Live component health, 90-day uptime and every incident we have had - including the ones nobody noticed. Paused runs are never affected by maintenance; that is the point of durable state.
Ninety days of daily health per component. Green is nominal, amber is degraded, red is an outage - measured from outside our network, not from our own dashboards.
Nothing. Run state lives in the engine's store, so a worker restart, a failover or a deploy is the same transition as a two-week wait for an approval.
A run waiting on human.approval holds no worker and no connection. It resumes from its last committed turn.
An interrupted turn is redispatched. Activities are idempotent at the engine boundary, so nothing double-fires.
Webhooks and schedules queue during a degradation and drain in order once capacity returns.
Ledger writes are part of the same commit as the turn, so the record never diverges from what actually ran.
Including the small ones. If it degraded your experience we publish it, with a timeline and what we changed afterwards.
A rate-limit change at the Telegram API caused queueing on notify.telegram deliveries. Other channels were unaffected, and no runs failed - queued sends drained automatically once concurrency was reduced.
A long-running analytics query saturated a read replica, slowing dashboard first paint. The API and execution engine were unaffected; no runs were delayed or lost.
Planned maintenance announced 7 days in advance. Paused runs were unaffected by design - per-turn dispatch means state lives in the store, so nothing needed replaying afterwards.
Incident and maintenance notices by email or webhook, plus a machine-readable status endpoint for your own dashboards.