Glossary
Status page
A status page is a public page reporting whether a service is working, hosted deliberately outside the infrastructure it describes. Its purpose is not transparency for its own sake: it is the cheapest way to stop an incident from also becoming a support queue, because every customer who checks the page is one who does not write to you. That only works if the page is updated during incidents, which is the part most status pages fail at.
Why it must be hosted elsewhere
A status page sharing infrastructure with the service reports the service is fine right up until it goes down with it.
That is not a hypothetical failure mode; it is the normal one, because outages tend to take out whole environments rather than single components.
Which is why status pages are usually on a separate domain, a separate provider, or both — and why a status page on a subdomain of the main site is worth a second look.
The same reasoning applies to DNS: a status page whose name resolves through the nameservers that just failed is unreachable for the same reason.
What makes one trustworthy
Updates during the incident, not after it. A page that is accurate only in retrospect is a changelog.
Component-level state, so a partial outage reads as partial rather than as everything being fine.
A timestamp on the current state, so a reader can tell the difference between working and not updated.
A history that includes the incidents that went badly. A page showing an unbroken record of availability is read as unmaintained, correctly.
Automatic and manual updates are different things
An automatically driven page reflects monitoring checks and is honest about what those checks cover, which is usually less than the whole service.
A manually updated page reflects what a person knows, including the parts no check measures, and stops being updated when everyone is busy — which is during an incident.
Most well-run pages are both: automatic component state, with manual incident narrative on top.
Neither replaces telling the customers who are already waiting, which is what a status page exists to make cheaper rather than unnecessary.
What is observable
Whether a public status page is referenced from the site, detected from the links the pages carry.
Whether public monitoring or observability tooling is referenced, which is adjacent information about how the service is watched.
Not whether the page is accurate, and not whether it is updated during incidents — both need observation over time rather than a single scan.
The absence of a status page is reported as absence. Most sites do not need one, and that is not a defect.
What to write on it during an incident
What is affected, in the words a customer would use rather than the name of the component.
Whether you know the cause, stated plainly including when you do not.
When the next update will be, which is the single most useful sentence on the page because it stops people refreshing.
A first update within minutes beats a complete one within an hour: the point is telling people you know.
Frequently asked questions
- Can I host my status page on a subdomain of my site?
- You can, and it will be unavailable during exactly the outages it exists for. Separate infrastructure — and ideally separate DNS — is the whole point.
- Does every site need a status page?
- No. It pays for itself where an outage generates support volume, which means services with paying users and integrations. A brochure site gains nothing from one.
- Should the history show past incidents?
- Yes. A page with no incidents in its history reads as unmaintained rather than reliable, because every service has had one.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website