The outage starts at 9:14am. By 9:16, the first support ticket lands: "Is the app down?" By 9:20 there are forty of them, all asking the same thing. Your support team is now answering "yes, we're looking into it" forty times instead of helping you fix the actual problem.
Somewhere, a status page that said "Investigating — we're on it" would have answered all forty for you, automatically, the moment you posted it.
A status page is the most underrated tool in reliability. It costs almost nothing to run and it does its best work on your worst day. Let's talk about doing it well.
What a status page is (and what it's for)
A status page is a public page that shows the current health of your service — what's up, what's degraded, and what's being worked on. Think status.yourcompany.com.
It quietly does three jobs:
| Job | What it means |
|---|---|
| Deflect tickets | Customers check the page instead of flooding support. |
| Build trust | Transparency during an outage reads as competence, not weakness. |
| Set expectations | "We know, we're on it, here's the ETA" calms people down. |
Counter-intuitive truth: hiding outages destroys more trust than the outage itself. Customers forgive problems; they don't forgive being kept in the dark.
The best practices
1. Host it somewhere your outage can't take down
The cardinal rule. If your status page runs on the same servers as your app, it'll go down exactly when you need it most — and a status page that's down during an outage is worse than none. Use a separate, independent host.
2. Show components customers recognise
Your customers don't know (or care) about "auth-service-v2". They know "Login", "Checkout", "API", "Dashboard". Name your components in their language, not your architecture's.
3. Communicate fast, then often
The first update matters more than the perfect update. A quick "We're investigating reports of errors" beats a polished message twenty minutes later. Then keep a steady rhythm — even "still working on it" reassures people someone's awake.
A simple, reusable incident lifecycle keeps you consistent:
| Stage | What it tells the customer |
|---|---|
| Investigating | We see a problem and we're digging in. |
| Identified | We know the cause; a fix is in progress. |
| Monitoring | The fix is live; we're watching to confirm. |
| Resolved | It's over, with a short note on what happened. |
4. Be honest about severity
Don't mark a full outage as "degraded performance" to soften the blow. Customers can tell, and the credibility you lose isn't worth the few minutes of comfort. Match the status to reality.
5. Show history, not just "now"
A green dot today is nice. A visible uptime history (a heatmap or percentage over weeks) is proof. It shows that today's incident is the exception, not the norm — context a single status indicator can't give.
6. Let people subscribe
Not everyone will sit refreshing your page. Offer subscriptions — RSS, email, or a webhook — so customers and your own team get updates pushed to them. The people who subscribe are usually your most engaged (and most anxious) users; serve them.
7. Announce maintenance before it happens
Planned work shouldn't look like an outage. Post scheduled maintenance ahead of time with a clear window, so the brief disruption is expected rather than alarming — and so it doesn't dent your uptime story.
8. Write a short follow-up after the big ones
After a significant incident, a brief, blameless note — what happened, what you did, what you're changing — turns a bad day into evidence that you take reliability seriously. You don't need a novel; a few honest paragraphs go a long way.
Dos and don'ts
| Do | Don't |
|---|---|
| Post the first update within minutes | Wait until you have the full story |
| Use plain, customer-facing language | List internal service names |
| Keep updating, even with "no change yet" | Go silent mid-incident |
| Match the status to reality | Downplay a real outage |
| Host it independently | Run it on the infrastructure that can fail |
| Show uptime history | Show only the current state |
A quick word on what not to put on it
A public status page is for customers. The messy reality of debugging — theories, logs, who's doing what — belongs in your internal incident notes, not on the page the whole world can read. Keep the public update calm and clear; keep the investigation private.
The bottom line
| Principle | In one line |
|---|---|
| Independence | Host it where your outage can't reach it. |
| Speed | First update in minutes, then keep going. |
| Honesty | Real severity, real history, no spin. |
| Empathy | Plain language, subscriptions, and a follow-up. |
A great status page doesn't pretend you never have problems. It shows that when you do, you're calm, honest, and on it — which is exactly the impression you want to leave on your worst day.
When you're ready to build one, our status pages guide covers components, visibility (public, private, or password-protected), incident updates and subscriptions, step by step.