> Copilot [has] seen a 96.47% uptime

That’s… one 9 of reliability. You could argue the title understates the problem.

> You don't need every single service to be online in order to use GitHub.

Well that’s how they want you to use it, so it’s an epic failure in their intended use story. Another way to put this is ”if you use more GitHub features, your overall reliability goes down significantly and unpredictably”.

Look, I have never been obsessed with nines for most types of services. But the cloud service providers certainly were using it as major selling/bragging points until it got boring and old because of LLMs. Same with security. And GitHub is so upstream that downstream effects can propagate and cascade quite seriously.

On the other hand: it also doesn't include instances where GitHub is painfully slow but technically usable.

These days it is very common that something like opening the diff view of a trivial PR takes 15-30 seconds to load. Sure, it will eventually load after a long wait or an F5, but it is still negatively impacting my productivity.

There have been multiple outages in the past year where they didn’t even fully report it very quickly. I’m talking the types of outages that brings down normal enterprise usage: we hook delivery for CI/CD, git operations for everyone, PRs for code review. And that’s not even including GitHub actions or copilot which lots of people also rely on.

Here is the same thing in 2019: https://web.archive.org/web/20190510070456/https://www.githu...

It seems that the same metric is about a magnitude worse than before.

96% is horrible uptime though

more context -- their enterprise SLA is 99.9% (3x9) uptime for individual services

https://github.com/customer-terms/github-online-services-sla

> GitHub commits to maintain at least 99.9% Uptime for the applicable GitHub service.

... and none of the individual services have hit 99.9% uptime in the last 90 days according to this site. 0_o

the basic git services are at one nine of availability