A status page is the cheapest support engineer you will ever hire — provided it tells the truth, and provided someone can find it before they open a ticket.
A small SaaS product or an agency managing client sites needs a status page from the moment a second person would otherwise ask "is it just me?" — because that question, multiplied, is the support load of every incident. The page shows, per component, whether it is operating normally, degraded or down, plus any open incident with timestamped updates, and it is generated from the same monitoring that detects the problem rather than updated by hand. For agencies, a private per-client page reached by a token URL is often better than a public one: the client sees their own assets, and nobody else sees the client list. The rules that make a status page worth trusting are short: automatic, honest, and updated before the tickets arrive.
When it does not: an internal tool with twenty users who sit near you. Tell them in the channel.
| Components | The three to eight things a user would name: web app, API, login, payments, email delivery, the client's site |
|---|---|
| State per component | Operational · Degraded · Partial outage · Major outage — derived from monitoring, not typed |
| Open incidents | Title, affected components, timestamped updates newest first, current status (investigating, identified, monitoring, resolved) |
| Scheduled maintenance | Announced in advance, with a window; excluded from the SLA if your terms say so |
| History | Past incidents and uptime for the last 30–90 days, per component |
What it should not show: internal component names nobody outside recognises, every micro-service, or a green tick that is not connected to anything.
A public page suits a SaaS product: one URL, linked from the footer and from every error message, indexed so "is [product] down" finds it. A private page — reached by a token in the URL, not by login — suits agencies and B2B vendors: each client sees only their own assets, the URL goes in the onboarding email and the monthly report, and the agency's client list stays confidential. Many teams need both: public for the product, private per client for managed sites. The data behind them is the same monitoring.
Investigating — "Since 14:02 IST some users are seeing errors when saving. We are investigating. Next update within 30 minutes."
Identified — "The cause is a failed deploy at 13:58; we are rolling back. Saving may fail until the rollback completes."
Monitoring — "Rollback completed at 14:21. Error rates are back to normal; we are monitoring."
Resolved — "Resolved at 14:45. Duration 43 minutes. Affected: saving in the web app. A summary will follow in the monthly report."
Four states, each with a time, each promising the next update. That is the whole discipline. The monthly SLA report is where the fuller account goes.
| Purpose | Answer "is it just me?" before the ticket is opened |
|---|---|
| State source | Monitoring checks — automatic, never hand-edited |
| Components | 3–8 things users would name |
| Incident states | Investigating → Identified → Monitoring → Resolved, each timestamped |
| Private pages | Token URL per client; no login; client list stays confidential |
| History | 30–90 days per component; never deleted |
Yes, from the first paying users. The first outage without one produces a ticket from every affected user asking the same question. A status page driven by your monitoring answers that question automatically and cuts incident support load to a fraction, and its history becomes evidence of reliability for prospects.
Yes, but usually a private one per client rather than a public one. A per-client page reached by a token URL shows the client their own sites' state and incident history without publishing the agency's client list, and it belongs in the onboarding email and the monthly SLA report as part of the maintenance retainer.
The handful of components a user would name, each with a state derived from monitoring; any open incident with timestamped updates and a current status; scheduled maintenance; and 30–90 days of history. It should not list internal services nobody recognises or show a green state that is not connected to real checks.
Component state should be automatic, driven by the same checks that detect the failure, so the page changes before anyone has looked. Incident narrative — what users see, what is being done, when the next update is due — is written by a person, quickly, in four states: investigating, identified, monitoring, resolved.
A public page has one URL anyone can open and is right for a product with many users. A private page is reached by a secret token in the URL, without a login, and shows one client only their own assets — right for agencies and B2B vendors who do not want to publish who their clients are. The monitoring behind both is the same.
Within minutes of detection, even if it only says you are investigating and when the next update will come. The first update's purpose is to stop the tickets, not to explain the cause. Follow with identified, monitoring and resolved states, each timestamped.
Merik's Digital Operations module includes status pages that are generated from the monitoring, not typed. Each client's assets can be exposed on a private page reached by a token URL — no login, no client list — showing per-asset state, open incidents with their timeline, and history. Because component state comes from the same outside-in checks that open the incident, the page changes when the failure is confirmed, before anyone has been alerted, and returns to normal when the checks recover.
Incidents carry deploy markers from GitHub and Vercel webhooks and dependency context from vendor status feeds, so the narrative on the page can say honestly whether it was a deploy or a provider. The same data produces the monthly per-client SLA report. See the Digital Operations module.
Tiers and their minutes, the seven sections, and how to present a quiet month.
Per-client structure, what to check, who gets the alert, and pricing the retainer around it.
The first ten minutes, what not to do, honest communication, and shrinking the blast radius.