Status pages that only know "green" and "red" force a lie. Something is slow, partially broken, or broken for a subset of users. If you mark that operational, you gaslight customers. If you mark it down, you imply nobody can work. Degraded exists for the middle — but only if the word means the same thing every time.
A definition you can steal
- Operational — customers can complete the core action for this component with normal effort.
- Degraded — the component works with significant pain: errors for some users, long delays, failover to a backup path, missing non-critical features.
- Down — the core action fails for everyone (or effectively everyone) who needs this component.
"Some users" and "significant pain" are judgment calls. Write examples for your product:
- Login succeeds but takes 30+ seconds → degraded.
- Login fails with 500s for all → down.
- Export works, search does not → search degraded, not the whole product down.
What degraded is not
- A PR-friendly synonym for down.
- A parking place for "we do not know yet." If you do not know, say investigating — and update soon.
- The default for every blip so you never have to say down.
If your history is a sea of yellow, customers learn to ignore yellow. You have rebuilt alert fatigue on a public page.
How monitoring should map
Automate carefully. A single failing probe should not flip a component to down. A confirmed outage on the customer path should. Partial regional failure might be degraded for "API" while you investigate — especially when not everyone is affected.
Human judgment still matters for wording. Automation sets the weather; you write the forecast.
During the incident
Prefer:
- "API is degraded: elevated errors in EU, retries succeeding for most users."
Over:
- "We are experiencing issues."
Specific degraded beats poetic vagueness. Customers forgive pain they understand.