Start with the job the page has to do
A customer opens your status page for exactly one reason: something feels wrong on their end and they want to know if it's you or them, without waiting on a support reply. Every design decision on the page should be judged against that job. A choice that makes the page look better but makes the answer slower or less certain is the wrong choice.
The job reframes a few common instincts. A status page is not the place for a changelog, a features roadmap, or upbeat copy about your uptime record. The page is closer to a control room readout: current state first, evidence for that state second, history third.
What order should a status page show things in?
A worried visitor reaches an answer fastest when the page follows this reading order. Start with the current state, because the WCAG guidance on use of color says color alone should never carry the meaning.
- Your name and the current overall state, labeled in words, not just a color.
- When that state was last confirmed, and from where.
- Per-component or per-region readings.
- Any active incident, with its most recent update first.
- Past incident history, for anyone checking whether a problem is recurring.
Burying the current state below a hero image or a pricing pitch defeats the page's only job. If someone has to scroll to find out whether you're up, the page has already failed that person. Most people visit a status page only during an outage.
How granular should status page components be?
Granular enough that a customer can tell whether their specific problem is a known issue, not so granular that the page turns into an internal architecture diagram. “API”, “Dashboard”, and “Checkout” are components a customer recognizes and cares about individually. “us-east-1 RDS replica” is an implementation detail that belongs in your internal runbook, not a public component list, unless your customers are themselves infra engineers who specifically care about that layer.
Region-level state is a different, useful kind of granularity for a service with genuinely independent regions. Region-level state answers “is this affecting me specifically” for a geographically distributed customer base, which a single global badge cannot. Region is a different axis from component granularity. Keep the two separate on the page rather than merged into one confusing status grid.
When should you post the first update?
Post the first update as soon as a real problem is confirmed, before customers have to ask. The practical way to hit that bar consistently is to let your monitoring open the first draft automatically the moment a check confirms a genuine state change. The alternative is waiting on a human to notice, decide the problem is worth a post, and then write one.
A team that must manually notice and manually decide to be transparent will, under pressure, sometimes decide not to. The cause is not bad faith. Someone is busy fighting the actual fire. Google's SRE book makes the same point about incident roles in Managing Incidents: communication needs a named owner so it does not compete with debugging.
A companion guide below covers the full stage-by-stage cadence and the templates for what to write during that window.
Staying honest when the truth is inconvenient
The hardest and most valuable discipline on a status page is refusing to make the page say something better than what actually happened. Two failure modes are worth naming because they are common and easy to slide into without noticing.
- Resolved incidents that quietly disappear. A page that only shows currently active incidents and drops resolved ones from the visible history fails a customer checking “did this happen to me last week too.” That customer finds nothing, even though it did happen. Keep resolved incidents visible in a history section. The instinct to hide old problems to look better is exactly backwards. A page with an honest incident history is more credible during your next outage than a page with a suspiciously spotless one.
- A badge that stays green because the check that would catch the problem doesn't exist. A single check from one location, run once a minute, only proves that one path works. The check says nothing about a regional outage, a broken checkout flow the health check doesn't exercise, or degraded performance that hasn't crossed a hard failure threshold yet. Publishing a green badge is an implicit claim that you checked. The claim is only honest if the check covers what the badge represents. The mechanics of how this goes wrong, and what checking from multiple regions fixes, are covered in the uptime monitoring guide.
Maintenance windows deserve their own treatment
Planned downtime is not an incident and shouldn't be dressed up as one, but it also shouldn't be invisible. Announce it in advance with a start and end time. Keep it visible on the page during the window. Suppress the alerting that would otherwise page your team for downtime you scheduled yourself.
Maintenance windows follow the same honesty standard as everything else on the page. A customer who checks during your maintenance window should immediately understand why things look different, without having to guess whether the cause is a real problem.
How RealUptime Status handles this
RealUptime Status orders every public page the same way: company name and overall state first, last-confirmed timestamp and check geography second, then per-region readings, then incident detail. Incidents draft automatically from a confirmed check transition and stay visible in a resolved history instead of disappearing once closed. Maintenance windows suppress alerts without hiding the window itself from the public page.
Next