10 ms·

GitHub no longer publishes aggregate numbers so here they are parsed out. It looks like they are down to a single 9 at this point across all services: https://

by mrshu 7mo ago

GitHub no longer publishes aggregate numbers so here they are parsed out. It looks like they are down to a single 9 at this point across all services: https://mrshu.github.io/github-statuses/ https://mrshu.github.io/github-statuses/

gordonhart 7mo ago
Great project, thanks for building and sharing!
jeltz 7mo ago
Do I misunderstand or does your page count today's downtime as minor? I would not count the web UI being mostly unusable as minor. Does this mean GitHub understates how bad incidents are? Pr has your page just not yet been updated to include it?
- onionisafruit 7mo ago
  Today's isn't accounted for on that page yet
onionisafruit 7mo ago
It's interesting to see that copilot has the worst overall. I use copilot completions constantly and rarely notice issues with it. I suspect incidents aren't added until after they resolve.
- nightpool 7mo ago
  Completions run using a much simpler model that Github hosts and runs themselves. I think most of the issues with Copilot that I've seen are upstream issues with one or two individual models (e.g. the Twitter API goes down so the Grok model is unavailable, etc)
everfrustrated 7mo ago
Nice! I still remember the old GitHub status page which showed and reported on their uptime. No surprises they took it offline and replaced it with the current one when it started reporting the truth. EDIT: You mention this with archive.org links! Love it! https://mrshu.github.io/github-statuses/#about https://mrshu.github.io/github-statuses/#about
Anon1096 7mo ago
> It looks like they are down to a single 9 at this point across all services That's not at all how you measure uptime. The per area measures are cool but the top bar measuring across all services is silly. I'm unsure what they are targeting, seems across the board it's mostly 99.5+ with the exception of Copilot. Just doing math, 3 (independent, which I'm aware they aren't fully) 99.5 services brings you down to an overall "single 9" 98.5 healthy status but it's not meaningful to anyone.
- munk-a 7mo ago
  It depends whether the outages are overlapped or not. If the outages are not overlapped then that is indeed how you do it since some of your services being unavailable means your service is not fully available.
  - reed1234 7mo ago
    They are overlapped. You can hover over the bars and some bars have multiple issues.
  - mynameisvlad 7mo ago
    I mean, there's a big difference between primary Git operations being down and Copilot being down. Any SLAs are probably per-service, not as a whole, and I highly doubt that someone just using a subset of services cares that one of the other services is down. Copilot seems to be the worst offender, and 99% of people using Github likely couldn't care less.
  - lxgr 7mo ago
    There's limits to that type of logic. Otherwise, as long as a single elevator or water fountain in any Google satellite office were out of order, would you consider Google "not fully available"?
zombot 7mo ago
> GitHub no longer publishes aggregate numbers Probably would be too obvious how badly M$ fucked this up.

by mrshu 7mo ago

gordonhart 7mo ago

Great project, thanks for building and sharing!

jeltz 7mo ago

Do I misunderstand or does your page count today's downtime as minor? I would not count the web UI being mostly unusable as minor. Does this mean GitHub understates how bad incidents are? Pr has your page just not yet been updated to include it?

onionisafruit 7mo ago
Today's isn't accounted for on that page yet

onionisafruit 7mo ago

It's interesting to see that copilot has the worst overall. I use copilot completions constantly and rarely notice issues with it. I suspect incidents aren't added until after they resolve.

nightpool 7mo ago
Completions run using a much simpler model that Github hosts and runs themselves. I think most of the issues with Copilot that I've seen are upstream issues with one or two individual models (e.g. the Twitter API goes down so the Grok model is unavailable, etc)

everfrustrated 7mo ago

Nice! I still remember the old GitHub status page which showed and reported on their uptime. No surprises they took it offline and replaced it with the current one when it started reporting the truth. EDIT: You mention this with archive.org links! Love it! https://mrshu.github.io/github-statuses/#about https://mrshu.github.io/github-statuses/#about

Anon1096 7mo ago

> It looks like they are down to a single 9 at this point across all services That's not at all how you measure uptime. The per area measures are cool but the top bar measuring across all services is silly. I'm unsure what they are targeting, seems across the board it's mostly 99.5+ with the exception of Copilot. Just doing math, 3 (independent, which I'm aware they aren't fully) 99.5 services brings you down to an overall "single 9" 98.5 healthy status but it's not meaningful to anyone.

munk-a 7mo ago
It depends whether the outages are overlapped or not. If the outages are not overlapped then that is indeed how you do it since some of your services being unavailable means your service is not fully available.
- reed1234 7mo ago
  They are overlapped. You can hover over the bars and some bars have multiple issues.
- mynameisvlad 7mo ago
  I mean, there's a big difference between primary Git operations being down and Copilot being down. Any SLAs are probably per-service, not as a whole, and I highly doubt that someone just using a subset of services cares that one of the other services is down. Copilot seems to be the worst offender, and 99% of people using Github likely couldn't care less.
- lxgr 7mo ago
  There's limits to that type of logic. Otherwise, as long as a single elevator or water fountain in any Google satellite office were out of order, would you consider Google "not fully available"?

zombot 7mo ago

> GitHub no longer publishes aggregate numbers Probably would be too obvious how badly M$ fucked this up.