When your site goes down, customers do not mainly want a fix on the spot; they want to know you are aware and what to expect. A status page answers that without a flood of emails and support tickets. This guide covers what belongs on one, how to divide your service into components, how to write each stage of an incident update, and why the page itself must not live on the infrastructure it reports about.
What a status page is for
A status page does three jobs:
- It reduces support load. People who can see "Checkout is degraded, we are working on it" are less likely to file a ticket asking if you are down.
- It sets expectations. A short factual message with a next-update time calms people more than silence.
- It builds a record. A visible history of incidents and how you handled them is one of the few trust signals that cannot be faked after the fact.
It is not a marketing page, a blog or a place to assign blame. Keep it plain, current and honest.
What to publish
Current status by component
Break your service into parts that match how customers experience it, not how your servers are arranged. "Web server 2" means nothing to a customer; "Website," "Checkout and payments," "Customer login," "API" and "Email notifications" do.
Good components share three properties:
- A customer can tell whether they are affected.
- You can tell, from monitoring, when it is failing.
- The list is short. Five to eight is usually enough; twenty creates noise and delays updates.
Use a small fixed vocabulary of states:
| State | Meaning | Example |
|---|---|---|
| Operational | Working normally | Everything responds in the usual time |
| Degraded performance | Works, but slowly or intermittently | Pages load in 8 seconds instead of 2 |
| Partial outage | Some users or features are failing | Card payments fail, bank transfers work |
| Major outage | Not usable | Site returns errors for everyone |
| Under maintenance | Planned work in progress | Scheduled database upgrade |
Incident history
Show at least the last 30 to 90 days of incidents with start time, end time and a short summary. People check history before signing up. An empty history is not reassuring if the page was created yesterday, and a history with clearly written incidents is.
Planned maintenance
Announce scheduled work ahead of time with the window, the expected impact and what users should do. Pair it with a correct 503 response on the site itself; see website maintenance mode done right.
Contact and subscription
Say how people can reach you if they are affected and, if possible, let them subscribe to updates by email or a feed. An update that reaches people is more useful than one they must remember to look for.
Optional: uptime figures
If you display uptime percentages, they must come from real external measurement. Read uptime percentages explained before quoting a number, because the period, definition of "down" and handling of maintenance all change the result.
Wording incidents
Incident updates move through a standard lifecycle. Each stage answers a different question, and sticking to it keeps messages short and consistent.
| Stage | Question it answers | Include |
|---|---|---|
| Investigating | Do you know? | What is affected, since when, that you are looking |
| Identified | Do you know why? | The cause in plain terms, the fix in progress |
| Monitoring | Is it fixed? | The fix is applied, you are watching |
| Resolved | Is it over? | Final time, impact summary, link to follow-up |
Principles of good incident wording
- Lead with impact, not cause. "Customers cannot log in" beats "an authentication microservice returned elevated 5xx rates."
- Use timestamps with a time zone. Always state one, and use UTC or your customers' main zone consistently.
- Promise the next update, not the fix. "Next update by 14:30 UTC" is a commitment you can keep; "fixed within the hour" is a guess.
- Be specific but careful. Say what you know. Do not speculate about cause until you are sure, and do not name a third party as at fault unless confirmed.
- No blame, no jargon, no minimising. Words like "minor" or "brief" are for the customer to judge afterwards.
- Do not wait for perfection. A rough first message within a few minutes beats a polished one after an hour.
Templates
Copy these and replace the placeholders.
Investigating
Investigating: <affected component> issues
We are investigating reports that <what users experience, e.g. customers
cannot complete checkout>. This started at about <HH:MM UTC>.
Other parts of the service are working normally.
Next update by <HH:MM UTC>.Identified
Identified: <affected component> issues
We have identified the cause: <plain-language cause, e.g. a database
server ran out of disk space>. We are <what you are doing, e.g. freeing
space and restoring the service>.
Impact: <who is affected and how>.
Next update by <HH:MM UTC>.Monitoring
Monitoring: <affected component>
A fix has been applied at <HH:MM UTC> and <component> is working again.
We are monitoring to confirm it stays stable.
If you still see problems, please <clear cache / contact support at ...>.
Next update by <HH:MM UTC>.Resolved
Resolved: <affected component>
This incident is resolved as of <HH:MM UTC>. Total duration was about
<N> minutes. During this time, <summary of impact>.
Cause: <one or two sentences>. We will publish a short write-up by
<date>.
We apologise for the disruption.Scheduled maintenance
Scheduled maintenance: <component>
On <date> from <HH:MM> to <HH:MM> UTC we will <what you are doing>.
During this window <what users will see, e.g. the site will show a
maintenance page and orders cannot be placed>.
No action is needed from you. We will post here when it is complete.Public or private?
Some status pages should be public; others should not.
- Public suits customer-facing services. It reduces support load and shows confidence. A public status page can show component states and incident history without exposing internals.
- Private or restricted suits internal tools, staging environments and services for a single client. The audience is known, so the page can be more detailed and can mention systems that would be pointless or risky to describe publicly.
A middle path is a public page with deliberately limited detail and a private runbook with the technical story. Never put credentials, internal hostnames, IP addresses or security details on a public page, even in an incident write-up.
For client work, decide at the start who sees what. A status page that surprises a client by making problems visible is a relationship problem waiting to happen; one that was agreed in advance is a feature.
Host it somewhere else
The most common design mistake is hosting the status page on the same server, network or DNS provider as the thing it describes. If your site goes down, so does the page that was meant to explain it.
To avoid that:
- Use a different provider and network. A hosted status service or a static page on a separate platform will keep working when your servers fail.
- Use a different DNS provider if you can. If your main domain's DNS fails,
status.example.comfails with it. Hosting the page on an independent domain is the safest, though a subdomain pointing at an external service covers most scenarios. - Do not rely on the same login. If your single sign-on breaks, you still need to post updates. Keep a separate account for the status service with its own two-factor method.
- Keep dependencies minimal. A status page that loads third-party scripts from a failing CDN or fetches data from your own API will itself break during outages. A static page with minimal JavaScript is the most robust form.
- Test it. Once, deliberately take the main site offline in a staging setup and confirm that the page is reachable and that you can update it.
Automatic updates from monitoring are valuable: a monitor failing can flip a component to "Major outage" within minutes, even before a human has written anything. Combine that with a human message for context.
Common mistakes
- Never updating the page, so it always says "All systems operational" during a real outage. This is worse than having no page.
- Updating only when fixed. Customers need the "we know" signal early.
- Using internal codenames or technical terms.
- Omitting time zones.
- Deleting old incidents to look better.
- Forgetting to link the status page from the site footer, login page and support email signature, where people look when something breaks.
To work out what to say about the cause once you know it, an outage root cause finder can help narrow down DNS, TLS, network or server causes, and down from where tells you whether the failure is global or regional. Afterwards, capture what you learned using the incident postmortem template and guide.
Next steps
- Publish your first page with status page.
- Feed it from real checks with the uptime monitor.
- Show your current state anywhere with uptime badges.
- Write the follow-up in the incident postmortem guide.
FAQ
Do small websites really need a status page?
If you have customers who depend on your site or app, yes, even a simple one. It takes a short time to set up and removes the need to answer the same "is it down?" question repeatedly. For a personal blog it is unnecessary.
How often should I update during an incident?
Post an initial message quickly, then commit to a next-update time and keep it, even if the update is "no change, still working on it." Every 30 minutes is a common rhythm for ongoing incidents; shorter if the incident is severe, longer if work is slow and steady.
Should I explain the technical cause on the status page?
Briefly, in plain language, once you are sure. Save the detailed story, with timeline and contributing factors, for a postmortem. Never publish speculation about causes during the incident.
Where should I host the status page?
On infrastructure that does not share your site's servers, network or DNS. A hosted status service or a static page on a different provider will survive the outages it is meant to report.
Is it bad to publish incidents publicly?
No. Every service has incidents. Customers trust providers that communicate clearly more than ones that appear perfect and say nothing. Deleting incident history damages trust far more than showing it.
Get notified when this guide updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.