GitHub’s down. CI’s down. AI’s down. Slack’s down. That’s the new normal, and the numbers on those status pages aren’t helping anyone understand it.
Jason Gorman wrote an article called “The Wall Confronting Reliable Coding Agent Autonomy,” and he made a point that stuck with the writer of this piece: the jump from 90% to 99% reliability is just as hard as getting to 90% was. From 99% to 99.9%, it’s just as hard again.
Those numbers look small on paper. A 98.31% uptime sounds solid. A 99.99% uptime sounds nearly perfect. But the difference between them is not small at all.
What the Numbers Actually Mean
Percent uptime is a good metric for people who measure infrastructure for a living. But it’s a terrible way to tell regular users how a service is doing.
“The difference between a 6.2 and a 7.8 might not seem that big, but it represents a massive difference in magnitude.”
That quote comes from the writer’s own argument, comparing earthquake measurements to uptime percentages. A 99.9% uptime means a service can be down for a small fraction of an hour each day. A 99.99% uptime means it can only be down a tiny fraction of an hour each day. The numbers look close. The reality is not.
The Wall of Colors
When a service goes down, you visit the status page. You see a wall of colors and numbers:
- 100%
- 99.72%
- 99.09%
- 98.98%
Those numbers all look similar. They’re all As in grade school, the writer notes. But the difference between 99.9% and 99.99% is ten times smaller. Infrastructure people understand this shorthand: two nines, three nines, four nines. They swim in these numbers every day.
The Public Audience
The audience for status pages is no longer just infrastructure people. It’s everyone now. And everyone reads numbers differently.
Percent uptime requires you to understand the nonlinear significance of numbers near 100%. That’s a skill most people don’t have. An hour, though, is something everyone understands.
The Writer’s Proposal
The writer suggests a simple change. Instead of posting a percentage, companies should post the actual downtime in hours.
For example, instead of:
“GitHub Actions: 98.31% uptime.”
Say:
“GitHub Actions: 12 hours affected in the last 30 days (98.31% uptime).”
One version requires you to do the math. The other just tells you how long the service was actually down.
The Real Question
The writer’s point is not about the math itself. The math is straightforward. The point is about communication. A user wants to know how much a service has been down recently. Not how close it got to perfection.
“Dude, how much have you been down lately? Seems like a lot…”
That’s the question the status page should answer directly.
Why the Change Would Help
The change would remove the abstraction. A percentage is a standard. An hour is a lived experience.
It also makes the stakes clearer. Ten hours of downtime a month is one thing. Ten minutes a month is another. The difference is visible at a glance.
What Comes Next
The suggestion is a small one. It doesn’t require a new dashboard or a new protocol. It just asks companies to add a few words to an existing page.
Whether companies adopt it depends on whether they think their users care. The writer believes they do.
The Verdict
The writer is amused by the whole situation. The percentages are not lying. They are just hard to read. The solution is simple: show the downtime in hours.
The numbers on the status pages are not the problem. The problem is that the numbers are hiding the truth behind a wall of precision that most people don’t understand. Showing the actual downtime in hours removes that wall entirely.
That’s a small fix for a big frustration. The writer hopes someone takes it.
Get the Notebook.
The day's best stories and every fresh verdict, in plain English, in your inbox by seven. One email a day, no more.