A status page does one job: it tells a customer whether they should keep debugging their own system or stop and wait for yours. Most status pages fail because they are written for legal safety, not user action.
“Investigating degraded performance” is not useful. Which product area? Which region? Which customer path? Can a user retry? Should they pause writes? Is the data delayed or lost? The page is not there to preserve your optionality. It is there to reduce the number of people making bad local decisions during a shared failure.
The minimum useful page
Three things belong above the fold:
- What is broken. Name the workflow, not the internal service.
- Who is affected. Give the boundary as honestly as you know it.
- What to do now. Retry, wait, use a fallback, or do nothing.
Everything else is secondary. The timeline matters. The root cause matters later. The first screen is triage.
The best status pages read like product copy because they are product copy. They have an audience, a job, and a failure mode. Treat them that way before the incident, not during it.