alt Hacker NewsCan we stop with the uptime percentages?
Comments
I’ve worked in systems which at worse have had three nines for years, but I’ve also worked in systems where five nines is a failure.
This attitude of modern tech claiming 98% is good just doesn’t work in the old tech acceptance. We had individual components fail all the time. We’re still looking at a 230ms outage to a branch office last week caused by a power failure combined with a badly plumbed power distribution.
Modern software people don’t consider 230ms to be an outage. Glad they don’t work in electricity.
(The failure we had was only on the services we guarentee at 99.1%, our lowest sla. After that there’s 99.95 and 99.999.
(In reality we reach five nines year after year on even the lowest levels, but there are major concerns like “large bomb in data centre” which could cause some of our less critical units to drop way more than 5 minutes a year.
Many commenters seem to think the author is saying that we should stop caring about uptime, when what he's really saying is that we should be reporting time (i.e. number of hours down in the last month) rather than just reporting an opaque percentage that hides the problem.
Separately from how you present the number, the very concept of "uptime" as a single number is a bit muddy in the context of a distributed system, where different components can be differently available for different users.
Also, 0.1% downtime in the form of a 45-minute outage per month is very different from 0.1% of requests failing in brief bursts. You often see downtime reported as "increased error rates" which is so vague as to be meaningless.
Google's "windowed user-uptime" attempts to deal with this a bit better, by exposing different views of the data instead of trying to condense uptime into a single number: https://www.usenix.org/system/files/nsdi20-paper-hauer.pdf
> We say something like:
> GitHub Actions: 12 hours affected in the last 30 days (98.31% uptime).
This is trying to shine the most favorable possible light onto a deteriorating situation. It doesn't take away from the fact that most businesses have measurable missed revenue in downtime. Customers that shop somewhere else, ads that were never severed, leads that grew a little colder. 12 hours of downed GitHub results in millions of dollars of lost developer productivity that was externalized by Microsoft to other companies.
We shouldn't be trying to spin downtime as "just a few hours a month." Those hours cost real dollars.
I don't really care about percentages, either. But for some industries, the difference between "two 9s" and "five 9s" can be millions of dollars, so that's why they're published that way to the customer.
Not sure if some one already mentioned, these numbers are rarely for general public
1. These are core to the (service level agreements) SLA's for the enterprise companies when they evaluate and sign the contract (must for government RFPs)
2. The contracts generally have provisions for payback or penalties for missed SLAs
3. When your product depends on any of the products directly then the availability of your product has to take into account the availability of the dependent services. Eg, I can easily sell a SLA of two nines for my service if I am building it on a platform which has SLA of three nines, other way around is always questionable (though possible)
4. All of this is what used to happen may be up until 5 years ago. As of today even with good number of outages, company like AWS has not updated their availability to reflect those outages. Ideally all the companies built on top of AWS infrastructure would have to update their availabilities in a cascading manner but some how everyone decided to skip the beat
5. At this point, calculation of the availability itself has become so opaque that no one understands it anymore so no one questions it either
One advantage of percentages is that you can multiply them if the outages aren't related. If you rely on 10 systems with a 99% uptime each you end up with roughly 90% uptime in total.
I wrote a blog [1] last week about what we've been doing at Depot to work around GitHub's instability. I wrestled with how to present their downtime in a way that communicates its real impact to users, and I landed on a similar approach as the author. But I think even this doesn't state it strongly enough. Their uptime stat comes from their public status page, so it's conservative by definition. And it's important to remember that their downtime comes almost exclusively during business hours, when people are relying on the platform to get work done.
There are projects like The Missing GitHub Status Page [2] that attempt a more accurate reporting, but taking 98.31% for granted, I think the more impactful framing would be _a floor_ of 1.5 business days lost every month. At 22 business days per month, that can feel more like 7+% downtime.
These numbers are useful proxies for how likely you are to have your work disrupted outside of your own control.
If you do something 100 times a day against a four-nines service, you can reasonably expect that everything will succeed.
If you do something 10,000 times a day against a two-nines service, you can expect to hit a substantial number of errors during that day, or even have long periods where your work cannot happen at all.
People aren't frustrated with Github because Github has 98% uptime or whatever the specific number is. They're frustrated because it regularly interferes with their ability to work. The 98% number is just a concise way to say it.
One thing that is I feel missed about uptime percentage when compared to on premise uptime is when the downtime occurs. Its far more impactful if its in the middle of the working day or during the busy period of shopping. A store that goes offline in the middle of black friday or in the run up to Christmas is harmed a lot more than some down time on a Sunday night/Monday morning at 3am.
One thing I have noted over time is a lot of these AWS, Azure et el downtimes is they occur in the middle of everyones day, millions of people are impacted by them. Same with github its getting in the way of work. Whereas when we hosted services on our own equipment the downtime was usually out of main hours. The percentages are in many ways the wrong measure of downtime because hours aren't equal in impact to businesses.
We've stopped with our caring about quality and understanding so I don't see why we'd keep caring about reliability and availability. How are you going to pinpoint performance issues when you have no idea how your app works?
Point the AI at your logs, tell it to fix things, rinse and repeat. It's faster than debugging, and fast is good.
I usually tell people you don't need as much reliability as you think.
Three nines reliability is great for most purposes. 8 hours downtime a year.
If your system produces money at a constant rate, it captures 99.9% of the available money. Even two nines or one nine might be pretty good on that basis, when the alternative is spending 2x or 10x as much - let's build another unreliable system with that money that captures some other independent market opportunity.
Poor reliability is a problem where you need to chain many systems together, or where the cost of a single failure is very large compared to a success. Or - as happens commonly because of load - if your periods of unreliability are correlated with periods of maximum opportunity, like an e-commerce site failing on Black Friday or a trading system failing when the market is most busy. But if you don't have one of those cases, evaluate whether investing in reliability is actually worth it to you.
GitHub is an example where two nines of reliability ought to be OK. The argument against it is that it's bad marketing to have an unreliable service, especially one aimed at software engineers. And if GitHub is largely a marketing play by Microsoft anyway (do they really make back its cost in enterprise subscriptions?) then marketing considerations need to drive its reliability.
You can use -log10(1-p). On the "nines" it is exactly the number of nines you have:
$ python3
Python 3.12.3 (main, Aug 31 2026, 10:18:26) [GCC 13.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> def nines(num):
... return -math.log10(1-num)
...
>>> nines(.9)
1.0
>>> nines(.99)
1.9999999999999996
>>> nines(.999)
2.9999999999999996
Which then smoothly covers the entire space:
>>> nines(.9321)
1.1681302257194985
>>> nines(.2)
0.09691001300805639
I think this idea is objectively good, but practically hazardous. "Four nines" is a meme at this point, and it's a helpful one: a commonly understood gold standard. Few people know that translates to roughly 4 minutes and 19 seconds of downtime per month. Since service quality is degrading, I fear that changing the way we express those uptime might also unintentionally provide convenient cover to reset expectations, e.g. 10 minutes of downtime is the new norm for reliability. Or 30 minutes. I don't think we should yield the Overton Window, so to speak, to this.
These service status pages have so many other problems, I can't really get excited about this article's point. As a user of a service, I don't really care that an additional 0.09% of uptime is any more or less difficult to achieve than an additional 0.9%, even if you describe it in terms of fractions of time. I only care about two things: what the service status is right now and your service reliability's impact to me over the long term (get out of here with your 30-day crap).
In the electric utility world we have a few IEEE standardized metrics (with appropriately IEEE'd acronyms) for tracking service reliability that I like much better and always wish for when I'm looking at a status page. Pie in the sky stuff for sure, nobody wants to do this analysis and publish the results without a regulator telling them have to, but c'est la vie.
SAIDI - System Average Interruption Duration Index. How many minutes an average customer experienced service interruption in a year. This is the big one I'd want to see on your service status page IMHO. For the power grid, we consider any outage longer than five minutes to be an interruption ("non-momentary outage").
SAIFI - System Average Interruption Frequency Index. How many total periods of interruption occurred for the average customer in a year.
CAIDI - Customer Average Interruption Duration Index. How long it takes service to be restored for the average customer when there is an interruption.
For the US, here is what these numbers look like: https://www.eia.gov/electricity/annual/html/epa_11_03.html. If you're outside the US look up yours and have a good laugh at us. :)
For the "right now" aspect you have probably visited your utility's outage map, but here I would say we do much better than most utilities. The level of detail on the investigation and resolution is often more detailed, and we usually know better than to bother providing much in the way of a concrete estimate for restoration time of a current outage (though this is getting better in the utility space).
As more and more things we might consider "platform" move to the cloud, I think it also matters what the service provider means by saying it's up. Just because the servers are alive and responding doesn't mean the platform is really functional.
One vendor in particular we deal with has a powerful feature which we use to a large extent. Unfortunately, that particular feature is all too often not working. The servers are up and the rest of the platform is working, but we need that feature, so if it's down, it doesn't help much that the rest of the platform is up.
These metrics tend to be bullshit in contracts.
For example we had a 6 9 (99.9999%) requirement from a customer for any given 3-6 month period. If we violated that, we owed them their money back (baring the outage wasn’t caused by us - I.e our cloud provider shit the bed).
That’s something like 7.5 seconds. For a contract over $1.5M. Am I the only one who thinks that’s outrageous expectations?
EDIT: The web app was for generating SBOMs of static assets.
The 12 hours out of 30 days seems like sugarcoating the issue.
Keep the percentages, and regardless of that - GitHub fix your uptime
One 12 hour outage is different to 12 1 hour outages at 3am which is different to 24 30 minute outages at 4:30pm when you're trying to commit something at the end of the day. Percentage and time are both flawed ways of looking at downtime.
Downtime really matters if it's at a time you need something to be up, and Github is big enough to have users for that to be all the time. That moves the conversation from 'It's down for a few hours a month' to 'Github is failing a significant number of it's users'.
I'm also not sure that all downtime is really properly measured now as more and more services are connected and intertwined.
Some measure quite detailled but some just don't summarize the downtime from all providers up and below their own platforms.
Mentally convert to downtime: 99.8 is clearly twice as bad as 99.9
Similar for LLM measures from an ideal 1.0 mark.
Until there is an industry wide definition of outage, degraded performance, etc then it's all moot
Yeah, this is always fun. Logarithmic graphs of downtime, people.
Funny this was posted a few hours after a Salesforce global outage
The job of the uptime numbers are to look good (and sometimes to meet contractual obligations), more context doesn't make them sound better. Not being understood in layman's terms is a feature.
These companies are happy that you don't know the difference between 99%, 99.9%, and 99.99% and that you think they all sound pretty good.
`-log10(1 - uptime)`
Its not for you, its advertisement, to preemptively avoid both consumer and securities fraud accusations, and for their enterprise client’s IT security review and SLAs
My b
> So how about, and I’ll just throw this out there, instead of: > > GitHub Actions: 98.31% uptime. > > We say something like: > > GitHub Actions: 12 hours affected in the last 30 days (98.31% uptime).
The suggested format is equally unhelpful.
You can get 12 hours of downtime by being down once for 12 hours, or 144 times for 5 minutes. The user experience is VERY different in those two cases.
Ultimately the graphs are the most useful format.
Services can have a 50% uptime (or a 50% downtime if you prefer) as long as it's the time when I need it to be up (or don't need it.)
Which is to say that the significance of downtime depends on the user. Talking about nines only makes sense internally when you are evaluating your infrastructure and operations. It doesn't tell you squat about impact to your customer.
They want to move goal posts of integrity because it makes their slop factory value proposition work better
Can we post uptime stats instead? I just axed two of my servers from colocation a couple of days ago. Sad to see them go, six years of FreeBSD.
root@vixen:/fountain/crystals #
*** FINAL System shutdown message from dblrabbit@ ***
System going down IMMEDIATELY
System shutdown time has arrived
root@vixen:/fountain/crystals # uptime
3:05PM up 1931 days, 18:13, 0 users, load averages: 1.01, 1.03, 1.41
root@cookie:/srv/users/dblrabbit # uptime
3:07PM up 1931 days, 16:59, 1 user, load averages: 1.76, 1.17, 1.06
root@cookie:/srv/users/dblrabbit # poweroff
Shutdown NOW!
poweroff: [pid 47177]What's the point here? That everyone should use the n-nines notation? Sure. However, companies have no interest in doing anything that makes them look worse.
Also, is anyone else getting the bitter taste of AI writing from this page?
Wider audience started to use status pages because the service unreliability became so much more noticeable than before and not the other way around. I never had to use a status page for bear blog or protonmail because i never had and issue with it or just i never noticed.
I am now _required_ to consult status page of github, circleci or MS services etc because i need to know why a build is not passing, why i cannot open a repo, why is my work stalling.
Percentages matter, it is just so much more obvious why they matter when it comes down to important pieces of the internet like github. And i highly doubt the number of 12 hours in the last month. MS has been downplaying the issues they have with GH performance for a while now and i don't think it is time to start to believe them yet. Maintaining these pieces of infrastructure is responsibility and a burden.
Overall i would be careful with "nonlinear significance of numbers near 100%" we are talking gh being well into the 90's this year and one number that infra people are also often being reminded about is that "1% is 3.5 days".
Things are tough for gh people and i feel for them but they are not a startup or a underdog of some sort to receive sympathy in that case.