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.