How status pages work
A status page is a communication tool operated by the company having the problem. That single fact explains almost everything about how they behave.
The short version
- Most status pages are updated manually, by people who are also fixing the incident.
- A green banner means no incident has been declared, not that nothing is wrong.
- Component-level pages are far more useful than a single overall indicator.
- Host the status page somewhere the outage cannot reach - Most do; some have learned the hard way.
The most common complaint about status pages is that they are green when the service is obviously broken. It is a fair complaint, and the explanation is structural rather than dishonest.
A status page is not a monitoring dashboard. It is a communication channel, and on almost every platform the state shown on it is set by a human, during an incident, by someone who is also busy fixing it.
Why they lag
The sequence of a typical incident:
- Something breaks.
- Internal alerting fires - Usually within a minute or two.
- An engineer starts investigating.
- The scope and cause are determined - This is the slow step.
- Someone decides to declare an incident publicly.
- The status page is updated.
Steps four and five are where the time goes. Declaring an incident has consequences: It pages people, it triggers customer communication, it may have contractual implications, and it is reported on. Teams are reasonably reluctant to do it before they are confident, and that reluctance is measured in tens of minutes.
Meanwhile users knew in the first thirty seconds, because they are the ones the failure happened to. That gap is why independent monitoring and user reports have value alongside an official page rather than instead of it.
Automated status pages, and their problem
Some pages are driven directly by internal monitoring. These update fast, and they have a different failure: They inherit the blind spots of the monitoring.
If the health check is a request to a home page, the page turns red when the home page fails and stays green when login is broken for half the world. Automation makes a status page faster without making it see any more. Partial outages defeat both approaches equally.
What good looks like
Certain features make a status page genuinely useful, and they are easy to spot.
Component breakdown. Not "Service: Operational" but a row per subsystem. Slack lists messaging, notifications, huddles, files, search, apps and connections separately. GitHub separates Git operations, the API, webhooks, Issues, Actions, Packages and Pages. During a real incident only one or two rows go amber, and knowing which changes what you do.
Geographic detail. Cloudflare's page reports per data centre, which lets you check whether your nearest point of presence is the affected one. Most regional outages are invisible on a page that only reports globally.
Honest severity. Degraded, partial outage and major outage should mean different things and should be used accurately. Pages that label everything "degraded performance" are not communicating.
Incident history. A page that keeps a public archive is far more informative than a live indicator, because a pattern of incidents tells you more than a snapshot. Slack's archive goes back years.
Subscriptions. Email, RSS or webhook. Polling a status page is a waste of everyone's time.
Where the page is hosted matters
A status page must not depend on the infrastructure it reports on. It is an obvious principle and it has been learned expensively more than once - A company whose status page went down with its service, leaving no way to tell anyone anything.
This is why most status pages run on a third-party platform, on a separate domain, behind a different CDN. If a company's status page is at status.example.com served by the same infrastructure as example.com, that is a warning sign.
It also explains the strange silence during the worst outages. When internal tooling is affected, the people who would update the page may not be able to, which is why an unexplained quiet status page during an obvious incident is itself information.
Reading one properly
Green does not mean working. It means no incident has been declared. Those are different claims.
Check the components, not the banner. The banner is a summary and summaries lose exactly the information you need.
Check the timestamps. An incident marked resolved ten minutes ago may still be recovering - Caches are cold and backlogs are draining. Recovery is not the same as the fix.
Read the maintenance section. Planned downtime lives in a separate section from incidents, and it is the least-read part of every status page.
Check the history for patterns. Three incidents in the same component this month is a much stronger signal than any single event.
If you run one
Post early and be vague. "We are investigating reports of errors" within five minutes beats a precise diagnosis at forty. People forgive not knowing; they do not forgive silence.
Commit to an update cadence and honour it even when nothing has changed. "Still investigating, next update in 30 minutes" is a useful message. The absence of a message is what turns an outage into a crisis for the people waiting.
Describe impact in terms of what users cannot do, not in terms of your internals. "Users cannot upload files" is useful. "Elevated error rates in the storage service" is not.
And publish a post-mortem afterwards, honestly. It is the single strongest signal a company can give about how it handles reliability, and the companies with the best reputations for it are not the ones with the fewest outages.
Questions people ask
Why do status pages say everything is fine during an outage?
Because most are updated manually by people who are also fixing the incident, and declaring an incident publicly has consequences they want to be confident about first. Green means no incident has been declared, not that nothing is wrong.
Are automated status pages more reliable?
Faster, not more accurate. An automated page inherits the blind spots of whatever monitoring drives it - If the health check is a home page request, the page stays green while login is broken for everyone. Automation fixes the lag, not the coverage.
Why is a status page hosted on a different domain?
So that it survives the outage it is reporting on. A status page served by the same infrastructure as the service goes down with it, which has happened often enough that hosting it separately is now standard practice.
What makes a good status page?
Component-level detail rather than one overall banner, geographic breakdown where relevant, honest severity labels, a public incident history going back years, and subscriptions so nobody has to poll it.
Read next
Partial outages
Why most real outages are partial, how regional and feature-level failures hide from monitoring, and how to tell what is actually broken.
How long do outages last?
Typical outage durations by cause, why most incidents resolve in minutes, and the warning signs that an outage is going to be a long one.
Monitoring your own site
How to set up uptime monitoring that actually catches problems: What to check, from where, how often, and what to alert on.
What uptime percentages mean
The uptime nines table, what each level costs to achieve, and why how uptime is measured matters more than the number itself.