At 9:12 the site stops responding. At 9:45 someone creates a Notion page "Incident status in progress". By 10:30 customers have flooded support — and social media — for lack of a single channel. A status page is not post-mortem luxury: it is trust infrastructure to build when everything works.
A public status page shows service state, incident history and alert subscriptions. Done well, it unloads support and frames incident communication. Done badly — or built under stress — it adds confusion.
What a useful page contains
| Element | Role | Common mistake |
|---|---|---|
| Split components | Site, API, mail — not one "everything" block | Global green while payment is down |
| History 90 days | Proof of seriousness | Empty page after every incident |
| Subscriptions email/RSS/webhook | Informed customers without calling | No link from footer or support |
| Planned maintenance | Fewer "is it down?" tickets | Announced the day before only |
| Separate hosting | Stays up if prod down | Status on same VPS as site |
Common tools: Statuspage (Atlassian), Cachet, Instatus, or European SaaS per GDPR constraints. The host may also provide a page — useful for their infra, insufficient for your stack.
Prepare before incident: minimal runbook
List components with technical owner and contact. Define who publishes — one named person, not vague "the team". Draft message templates: investigating, identified, monitoring, resolved. Run a quarterly fake outage with update and subscriber notification. Link the page from the site (footer, support page) and support signature.
During incident, each update follows the rule: say what you know, mark what you don't, clear timestamp. No "all fixed" before proof.
Link monitoring and status
Automate what you can: HTTP probes on critical URLs (homepage, /health, checkout API), Prometheus or UptimeRobot alerts to status webhook. Avoid auto-resolving without human validation.
The host uptime SLA does not replace your own application probes.
The peak: status page is an implicit contract with users
Hosts with public status (OVH, Scaleway, etc.) set the example for infra; your job remains translating business impact.
Decide and move forward without blind spots
Pick a tool hosted outside main production. Split four to six business-visible components. Train an on-call publisher and write message templates. Schedule a semi-annual drill: fake outage, notification, timing. Link the page from your site footer and support signature. Compare hosts with public status history via the directory.
Frequently asked questions
Need a page if the host has one?
Yes for your application layer: expired certificate, WordPress, API, checkout. OVH or AWS status does not say whether your business service works.
Which components to list?
What users see or what blocks an order: public site, API, back office, transactional email, DNS.
Same host for status and site?
Risky — if the datacenter fails, the page fails too. Prefer external SaaS or another region.
Update frequency during incident?
Every fifteen to thirty minutes minimum for major impact, even without identified cause. Silence fuels rumours.
Configure your status page on a calm day. On outage day you will have neither time nor headspace to invent it — only to fill it.