Status Overview
The Status section explains how to interpret operational health, release progress, and feature readiness. Use these pages to decide whether to keep moving, mitigate risk, or escalate.
Status Views
Status is split into four views so you can isolate the kind of decision you need to make:
- Overview -- how the full status system works and when to use each view.
- Service Cards -- runtime health and reliability signals for live services.
- Releases -- rollout state, blockers, and post-release confidence.
- Feature Registry -- feature maturity, availability, and actionability.
Reading Signals
Every status view should be read in this order:
- State -- the current explicit status (healthy, degraded, blocked, beta, and so on).
- Freshness -- when that status was last updated.
- Impact -- which users, teams, or workflows are affected.
- Owner and next action -- who owns the item and what should happen next.
Action Workflow
Once you identify a concerning signal, use a simple response loop:
- Confirm whether the signal is current and reproducible.
- Classify impact as local, team-wide, or user-facing.
- Apply the relevant playbook for service, release, or feature status.
- Document the update so the next reader has a clear current state.
Common Playbooks
| Signal | Immediate Action | Next Action |
|---|---|---|
| Service health downgraded | Freeze risky changes and verify telemetry | Open incident thread and assign owner |
| Release blocked | Pause rollout expansion | Track blocker to resolution or rollback |
| Feature marked experimental | Limit usage to approved cohort | Collect validation data before promotion |
| Status update is stale | Re-check source systems | Refresh status with timestamp and owner |
When to Escalate
Escalate immediately when you see user-facing impact, conflicting status signals, repeated regression after rollback, or unknown ownership for a critical item.