Every company has a status page. Most of them are terrible. They show "All Systems Operational" while Twitter is full of users reporting errors. They get updated 45 minutes after the incident starts. They say "we're investigating" for three hours with no follow-up.
A good status page isn't a marketing asset — it's an operational tool. Here's how to build one that actually serves its purpose.
Why you need a status page
The primary benefit is support ticket deflection. During an incident, users want to know three things: is it down, do you know about it, and when will it be fixed. A status page answers the first two immediately, reducing inbound support volume by 30-50%.
The secondary benefit is trust. Companies that communicate openly about incidents — including honest timelines and root causes — retain customers better than those that pretend everything is fine. Transparency is a competitive advantage.
Show components, not a single status
"All Systems Operational" is meaningless when you have 15 services. Break your infrastructure into components that map to what users care about:
- API — Core API availability and response times
- Dashboard — Web application frontend
- Webhooks — Outbound webhook delivery
- Authentication — Login and token services
- Integrations — Third-party connections
When your webhook delivery is degraded but the API is fine, users who don't use webhooks shouldn't see a scary yellow banner. Component-level status gives accurate, targeted information.
Auto-update from monitoring
The worst status pages are manually updated. By the time someone logs in, writes an update, and publishes it, users have been experiencing the issue for 10-20 minutes with no acknowledgment.
Connect your status page directly to your monitoring. When uptime checks detect consecutive failures, the status page should reflect it automatically — no human in the loop for the initial detection. Auto-created incidents ensure users see the problem as fast as your monitoring detects it.
Manual updates still matter for context. Auto-detection handles the "is it down" question; human updates handle "what's happening and when will it be fixed."
Incident communication that doesn't suck
Acknowledge fast
The first update should come within 5 minutes of detection, even if it's just "We're investigating increased error rates on the API." Silence is worse than incomplete information. Users don't expect you to have a root cause in 5 minutes — they expect you to know something is wrong.
Update regularly
Set a cadence and stick to it. Every 20-30 minutes during an active incident, post an update. Even if the update is "Still investigating, no new information yet." Regular updates tell users the incident is being actively worked on. Radio silence suggests nobody's looking at it.
Be specific about impact
"Some users may experience issues" is useless. Instead: "POST requests to /api/v2/orders are returning 503 errors. GET requests are unaffected. Approximately 15% of order submissions are failing." Specific impact statements help users assess whether they're affected.
Explain what happened after resolution
When the incident is resolved, don't just flip the status to green and move on. Post a brief summary: what broke, why, how it was fixed, and what you're doing to prevent it. This is the foundation of a postmortem, and it belongs on the status page.
Custom domain: status.yourcompany.com
Your status page should live on your domain, not a third-party URL. status.yourcompany.com is professional and memorable. Users bookmark it. Search engines associate it with your brand. It also works when your main domain is down (as long as DNS resolves differently).
Set up a CNAME record pointing to your status page provider. SSL gets provisioned automatically. The whole process takes under 5 minutes.
Design for the worst moment
People visit your status page when they're already frustrated. The design should be:
- Fast loading — No heavy JavaScript bundles. The status page must work even when infrastructure is degraded. Server-side rendering is essential.
- Mobile-friendly — On-call engineers check status pages from their phones at 3 AM. Responsive layout is not optional.
- Scannable — Users should see the current status within 1 second of page load. Put the overall status at the top, component details below.
- Accessible — High contrast, clear typography, screen reader friendly. Don't rely solely on color to indicate status.
Subscriber notifications
Not everyone wants to manually check the status page. Offer subscription options:
- Email — The universal channel. Works for everyone.
- Webhooks — For B2B customers who want to pipe updates into their own systems or Slack channels.
- RSS — For users who prefer feed readers.
Subscribers should receive notifications when incidents are created, updated, and resolved. Include enough context in the notification that users don't need to visit the page — the email itself should be actionable.
Common mistakes
- Never updating — A status page that says "Operational" during an outage destroys trust faster than having no status page at all.
- Hiding incidents — Deleting resolved incidents or clearing history makes users suspicious. Keep a transparent history.
- Vague descriptions — "We're experiencing issues" tells users nothing. Name the affected service, describe the impact, estimate recovery time.
- No uptime history — Show 90-day uptime bars for each component. Users want to see your track record, not just today's status.
- Overcomplicating it — Don't show internal service names users don't recognize. Map components to user-facing features.
Postmortems: close the loop
For any significant incident (>15 minutes of user impact), publish a postmortem within 48 hours. A good postmortem includes:
- A clear summary of what happened and how long it lasted
- A timeline from detection to resolution
- Root cause analysis — what actually broke and why
- What went well during the response
- Action items with owners and deadlines
Postmortems linked from your status page show that you take reliability seriously. They turn a negative event (an outage) into a demonstration of engineering maturity.