On this page
When your service goes down, one page suddenly becomes the most important thing you publish: your status page. Handled well, it absorbs a flood of "is it just me?" tickets and turns a bad moment into a display of competence. Handled badly — or missing entirely — it leaves customers refreshing your homepage, filling your inbox, and guessing.
The short version
- During an incident, a status page is your highest-traffic, highest-stakes surface.
- Show overall status, per-component health, uptime history, incidents, and maintenance.
- Acknowledge fast, then update on a predictable cadence — even before you have a fix.
- Honesty about downtime builds more trust than silence; customers already know it's down.
- Let people subscribe, so the page reaches them instead of waiting to be checked.
Why a status page matters
A status page does three jobs at once. It deflects support load — one clear banner answers the question hundreds of customers are about to ask. It sets expectations — "we know, we're on it, next update in 30 minutes" defuses the anxiety that turns an outage into a reputation problem. And over time it builds credibility — a public history of incidents handled transparently is stronger proof of reliability than any "99.9%" on a marketing page.
In short
What a good status page shows
- Overall status, at a glance. One unmistakable banner — "All systems operational" or "Major outage" — readable in half a second.
- Per-component breakdown. API, dashboard, payments, each as its own line, so a partial outage reads as partial. It reassures the customers who aren't affected.
- Uptime history. A rolling 90-day grid per component. It contextualizes today's blip against a long green record.
- Active incidents. A timestamped, reverse-chronological log of updates while something is wrong.
- Scheduled maintenance. Upcoming planned work, posted ahead of time so it's expected, not alarming.
Public vs private
A public page is the default and usually right: it's SEO-friendly, deflects the most tickets, and signals confidence. A private or password-protected page makes sense when your customer list is itself sensitive, when you're an agency or MSP showing a client only their own services, or when a contract restricts who can see operational detail. Many teams run both — a public apex page and per-client private pages.
Writing incident updates
Most of a status page's value is created in the first ten minutes of an incident, in how you write. A workable lifecycle and template:
1. Investigating (post within minutes)
Don't wait for a diagnosis. "We're investigating reports of errors on the API and will update by [time]." Acknowledgement is the message; the details come later.
2. Identified
"We've identified the cause as [plain-language summary] and are working on a fix." No blame, no deep internals — just enough that customers know it's understood.
3. Monitoring
"A fix has been applied and we're monitoring recovery." Sets the expectation that it's not fully closed yet.
4. Resolved
"This incident is resolved. All systems are operational." For anything major, follow up later with a brief post-mortem — what happened and what you're changing.
Cadence and tone
- Be predictable. Always say when the next update will come, and hit that time even if the update is "still working on it." A promised update that arrives on schedule is itself reassuring.
- Be human, be plain. Write for the customer, not the on-call engineer. "Logins are failing" beats "auth service returning 503 on token exchange."
- Don't over-promise. Avoid guessing an ETA you can't hit. "Next update in 30 minutes" is a promise you can keep; "fixed in 10 minutes" usually isn't.
Planned maintenance
Scheduled maintenance is the easy win most teams skip. Post the window ahead of time and two good things happen: customers plan around it, and — if your monitoring is wired up — you can suppress the down alerts it would otherwise trigger, so your team isn't paged for work they planned. That's the same alert-suppression discipline from taming alert fatigue, applied to the public surface.
Let people subscribe
A status page that waits to be visited only helps the customers who think to check it. Let people subscribe — email, or webhook for the technical crowd — and each incident update pushes to them automatically. This flips the page from passive to active and is often what most reduces "is it down?" tickets, because your most anxious customers now hear from you first.
Tip
Common mistakes
- Hosting the status page on the same infrastructure it monitors. When you're fully down, so is your status page. Keep it independent.
- Going silent mid-incident. A gap between updates reads as "they've lost control." Keep the promised cadence.
- Marking things resolved too early. Premature "all clear" followed by a relapse burns trust twice.
- Engineer-speak. Stack traces and internal service names belong in your incident channel, not the customer-facing page.
- Never posting a post-mortem. For major incidents, the follow-up is where trust is rebuilt.
A status page is the public half of good incident response; private, well-tuned alerting is the other half. Ensju includes status pages with per-component uptime history, incidents, scheduled maintenance, email subscribers, custom domains, and optional password protection — so detection and communication live in one place. If you're setting up the detection side first, start with what uptime monitoring is.
Frequently asked questions
- What should a status page include?
- An at-a-glance overall status, a per-component breakdown, a history of recent uptime, an active-incident area with timestamped updates, and scheduled-maintenance notices. A way to subscribe for updates is what turns it from a page people check into one that reaches them.
- Should my status page be public or private?
- Public is the default and usually the right call — it deflects support tickets and signals confidence. Use a private, password-protected page when your customer list or infrastructure details are sensitive, or when contracts require restricted access.
- How often should I post updates during an incident?
- Post an initial acknowledgement fast, even before you have a diagnosis, then update on a predictable cadence — every 30 minutes during an active major incident is a good default — plus whenever the situation materially changes. Predictability matters more than perfect information.
- Does a status page hurt my brand by admitting downtime?
- The opposite. Hiding downtime doesn't make it invisible — customers experience it either way. A clear, honest status page turns a frustrating outage into evidence that you're on top of it, which builds more trust than pretending nothing happened.