Public Status Pages: Why and How to Run One

When your site or app goes down, your customers ask one question: "Is it me, or is it you?" If the only way to find out is to email support or post on social media, you get a flood of duplicate tickets at exactly the moment your team has the least time. A public status page answers that question before it is asked. This article covers what a good status page contains, what to write during an incident (with templates), where to host it and how to make people find it.

What a status page is for

A status page is a public, read-only page that shows whether your services are working right now, and, when they are not, what you know and what you are doing about it. It serves three audiences:

Customers who want to know whether a problem is on their side, and whether to wait or find a workaround.
Your own support and sales staff, who need a single, authoritative answer to give people.
Partners and integrators whose systems call yours and who need to decide whether to retry, queue or fail over.

The business benefit comes from the mechanism, not from the page itself: one public update replaces many individual conversations. A customer who sees "We are aware of the problem with checkout and are working on it" on the status page has no reason to open a ticket that says the same thing. Over time, a page that is reliably accurate also builds trust, because customers learn that you tell them about problems instead of hiding them.

What a good status page contains

Current state, at a glance. One line at the top: everything working, or which part is affected. Green, yellow and red are fine, but also say it in words for color-blind visitors and screen readers.
Components that match how customers think. "Website", "Checkout", "API", "Customer dashboard" is useful. "db-primary-02" is not. If one internal server failing breaks checkout, the component is "Checkout".
Uptime history. A 30- or 90-day record per component shows whether today is an exception or a pattern. Honest history is more convincing than a page that is always green.
Active incident updates, newest first, each with a timestamp and time zone.
Past incidents, briefly, so people can see how you handled them.
Scheduled maintenance, announced in advance with a start and end time.
A way to get help if the page does not answer the question: a link to your support form or help center.

What to leave off: internal hostnames, IP addresses, stack traces, names of the engineers on call, and anything that would help an attacker map your infrastructure.

Host it away from what it reports on

The most common status-page mistake is hosting it on the same server, the same database or the same CDN configuration as the main site. When that infrastructure fails, the status page goes down with it, which is the one moment it was needed.

Rules of thumb:

Use a different host or a hosted status-page service, so the page does not share your servers, database or load balancer.
Do not make the status page depend on your login system, your API or your main domain's DNS if you can avoid it. A subdomain such as status.example.com is convenient, but it still relies on your DNS provider; if that is a concern, link to the hosted address directly as a fallback.
Make sure the people who post updates can do so even when your internal tools (SSO, VPN, chat) are down. Keep a break-glass login.
Drive the up/down indicators from external monitoring rather than from the application reporting on itself. An app that has crashed cannot report that it crashed.

What to post during an incident

The industry has settled on four stages: Investigating, Identified, Monitoring and Resolved. Using them consistently tells readers where you are without making them parse a paragraph. Post the first update fast, even if you know little, and then update on a predictable schedule (every 30 minutes is a common promise) even if nothing has changed.

Templates you can adapt:

Investigating

Investigating: Some customers are unable to complete checkout. We are investigating the cause. Browsing and accounts are not affected. Next update by 14:30 UTC.

Identified

Identified: The checkout failures are caused by a problem with our payment provider connection. We are applying a fix. Orders placed before 13:50 UTC were processed normally. Next update by 15:00 UTC.

Monitoring

Monitoring: A fix has been deployed and checkout is working again. We are monitoring to make sure it stays stable. If a payment failed during the incident, you were not charged and can retry now.

Resolved

Resolved: Checkout has been working normally since 14:52 UTC. Between 13:50 and 14:52 UTC, about a third of checkout attempts failed with an error. No payments were taken for failed orders. We will publish a short summary of the cause and what we are changing within two business days.

Notice what the templates do: they describe impact from the customer's point of view, say what is not affected, give a time for the next update and tell people whether they need to do anything. They avoid blame, speculation and internal jargon. If you do not know the cause yet, say so; a confident wrong explanation does more damage than "we are still investigating". For the internal side of the same process, see incident management best practices for dev teams.

Writing the follow-up

For significant incidents, a short public post-incident summary a few days later is worth the effort: what happened, how long, who was affected, the root cause in plain language and the concrete changes you are making. Keep it factual. Customers rarely expect perfection; they do expect to see that the same failure is less likely next time.

Make it findable

A status page only reduces tickets if people find it before they contact you. Link it where they look when something is wrong:

Site footer, labeled "Status" or "System status".
Help center and contact page, ideally above the contact form: "Having trouble? Check our system status first."
Error pages: your custom 500, 502 and 503 pages should include the link. They are static, so they still load when the app does not.
App and API documentation, for developers who integrate with you.
Support auto-replies during an active incident.
Social profiles, so that people who come to complain find the answer instead.

How a status page reduces support load

The mechanism is simple, and you can verify it with your own data rather than anyone's benchmark:

Deflection. Customers who can confirm the problem is on your side stop troubleshooting their own setup and do not ask you about it.
One answer instead of many. Support staff reply to incoming tickets with a link instead of writing individual explanations, and the answer is consistent.
Fewer follow-ups. "Any update?" messages drop when updates arrive on a schedule people can see.
Fewer "is it down?" checks after recovery. A clear "Resolved" post closes the loop for everyone at once.

To measure the effect, tag incident-related tickets during outages and compare the counts for incidents before and after you started publishing a status page, relative to the incident's length and the number of customers affected.

Common mistakes

Always green. A page that never admits a problem trains people to ignore it. If the status page is updated manually, someone must own updating it during every incident.
Too slow. If customers report the outage on social media 20 minutes before the page changes, it has lost credibility. Automated status from external monitoring helps here.
Too technical. Write for the least technical customer who will read it.
Silence between updates. "No change, still working on it, next update at 15:30" is a valid and useful update.
Forgetting maintenance. Planned downtime that surprises customers feels the same as an outage. Announce it, and pause your alerts for the window so your own team is not paged; see maintenance windows without false alarms.

Checklist

Status page hosted separately from your main infrastructure.
Components named the way customers describe your product.
Up/down state driven by external monitoring.
Uptime history visible for each component.
Incident templates for Investigating, Identified, Monitoring and Resolved saved where the on-call person can find them.
Update schedule agreed (for example every 30 minutes).
Linked from the footer, help center, contact page, error pages and docs.
An owner for posting updates during every incident.

Uptime Monitor includes public status pages built from your monitoring data: one page can list several of your sites with their current state, 30-day uptime, average response time and recent failed checks, and it is hosted on our infrastructure rather than yours, so it stays up when your server does not. If you are not monitoring yet, the free Starter plan is enough to create a status page for one site; the guide to monitoring website uptime for free walks through the setup.