Status page indicators decoded: what 'minor', 'major', and 'maintenance' actually mean

Most public status pages — Statuspage.io, Status.io, Better Stack, even custom-built ones — converge on the same five labels at the top of the page. Operational. Minor. Major. Critical. Maintenance. They look like rough English but they're actually a tight machine-readable vocabulary. If you know what each value commits the vendor to, you can read a status page in three seconds.

The five values

Statuspage publishes these as the canonical indicator field in its API. Almost every competing status page tool uses the same names so they can be aggregated:

The vocabulary is intentionally small. Five values means the badge on a status page can use a single colour and you can read it in your peripheral vision. The trade-off: it compresses a lot of nuance. A "minor" with 2% of users affected reads the same as a "minor" with 40% affected.

How the page-level indicator is computed

The top-of-page indicator is a rollup. Statuspage walks every component in the page tree and takes the worst status, with the following ordering (worst-to-best):

1. major_outage
2. partial_outage
3. degraded_performance
4. under_maintenance
5. operational

Then it maps that worst-component status to the page indicator:

• One or more components at major_outage → page is critical
• One or more at partial_outage → page is major
• One or more at degraded_performance → page is minor
• All operational, but maintenance running → page is maintenance
• Everything else → none

The implication is important: a status page can report critical even if 99% of components are healthy. A single broken component is enough to flip the whole page red. This is the right behaviour — users care about the service they're trying to use, not the company-wide average — but it means the headline label is often more alarming than the actual blast radius.

When you see a critical banner, scroll down and read the affected component list. The page tells you exactly which surfaces are broken.

"Operational" doesn't mean "working for you"

The single most common misreading of status pages: assuming "all systems operational" means the service is working for the user reading the page.

It doesn't. It means:

• No component alarm has been raised by the vendor.
• No incident has been opened in the last 5 minutes (the typical alarm latency).
• No human has manually flagged the page to minor or worse.

If your specific feature, region, or account hit the failure window before the alarm fired, the page will still say green. The lag between user-impacting failure and status-page acknowledgement is the single biggest source of "the status page is lying" complaints. The page isn't lying — it's just behind the curve.

Maintenance is a special case

maintenance pre-empts the other indicators. If a vendor pre-scheduled a maintenance window and the window is active right now, the page shows maintenance — even if the maintenance is also causing real user-facing problems.

This is by design. The vendor is saying "we know, this is planned, don't open a support ticket." The implication for you as a reader:

• If you see maintenance, check the announced end time. Past that, the indicator should switch back to none automatically.
• If maintenance overruns, the indicator usually stays maintenance until someone manually overrides it, even if the situation has effectively become a real incident.
• Maintenance + active incidents in the timeline below is a hint that the vendor is hiding a problem behind a planned window. Rare, but it happens.

Reading the timeline matters more than the indicator

The five-state indicator is a summary. The real signal is the incident timeline below it. A page that's been at none for 30 days but has a long history of major incidents tells you something different from a page that just flipped to minor for the first time in months.

Pay attention to:

• Frequency. How often do incidents open? Daily is a red flag; quarterly is normal at scale.
• Mean time to resolution. How long do incidents stay open? Hours is normal. Days suggests systemic issues or understaffed on-call.
• Acknowledgement latency. How quickly does a known outage get a status page update? A 30-minute gap between Twitter complaints and a status-page acknowledgement is a sign the page is a comms artifact, not a real-time signal.

What we do with the indicator

On StatusDetector, every service page shows the vendor's current indicator alongside our own HTTP probe and user-report data. The three signals usually agree. When they disagree — vendor says green, probe shows 500s, users are reporting issues — you've found a moment where the status page is behind the actual state of the world. Those are the moments where third-party monitoring is genuinely useful.

For a real-time view of which services across the catalogue are currently in minor, major, or critical, head to the Shutdown Radar. For a specific service's full timeline, search for it from the homepage — every /status/[slug] page surfaces the vendor's official indicator, current incidents, and historical patterns side-by-side.

Frequently asked

Does every status page use the same five values?

Most do. Statuspage.io is the dominant tool; Status.io, Better Stack, and Sorry App all match the same five-value vocabulary either by convention or because they're trying to be drop-in compatible. A few vendors (Google Cloud, AWS) publish JSON in a custom format but still map cleanly to the same five states.

What's the difference between 'major' and 'critical'?

major is a partial outage — a meaningful subset of users are blocked from a meaningful subset of the product. critical is a full outage — most or all users can't use the primary surface. The line between them is editorial, not technical; vendors err on the side of major to avoid scaring everyone when only one region is affected.

Why do some status pages skip 'minor' entirely?

Some vendors only publish updates at the major threshold and above, because announcing every transient degradation creates noise. The trade-off: a really long stretch of minor issues can hide an underlying problem the vendor is choosing not to acknowledge publicly.