Status pages deserve better
3m readPeter Pettas
Most public status pages are ugly. Not "oh, it needs a designer" ugly. Systematically, architecturally, on-purpose ugly, in the same way a DMV office is ugly — built for a function no one is trying to perfect.
That's a problem, because a status page is the one thing your users read precisely when they are furious with you.
What a status page actually is
A status page is not a monitoring dashboard. A monitoring dashboard is for the engineer on call; its job is to be dense, comprehensive, and quick to scan. A dense dashboard is good.
A status page is for the customer whose checkout just broke at 4:58pm on a Friday. Its job is to load instantly, tell the truth in one sentence, and get out of the way. A dense status page is hostile.
Almost every major vendor conflates these two documents and ships the dashboard to the customer.
What we stripped out
When we were designing PingPane's public page, we started with a long list of things we were not going to include:
- No tabs. The page is a page, not an application.
- No filter controls. You either want the status or you don't.
- No incident categorization UI. Users don't want to click "view all incidents tagged: networking"; they want to know whether the thing they were trying to do works.
- No region selector. If it matters that one region is out, say that in the incident body.
- No "subscribe via Twitter" or "share to Facebook" buttons. A status page isn't a growth surface.
What remained was the skeleton of the thing: one line of truth, the monitors, the incidents, and a subscribe form tucked into the corner for readers who want the follow-up email.
The one line of truth
Pick one sentence. Put it above the fold. Make it the biggest text on the page. It is the only thing most readers will read.
At PingPane, that sentence is one of three:
- All systems operational
- N systems degraded
- Major outage in progress
Nothing else. No "mostly up," no "partial incident affecting some regions." Either it works or it doesn't. If you need nuance, put the nuance in the incident body, not the hero.
The dot that pulses
We put a 12px green dot above the one line of truth, and we made it pulse at three seconds. A JavaScript dev will tell you it should be driven by WebSocket updates. It isn't. It's a CSS keyframe. The whole page re-renders every thirty seconds via ISR and the dot keeps pulsing in between.
The page feels alive because something on it is moving. It doesn't have to be real-time to feel real.
Users read "this page was generated seconds ago" without reading it. It is the oldest trick in interface design and it keeps working.
What we added back
We added back exactly one thing: a ninety-day barcode underneath each monitor, two pixels wide and sixteen tall. A failed day is a red rectangle; a successful day is green; a day with no data is dim. You can read a year of reliability in three seconds.
It is the closest thing we ship to a "data visualization" and it only exists because the information it encodes — "has this been reliable, yes or no" — is what the user actually wants.
Everything else is noise.
Related
- TransmissionWhy we check every minute, not every five Most monitoring tools default to a five-minute interval. Here's why PingPane Pro ships with sixty seconds and why the difference matters.
- TransmissionThe quiet hours An alert you ignore is worse than no alert at all. How PingPane thinks about signal, noise, and the cost of the wrong notification at 3am.
- ManualGetting started with PingPane Wire up your first monitor and a public status page in under a minute.
- ProductStart monitoring free Three monitors free forever. No credit card.