How to set up a status page your customers will trust
A status page earns trust by being honest when things break. Choose what to show, let real checks drive it, and say something at every stage.
Keep customers informed · 4 min read · Updated Oct 12, 2026
Most status pages say "All systems operational" during the outage their customers are complaining about. After the second time, nobody opens the page again, and support gets the questions it was meant to answer.
A status page is trusted for one reason: it was right the last time something broke. Everything in this guide serves that.
How it works
A status page answers three questions for someone who cannot use your product right now: is it me or you, do you know, and when will it be back?
It can only answer them if it is fed by the same checks that alert your team, shows the parts of the product in words customers use, and changes within minutes of a failure, without waiting for someone to remember to update it.
Step 1: Name the parts as customers see them
A customer does not know what pg-primary-2 is. They know they cannot check out.
List the things a customer does with your product, and make those the components. Three to seven is right for most products. Fewer says too little; more makes people hunt.
Step 2: Let real checks drive it
A page updated by hand is updated late, by someone who is busy fixing the problem. Connect each component to the checks that watch it, so that its state follows what the checks see.
This is also what keeps the page honest. If the page can only turn red when a person decides to admit it, customers learn what green is worth.
Host the page somewhere other than the product. A status page on the same servers goes down with them.
Step 3: Say something at every stage
An incident on a status page moves through four stages. Each needs one sentence, quickly, more than it needs detail:
| Stage | What it tells the customer |
|---|---|
| Investigating | We know. You can stop wondering whether it is you. |
| Identified | We know why, and we are fixing it. |
| Monitoring | A fix is in. We are watching that it holds. |
| Resolved | It is over. |
The first update matters most. "We are investigating" within five minutes is worth more than a full explanation after an hour.
Leave out guesses about the cause, blame, internal names, and promised times you are not sure of. Afterwards, a short account of what happened and what is changing closes the loop: see how to write an incident postmortem.
Step 4: Show the history
Uptime over the last months and the list of past incidents are what a prospective customer looks at. A page with a few short, well-handled incidents reads better than one with none, which reads as a page nobody maintains.
Step 5: Let people subscribe, and tell them where it is
- Subscriptions. Email for people, a feed for tools. Someone who subscribed does not have to keep reloading, or ask support.
- Planned work. Announce it on the same page: see how to plan a maintenance window.
- Links. In the footer of your site, on the support page and on the login page, which is where people are when it matters.
Step 6: Test it
- Subscribe to the page with your own address.
- Make a check behind one component fail on purpose.
- Watch the component change, the incident appear, and the email arrive. Time it.
- Let the check recover, and watch all three clear.
If any of the three needed a person to do something, that is the step that will be missed in a real outage.
Common mistakes
- Always green. The page is updated by hand, or not connected to anything.
- Components named for the team. Internal service names mean nothing outside.
- Silence during the incident. No update for an hour reads as "they do not know".
- Hiding the history. It is the part that builds trust.
- Nobody can find it. A status page not linked from the product is found by nobody.
Doing this in saysOK
A status page is built from components, and each component takes the worst state of the monitors linked to it: Operational, Degraded or Down. The headline follows from them.
When a monitor on the page fails, its component changes at once. If an alert rule with the Open incident action covers that monitor, the incident is also posted to the page by itself, with a title that names the affected components, and subscribers are told. Each stage posts one sentence in fixed wording, so the page says something at every stage without anyone writing under pressure.
The updates your team writes on the incident are for the team and are not shown publicly. Your own words reach customers through the page's summary message, a maintenance window's public message, and the published postmortem summary, which appears under the incident.
Visitors can subscribe by email, confirmed by a link, or by RSS. The page can show 90 days of uptime, the ten most recent incidents and planned maintenance.
Every plan includes a status page; see pricing for how many, and for custom domains.
Next
To put the page on your own address, see how to set up a status page on your own domain.
Set this up in saysOK
Start on the free plan. The guide says where a step needs a paid one.