What a status page is actually for
During an outage, customers don't know if it's their connection, their account, or your service. Without a status page, that uncertainty becomes support tickets, tweets, and repeated "is this just me?" messages — all landing on your team at the exact moment they're busiest fixing the actual problem.
A status page absorbs that. One link, one place to check, updated as the incident happens. It doesn't fix the outage, but it removes the second problem — confused customers — that every outage otherwise creates on top of the first.
What belongs on it
At minimum: the components customers actually care about — the main site or app, the API if customers integrate with it, and anything else with its own failure mode worth tracking separately. Each component should show its current state (operational, degraded, down) and a rolling uptime figure.
Beyond that, incident updates — a short note when something breaks, an update as you learn more, and a resolution note when it's fixed — turn the page from a static dashboard into a real communication channel. Optionally, an uptime badge visitors can embed elsewhere is a low-effort way to make the page findable from a README or docs site.
Why it should be powered by real monitors, not updated by hand
A status page someone has to manually flip to "red" during an incident has an obvious flaw: it depends on a human noticing and remembering to update it, exactly when that human is busiest. It also tends to stay stuck on "all systems operational" long after something has actually broken.
A status page tied to the same monitors already watching your site updates itself the moment a check fails and again the moment it recovers — no one has to remember to touch it during an incident, which is exactly when it matters most.
Mistakes that make a status page useless
Manually maintained and stale. If it lags reality by hours, customers learn not to trust it and go back to filing tickets.
No incident history. A page that only shows current state, with no record of past incidents or uptime, can't answer "how reliable has this actually been" — which is often the real question a prospective customer is asking.
Buried where no one finds it during an outage. A status page linked nowhere from the product, the docs, or the footer doesn't help anyone at the moment they need it.
Writing good incident updates
The automatic part of a status page — a component turning red or green — tells people something changed. It doesn't tell them what, or what to expect next, which is what a short human note is for. "We're aware of an issue affecting [component] and investigating" beats silence even with no further detail yet; a second update with what's known, and a resolution note when it's fixed, is usually all a real incident needs.
Vague reassurance without a timestamp or a next step ("we're looking into it") is barely better than nothing if it never gets updated again. The bar isn't eloquence — it's posting something promptly, then following up.
Public vs. internal status pages
A public status page is for customers and anyone integrating with your API — it needs to be simple, accurate, and not leak internal detail (no need to name the specific database table that failed). An internal status page, shared only with a team, can afford more detail and more components, since the audience already knows the systems involved. Many teams end up wanting both: a clean public page for customers, and a more detailed internal view for on-call.
How Holter does it
Holter status pages are driven by the same monitors that check your site — a component goes red because a real check failed, and green again because it recovered, with no manual step in between. Pages carry an uptime history, incident notes, and an embeddable badge, and every page starts on the free plan alongside 5 monitors and 5-minute checks, no credit card required.
Holter watches this for you: outside-in monitors plus dead-man heartbeats for silent failures. Free plan: 5 monitors, 5-minute checks, no credit card.
Create a status page — free