Running a Public Status Page: Content, Custom Domains and Outage Transparency
When your service is down, users do one of two things: open your status page, or — if you do not have one — open Twitter and assume the worst. A public status page is cheap insurance: it converts a communication vacuum into a factual, timestamped record, and it measurably reduces support load during incidents because “check the status page” answers most tickets before they are written.
What to include
Useful status pages share a small set of elements:
- Per-component current state: API, dashboard, mail, each integration endpoint. One aggregate “all systems operational” hides partial failures that matter to specific users.
- 30-day uptime percentage: long enough to smooth over a single incident, short enough to stay relevant. A year-long number hides recurring flakiness; a 24-hour number panics over nothing.
- Incident history for the last 7 days plus a browsable archive: start time, duration, affected components, resolution note. The archive is what builds trust over time — patterns (“database failovers every second Tuesday”) become visible to you before they become visible in churn.
- Timestamped updates during the incident: even “we are still investigating, next update in 30 minutes” beats silence. Users forgive failures; they do not forgive being ignored.
Custom domains and TXT verification
Hosting the page on status.vendor-platform.com works but looks transient. Most status platforms let you serve it from status.yourdomain.com, which raises a security question: how does the platform prove it may speak for your hostname? The standard answer is DNS verification — you add a TXT record with a token the platform generated:
status.yourdomain.com. IN TXT "whodns-status-verify=9f2c41ab…"
The platform queries _whodns-status.yourdomain.com (or its chosen label), finds the token, and binds the custom domain to your account. This prevents a squatter from pointing an arbitrary status page at your brand. Keep the record after verification; some platforms re-check periodically.
Outage communication that works
- Post the first acknowledgment within minutes, with an affected-components list even if incomplete.
- Update on a stated cadence — “next update in 20 minutes” — and honour it even if the update is “no change”.
- After resolution, write a short summary with a timeline; link monitoring data if the platform shows it.
- Never delete or edit past incident entries into vagueness. The archive’s honesty is its value.
- Keep the status page on separate infrastructure from the product. A status page served by the same load balancer that just failed tells users only that everything, including your transparency, is down — that failure mode is the strongest argument for a hosted or independently hosted page.
The public status pages feature on WhoDNS turns your existing uptime monitors into a shareable page: up to five pages, each showing 30-day uptime, the last 7 days of incidents, and optional custom domains verified with a TXT record — so transparency costs you one configuration screen, not a separate subscription.