Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub's Historic Uptime

damrnelson.github.io

Post reply on HN
Print view View original

111–120 of 131 posts

Re: GitHub's Historic Uptime

#111

Post by bandrami »

verdverm wrote: post #33
montroser wrote: post #21

Earlier quoted context omitted.

It has been pretty rough. Their own numbers report just a single `9` for Actions in Feb 2026 with 98% uptime. But that said -- I don't get the 90% number. Anecdotally, it seems believable that 1 in 50 times (2%) in Feb that Actions barfed. Which is not very nice, but it wasn't at 1 in 10 times (10%).

It looks like the aggregate stats are more of a venn diagram than an average. So if 1/N services are down, the aggregate is considered down. I don't think this is an accurate way to calculate this. It should be weighted or in some way show partial outages. This belief is derived from the Google SRE book, in particular chapters 3 (embracing risk) and 4 (service level objectives) https://sre.google/sre-book/embracing-r…

Thinking back to when I was hosting, I think telling a customer "your web server was running fine it's just that the database was down" would not have been received well.

Re: GitHub's Historic Uptime

#112

Post by w0m »

fishtoaster wrote: post #20

Is the pre-2018 data actually accurate? There seem to have been a number of outages before then: https://hn.algolia.com/?dateEnd=1545696000&dateRange=custom&... Maybe that's just the date when they started tracking uptime using this sytem?

i assume they simply fixed the status page in 2018.. lol.

Re: GitHub's Historic Uptime

#113

Post by tbossanova »

marcosdumay wrote: post #57
verdverm wrote: post #33

Earlier quoted context omitted.

It looks like the aggregate stats are more of a venn diagram than an average. So if 1/N services are down, the aggregate is considered down. I don't think this is an accurate way to calculate this. It should be weighted or in some way show partial outages. This belief is derived from the Google SRE book, in particular chapters 3 (embracing risk) and 4 (service level objectives) https://sre.google/sre-book/embracing-r…

That's how you count uptime. You system is not up if it keeps failing when the user does some thing. The problem here is the specification of what the system is. It's a bit unfair to call GH a single service, but it's how Microsoft sells it.

As a “customer”, I consider github down if I can’t push, but not down if I can’t update my profile photo (literally did this today, sending out my github to potential employers for the first time in a long time). This stuff is notoriously hard to define

Re: GitHub's Historic Uptime

#114

Post by chenzhekl »

My impression is that, before Microsoft acquired GitHub, GitHub went for many years without really introducing new features, so part of its stability came from the fact that it wasn’t very ambitious or proactive about improving.

Re: GitHub's Historic Uptime

#116

Post by ahofmann »

chenzhekl wrote: post #114

My impression is that, before Microsoft acquired GitHub, GitHub went for many years without really introducing new features, so part of its stability came from the fact that it wasn’t very ambitious or proactive about improving.

I loved that time. Websites, or "apps" that don't change every second time I want to use them, are great.

Re: GitHub's Historic Uptime

#118

Post by hk__2 »

voxic11 wrote: post #59
hk__2 wrote: post #27

It’s biaised to show this without the dates at which features were introduced. A lot of the downtimes in the breakdown are GitHub Actions, which launched in August 2019; so yeah what a surprise there was no Actions downtime before because Actions didn’t exist.

Check the breakdown page. Like yes the magnitude is reduced obviously for individual services. But they all show the same trend.

I checked the breakdown page, as I wrote:

> A lot of the downtimes in the breakdown are GitHub Actions

Re: GitHub's Historic Uptime

#119

Post by jamiemallers »

nulltrace wrote: post #104
padjo wrote: post #68

Earlier quoted context omitted.

It feels like they launched actions and it quickly turned out to be an operations and availability nightmare. Since then, they've been firefighting and now the problems have spread to previously stable things like issues and PRs

We added Actions for CI in 2020. A year later realized our entire deploy pipeline just assumed it would be up. Webhook doesn't fire, nothing errors out, and you find out when someone asks why staging hasn't moved in two days.

[dead]

Re: GitHub's Historic Uptime

#120

Post by grayhatter »

otterley wrote: post #78
verdverm wrote: post #65

Earlier quoted context omitted.

It's an uptime chart and shouldn't need to show much more than the 99% range. If you started the y-axis at zero, you wouldn't see much of anything. Logarithmic scale would still be a bit much imo.

> If you started the y-axis at zero, you wouldn't see much of anything. That's... kind of my point. As a reliability engineer, I'm disappointed in GitHub's 99.5% availability periods, especially as they impact paying customers. On the other hand, most users are non-paying users, and a 99.5% availability for a free service seems to me to be a reasonable tradeoff relative to the potential cost of improving reliability…

> the other hand, most users are non-paying users, and a 99.5% availability for a free service seems to me to be a reasonable tradeoff relative to the potential cost of improving reliability for them.

If they are using your data, you're still paying just not in cash.

As a former reliability engineer, I'm trying hard to remember back when we had multiple months in a row never reaching 100% uptime, and I can't. Yes, we've seen runs of painful months, but also runs of easy months without down time.

But let's talk root cause here, the cost of improving them here, is someone caring. This isn't simply a hard problem, it's a well understood hard problem that no one who makes decisions cares about. Which as a reliability engineer is an embarrassment. Uptime is one of those foundational aspects that you can build on top of. If you're not willing to invest in something as core as your code or service works. What are you even doing?

Post reply on HN