Back to blog
3 min read
ProductStatus pages

Designing status pages your customers actually trust

A status page is the one thing customers look at on your worst day. A few opinions on making yours read as honest, not as damage control.

NK

Nabin Khair · Founder

A status page is the one piece of your infrastructure your customers look at on your worst day. Get it right and an outage can actually build trust. Get it wrong and a green "all systems operational" banner sitting on top of a known outage tells everyone the page is theater, and they will not believe it again.

I have opinions about this, mostly formed by watching how the good ones behave during real incidents.

A green banner during an outage is worse than no page at all

The fastest way to burn trust is a status page that insists everything is fine while support tickets pile up. If your monitors already know a service is failing, the page should be wired to the same truth your on-call is.

In Tallwatch, the components on a status page map to your monitors, so the page is grounded in what you are actually measuring rather than in someone remembering to flip a switch in the middle of an incident. You still write the human updates. The underlying signal just comes from the same checks that page your team.

Separate "is it up" from "what happened"

The pages that work answer two different questions for two different readers, and they keep them apart:

  • The live signal, for the customer in a hurry. Which components are healthy right now, and the uptime trend behind them. One glance, done.
  • The incident story, for the customer who wants detail. What broke, what you are doing about it, when it resolved.

Mash those together and you serve neither reader. Keep them separate and both get what they came for.

Write like a person who is handling it

This is the part no tool can do for you, and it is the part that matters most. Templated, robotic updates read as evasion. Compare these two.

We are aware of an issue and are working to resolve it.

Investigating elevated error rates on the API. Checks from three regions are failing. We have paged the on-call engineer and will post the next update by 14:30 UTC.

The second one is specific, honest about what you do and do not yet know, and it sets the next checkpoint so nobody has to sit there refreshing. A status update is a small promise. Keep the small ones during an outage and the big promise, that your product works, becomes a lot easier to believe afterward.

Put it on your own domain

A status page at status.yourcompany.com, in your colors, reads as yours. The same page on a generic vendor subdomain reads as outsourced, at the exact moment people are paying the closest attention to your brand. Tallwatch status pages run on your own custom domain with certificates handled for you, on every plan including free.

None of this is really about design polish. A status page is a trust instrument, and an outage handled in the open is one of the few chances you get to prove you are honest when it is inconvenient. That is worth far more than the green banner ever was.