What Should Your Status Page Say During an Outage?
A good status page update during an outage says three things and nothing else: what is affected, since when, and when you will post again. It skips the guesswork about root cause until you actually know it, and it never repeats the raw error strings, hostnames, or stack traces sitting on your internal dashboard. Get those three things right and users stop refreshing the page and emailing you to ask if you already know.
A status page is a public page, usually at a short shareable link, that shows whether a service is currently operational, degraded, or down, plus a short history of past incidents. It exists so your users can answer their own question — is it just me? — without opening a support ticket.
If you have ever refreshed a vendor's status page during an outage, you already know the two ways it fails you. Either it says everything is fine while the product is clearly broken in front of you, or it goes quiet for three hours with no update at all. Both destroy trust faster than the outage itself. This guide covers what to put in an update, what to leave out, how often to post, and how to keep the page honest even when nothing is wrong yet.
What Should Your Status Page Say During an Outage?
Each update should cover five things, in this order, and nothing more:
- State — operational, degraded, or down. Pick the honest one, not the optimistic one.
- What is affected — the specific component (checkout, API, the mobile app), not "the platform".
- Since when — a timestamp, not "earlier today".
- What you are doing about it — one line: investigating, identified, monitoring, or resolved.
- When you will post again — a concrete time, even if the honest answer is "in 30 minutes with no change".
That last item matters more than people expect. A promised next-update time is what stops a reader from refreshing every ninety seconds — they know exactly when to check back instead of guessing.
An example update
"Checkout — degraded since 14:12 UTC. Some card payments are failing to authorize. We have identified the cause and are rolling out a fix. Next update by 14:45 UTC or sooner if resolved."
Notice what is absent: no gateway provider name, no HTTP status code, no guess at whose bug caused it. All of that is true and useful internally. None of it belongs on a page your customers read.
How Often Should You Post Updates While an Incident Is Open?
Post an initial update within minutes of detecting the problem — before you have a root cause, before you have a fix, as soon as you know something is wrong. Silence in the first ten minutes is what sends people to your support inbox instead of your status page. After that, update on a fixed cadence (every 30–60 minutes is reasonable for most small teams) or immediately whenever the state changes, whichever comes first. A resolved incident gets one closing update: what broke, roughly how long it lasted, and that it is fixed. You do not owe a postmortem in the status feed — that can live in a separate write-up if you publish one.
What Should Never Show Up on a Status Page?
Three categories stay off the public page, full stop: raw diagnostics (error strings, hostnames, response codes), speculation about root cause before it is confirmed, and blame — at a vendor, a team, or an individual. A status page states that something was down and for how long. It never states why, in technical or internal terms, because that detail is either wrong (early guesses usually are) or exposes information about your infrastructure that has no business being public. Pingwire's own public status pages are built to this rule structurally: the incident feed a page renders carries only the component name, the state, and the duration — the private diagnostics an owner sees on their dashboard are deliberately excluded from what gets published, not just left out by convention.
Who Should Be Allowed to Post an Update?
On a two-person team, the honest answer is usually "whoever is fixing it," and that is fine as long as it is written down somewhere, not assumed. The trap is not malice, it is momentum: the person elbow-deep in a fix is the worst-positioned person to also remember to post a calm, public update every 45 minutes. Decide in advance, before the next incident, whether the person handling the fix also owns the page, or whether a second person (a co-founder, a teammate, even someone reading the internal alert and drafting the public line) takes that job instead. Neither answer is wrong; not deciding is.
How Do You Keep a Status Page Honest When Nothing Is Wrong Yet?
The most common status page lie is not written by a person — it is a default. Three cases trip up most homegrown pages:
- A monitor with zero checks so far renders as 100% uptime instead of "no data". Zero measurements is not a fact about reliability.
- A check that has not run yet ("pending") renders green because green is the default color, not because anything was confirmed operational.
- A paused monitor keeps showing its last known state instead of saying it is paused — so a page can read "operational" for a service nobody has watched in weeks.
Each of these is a page telling your own users something you do not actually know. The fix is the same in every case: treat "no data" as its own state, distinct from both up and down, and never let a default fill in for a measurement you do not have.
| Hand-written page | Monitor-linked page | |
|---|---|---|
| Update trigger | Someone remembers to edit it | State follows the underlying check automatically |
| Honesty risk | Easy to leave stale after the fix ships | Reflects current check results, including "no data" |
| Effort per incident | Manual edit, every time | Components already exist; you write the summary line |
Writing Updates by Hand Works Until It Does Not
A hand-edited status page is fine for a service with one incident a year. It gets harder the moment you are also the one fixing the outage — composing careful, honest paragraph updates is the last thing you want to do mid-incident. Pingwire's status pages attach directly to your existing uptime, heartbeat, or traffic monitors, so the state and history sections update from real check results instead of memory, and you only have to write the one-line summary. The link is a random token you can rotate any time, which quietly revokes the old URL without deleting the page.
The most common reason to skip a status page is "we do not have enough users or incidents to justify one." That is backwards — a status page costs you almost nothing to keep dark under normal operation, and the one time it earns its keep is the first real outage, when a link you can drop into an email or a pinned message replaces answering the same "is it down?" question five separate times. The setup cost is a few minutes once; the payoff shows up exactly when you have the least spare time to improvise one.
Set One Up in a Few Minutes
If you already have a monitor watching the service, creating a page and attaching it takes two API calls:
curl -X POST https://pingwire.dev/api/v1/status-pages.php \
-H "Authorization: Bearer pw_live_xxxxx" \
-d '{"title":"Acme status"}'
curl -X POST https://pingwire.dev/api/v1/status-pages.php \
-H "Authorization: Bearer pw_live_xxxxx" \
-d '{"id":1,"monitors":[{"monitor_id":4,"display_name":"Checkout"}]}'Create a free account, connect your first monitor, and publish a status page before you need one — it takes a few minutes now versus composing your first update live during an outage.
Frequently asked questions
What is a status page?
A status page is a public page, usually at a short shareable link, that shows whether a service is currently operational, degraded, or down, along with a short history of past incidents. It lets users check current state themselves instead of emailing to ask if you know something is wrong.
How often should I post updates during an outage?
Post an initial update within minutes of detecting the problem, then update on a fixed cadence such as every 30 to 60 minutes or immediately whenever the state changes, whichever comes first. Always include when you will post next so readers know when to check back instead of refreshing constantly.
Should a status page explain the root cause of an outage?
Not while the incident is open. Early guesses about root cause are often wrong, and confirmed technical detail like hostnames or error codes exposes information about your infrastructure that has no reason to be public. State what is affected and for how long; save the full explanation for a postmortem if you publish one.
Do I need a status page if I only have a few users?
Yes, because the cost of having one sits at zero until you need it. A status page stays quiet under normal operation, and the first real outage is exactly when a shareable link saves you from answering the same "is it down?" question multiple times over email or chat.
What's the difference between uptime monitoring and a status page?
Uptime monitoring is what tells you a service is down in the first place, by checking it from outside your infrastructure. A status page is what tells your users the same thing, at a public link, without them having to ask you. Most teams need both: monitoring to detect, a status page to communicate.
Can I revoke a status page link after sharing it?
If the page is built on a rotatable token, yes — rotating generates a new link and immediately invalidates the old one, without deleting the page or its history. This matters if a link was shared more broadly than intended, or a former client should no longer see current status.
Try Pingwire
Send your first alert in under 30 seconds — one HTTP call, straight to a chat and your phone.