There is no status page, notification channel, or in-product indicator for Elle / Aha! Builder service health. When the backend or its upstream AI provider has an incident, builders only discover it through failures: conversation-killing activejob errors that terminate the chat and destroy its full context, or chats that hang indefinitely on a spinner with no error at all. Support confirmed (June 2026) that no health-visibility channel currently exists and that transient job failures terminating whole conversations is a known weakness.
During June 9–11, 2026, recurring upstream-provider incidents halted all development on our Builder application for the better part of three days. Four separate conversations were killed mid-build (losing their accumulated context each time), additional time was lost to retries during windows we didn't know were incidents, and one morning was spent probing a degraded-but-not-erroring backend (a trivial question hung 40+ minutes). Without health visibility, every failure costs a support round-trip to distinguish "our problem" from "platform incident," and teams burn chat context and rework discovering outages empirically.
Provide visibility into Elle / Builder service health so teams can pause work during incidents instead of discovering them through failures. Any (or ideally all) of: (1) a public status page covering Elle / Builder backend and its AI-provider dependency, like status.aha.io but scoped to Builder/AI service health; (2) an in-product banner in the Builder editor when a degradation or incident is active ("Elle is currently experiencing delays — your chat may be affected"); (3) a subscribable notification channel (email/webhook/RSS) for incident start and resolution. Complementary hardening: when a transient backend/job failure does occur, fail the single response — not the entire conversation — so accumulated chat context survives the retry.