Status Page Best Practices for When Your Service Is Down

A status page that goes down with your product is worse than none. Put it on a different provider, a different domain or subdomain that doesn't share your DNS zone's failure modes, and a different login system from production. Test that you can publish from a phone on cellular data with your main network unreachable.

Link to it from places customers look: the app footer, the support widget, your help center and your email signature. Also make sure your in-app error message tells people where to check. If customers can't find the page during an incident, they'll open tickets instead, and support becomes your status channel.

Components should map to things customers say, not to your architecture. 'Sign-in', 'Dashboard', 'API', 'Email notifications' and 'Payments' are useful; 'ingest-worker-3' is not. A workable process:

1. List the five to ten customer-facing capabilities people would notice missing.
2. Assign each one an internal owner who can confirm its state.
3. Decide what each status means in your terms: degraded means slow or partial, outage means unusable for most customers.
4. Separate regions or tenants only if customers actually experience them separately.
5. Add third-party dependencies, such as your payment processor, only if you'll keep them updated.

Resist the urge to publish every internal service. Granularity you can't maintain becomes misleading fast.

Use a fixed sequence of states, commonly investigating, identified, monitoring and resolved, so readers can tell where things stand. Every update should answer four questions: who is affected, what they'll notice, what you're doing, and when the next update is coming.

Compare two versions of the same message. Vague: 'We're experiencing some issues with our platform.' Better: 'Some customers can't log in. Existing sessions still work. We've identified a failing authentication service and are rolling back a change. Next update in 30 minutes.' The second is what a support agent or an anxious customer can act on. Avoid jargon, avoid guessing at causes, and avoid promising a fix time you can't guarantee. If you don't know the estimate, say so and give the time of the next update instead.

Customers forgive outages more easily than evasiveness. Common errors:

• Waiting for a root cause before posting anything, so the first message arrives an hour after customers noticed.
• Using 'degraded performance' for what is really an outage, which customers read as spin.
• Missing your own promised update time. If nothing changed, post 'no change, still investigating' at the time you said.
• Blaming a vendor in the first message. Explain impact first; discuss vendors in the review if relevant.
• Marking incidents resolved too early and then reopening them, which teaches people to distrust green statuses.

Resolve the incident on the page only after you've watched the metrics recover. Then add a short summary within a day or two: what happened in plain terms, how long it lasted, and what you're changing. It doesn't need to be a full postmortem; the internal review belongs to the blameless postmortem template.

Decide in advance who's allowed to publish, and tie the rule to your severity scheme so the page isn't updated by whoever is nearest. The incident response plan outline has a place for the communications role. If you want status updates published from the same place you coordinate the incident, tools like incident.io include that workflow; the comparison in PagerDuty vs incident.io for B2B SaaS covers how that differs from a paging-first product.