Building a Status Page That Actually Helps When Things Break
The lightweight enterprise feature that closes deals and calms customers. Most SaaS ship one that does neither.
A status page is one of those features enterprise buyers scan for on the first visit. If it's missing, it's a small negative signal. If it's there and useful, it's a trust marker. If it's there and out of date during an actual outage, it's worse than not having one at all. This is how we build them when clients scope enterprise readiness.
Why status pages matter more than they should
They're not a technical feature. They're a communication feature. Customers use them for three jobs:
- Confirm that a problem they're seeing is your problem, not theirs.
- Estimate when the problem will be resolved.
- Trust that you know what's happening.
The third one is the hard one. Every customer who has been on the receiving end of a bad status page — silent, out of date, or evasive — learns to distrust the vendor. A good status page turns an outage into a relationship-building moment. A bad one accelerates churn.
The minimum useful status page
What we ship in the first version:
Current status of major components
Not every service. Group into 4-8 high-level components — API, Web App, Auth, Integrations, Dashboard. More granularity than that hides the signal in noise.
Uptime history for each component
Last 90 days visible. Green/yellow/red bars. Customers scan this before they trust your product.
Incident feed
Every incident, with timeline updates. Include the initial detection, investigation, resolution, and post-mortem link when written. Timestamps in the reader's timezone.
Scheduled maintenance
Announced in advance, with clear windows. Enterprise buyers plan around these.
Subscribe by email, SMS, or webhook
Different customers want different notification paths. All of them are cheap to support through a hosted status page provider.
Build vs buy
Statuspage (Atlassian)
The default choice for years. Mature, integrates with everything, expensive. Overkill for most SaaS under 10,000 customers.
Instatus, BetterStack, Sorry, Status.io, Cachet
Newer entrants. Cheaper, faster to set up, competitive feature sets. Instatus and BetterStack in particular are what we recommend for most clients starting out.
Self-hosted (Cachet, Kener)
Open source. Cheaper at scale, more work to run. Reasonable when the team already runs infrastructure and status page is one more service. Rarely a good early-stage choice — running a status page that itself can go down is a special kind of embarrassing.
Built into your app
Occasionally the right call. If your buyer requires the status page on your primary domain for SSO or brand reasons, building it into the app makes sense. Downside: if your app is down, your status page is too. That's the whole point of a status page being separate.
Automation — what to instrument
A hand-maintained status page is out of date within a month. Automate the mechanical parts.
Public health checks
External monitors pinging your API from multiple regions, updating the component status when they detect a problem. Every hosted status page provider has this built in.
Synthetic user flows
Beyond ping. Log in, execute a canonical workflow, verify the result. Catches degradations that a 200 response can't. Slower to set up, higher signal.
Error rate thresholds
Wire your error tracking (Sentry, BetterStack, Datadog) to auto-open a status page incident when error rates spike. Don't rely on humans noticing during business hours.
Deploy annotations
Every deploy noted on the status page timeline internally. When something breaks, the correlation is usually obvious.
How to write incident updates
The single most important skill for a status page. Good updates share three properties.
Timely
First update within 5-10 minutes of incident detection. Silence is worse than uncertainty. "We're investigating an issue with the API" is fine. Say something.
Specific about scope
Which customers are affected? Which regions? Which functionality? Vague updates ("some users may see errors") multiply support tickets because everyone assumes they're the ones affected.
Honest about timeline
Estimates are hard. "We expect to have a fix deployed within the hour" is fine if you believe it. Never say "resolved" unless it is. Customers hate the "resolved" reversal more than they hate a long incident.
Format
Roughly the sequence we use:
- Investigating — we've seen the problem, we're looking.
- Identified — we know the cause.
- Monitoring — fix is deployed, watching to confirm.
- Resolved — confirmed working, post-mortem to follow.
Post-mortems — the trust multiplier
Publishing a post-mortem after every significant incident is one of the highest-ROI communication moves an early-stage SaaS can make. It converts an outage from "they had problems" to "they take reliability seriously."
Structure that works:
- What happened, in one paragraph.
- Timeline of detection and response.
- Root cause, in plain language.
- What went well.
- What we're changing to prevent it.
Skip corporate language. Customers can tell when a post-mortem is written for lawyers instead of them.
Common mistakes
Hosting the status page on your own infrastructure. When the app is down, the status page needs to be up. Use a hosted provider or at minimum a separate infrastructure and domain.
Too many components. Twenty granular services on the status page turns the signal into noise. Group aggressively.
Silent status pages during outages. Every minute without an update generates more support tickets. Communicate first, investigate second.
Automating incident creation without human confirmation. A flaky check that opens and closes incidents makes your status page look chaotic. Automate detection; require a human to publish.
Not linking to it from the app. If a customer sees an error, they should see a link to the status page in the error message. Don't make them Google for it.
Trade-offs
A public status page increases accountability. Every incident becomes visible. Some teams see that as a downside — it exposes reliability problems that would otherwise stay quiet. In practice, hiding problems doesn't work at scale. Customers notice regardless; the question is whether you're the one telling them.
Historical uptime metrics also become part of the sales conversation. If your uptime is genuinely bad, publishing it accelerates the pressure to fix it. That's usually a good thing, but it's a real commitment.
Our note on on-call for small teams covers the operational side of running the response.
Common misconceptions
"Only enterprise SaaS need a status page." Any SaaS with paying customers benefits from one. It's a $30-100/month feature that closes deals and calms customers.
"We'll add one after we have an incident." Adding a status page in the middle of an incident is impossible. Set it up beforehand and hope it stays green.
"Status pages hurt customer trust by exposing problems." The opposite. Silent SaaS with hidden problems lose trust faster than transparent ones with visible problems.
Frequently asked questions
Final take
A status page is a low-cost, high-trust feature every SaaS with paying customers should ship. Use a hosted provider unless you have a specific reason not to. Group components sensibly, automate the detection, and communicate incidents in plain language. When something goes wrong — and it will — a well-run status page turns an outage from a churn risk into a trust-building moment.
If you're scoping incident communication for an enterprise-facing product, book a call. We can review your setup in an hour.
FAQ
Frequently asked questions
Which status page provider should I use?+
For a new SaaS, Instatus or BetterStack are the best value — cheap, modern, feature-complete. Statuspage by Atlassian is the enterprise default but overpriced for teams under 10,000 customers. Self-hosted options exist but rarely make sense before real scale.
Should the status page be automated?+
Detection yes, publishing usually no. Automated health checks catch problems fast, but automated incident publishing can create false alarms during network blips. The right pattern is auto-detect, alert an on-call engineer, and let a human publish the incident with real language.
How many components should I list on the status page?+
Four to eight major components — API, Web App, Auth, Integrations, and so on. Beyond that, the signal turns into noise. Customers want to know if their workflow is affected, not the state of every microservice.
Do I need to publish post-mortems publicly?+
Not required, but highly recommended for enterprise-facing products. A well-written post-mortem after a significant incident is one of the best trust signals a SaaS can send. Keep them honest and specific, and skip legal-speak.
Where should the status page live — on my domain or a separate one?+
Separate infrastructure, and ideally a separate domain (status.yourcompany.com pointing at a hosted provider). If your app's DNS or hosting has a problem, the status page needs to still work. Same-domain status pages fail in exactly the moments they're needed.
Building something similar?
Let's talk in 30 minutes.