4 ms·

The graph in TFA shows the downtime pattern starting in January 2020. OpenAI released GPT-3.5 in November 2022 (basically December), and LLM/agentic coding didn

The graph in TFA shows the downtime pattern starting in January 2020. OpenAI released GPT-3.5 in November 2022 (basically December), and LLM/agentic coding didn’t really kick off in the way you’re describing until 2024, but really in 2025. How can that explain the terrible uptime for the ~4 years post acquisition before all the AI stuff you’re talking about started?

johnfn 5mo ago
The subjective experience I and others report is that GitHub feels to have gotten significantly worse over the last few months. If you look at the month over month view of "Uptime history" in the cited link[1], it confirms this: it's been sub-90 (even sub-80 last month) essentially since the start of this year (i.e. when GitHub says that commit activity 10xed). Go back even a year and it's all in the high 9s. I honestly can't explain the discrepancy between the graph in the article and the month over month stats on the same page, but the latter tracks both to my own subjective experience of GitHub and their own internal metrics. [1]: https://mrshu.github.io/github-statuses/ https://mrshu.github.io/github-statuses/
silverwind 5mo ago
I think it's just a case of brain drain, followed by reckless AI adoption which both drove the quality down.
chilmers 5mo ago
The graph is not accurate, because GitHub's historical downtime data is not accurate. For example, here is a Hacker News story about GitHub being down on July 28th 2016: https://news.ycombinator.com/item?id=12178449 https://news.ycombinator.com/item?id=12178449 Here's GitHub's historical uptime graph (on which this chart is based), saying there was no recorded downtime that day, or in fact that entire month: https://www.githubstatus.com/uptime?page=40 https://www.githubstatus.com/uptime?page=40
- antiframe 5mo ago
  Looks like it's not accurate by under repporting not over reporting. So their down time was likely worse!
  - RadiozRadioz 5mo ago
    We don't have enough data to confirm if it's over or under reporting. This sample size of 1 is enough to prove the data is not perfectly accurate, but it's not enough to prove a skew bias in the data either way.
    - Petersipoi 5mo ago
      Oh please, show me a company that has ever over reported their downtime. That's silly.
    - antiframe 5mo ago
      That's fair. We don't know. I am making an assumption that if Microsoft saw a lot of false positive outages they would fix that, but might drag their feet if there was an outage that didn't get properly recorded (assuming it's automatic to begin with, it might be that a human needs remember to update it).
  - ncruces 5mo ago
    Or things didn't change much at all except Microsoft forced them to be more honest in their reporting. See, I can just as easily make up a story that explains the chart.
- abraham 5mo ago
  GitHub launched a new status page Dec 2018[1]. It doesn't appear as if any history before Oct 2018 was ported over. [1] https://github.blog/engineering/infrastructure/introducing-the-new-github-status-site/ https://github.blog/engineering/infrastructure/introducing-t... [2] https://web.archive.org/web/20181211191456/https://www.githubstatus.com/history https://web.archive.org/web/20181211191456/https://www.githu...
- starkparker 5mo ago
  That graph has bugged me since it went viral. The methodology is horseshit: https://github.com/DaMrNelson/github-historical-uptime https://github.com/DaMrNelson/github-historical-uptime Just dumping HARs from devtools from a status site that hallucinates 100% uptime when it has no data. For example, all GitHub services had 100% uptime in June 1996: https://www.githubstatus.com/uptime?page=200 https://www.githubstatus.com/uptime?page=200 The graph gives GitHub Actions 100% uptime before it launched to GA in November 2019. That factors into the average uptime for every month on the graph before that. It's fully horseshit.
MallocVoidstar 5mo ago
The graph in the article is a lie, because GitHub's "historical data" is a lie. https://www.githubstatus.com/uptime?page=3000 https://www.githubstatus.com/uptime?page=3000 According to it, GitHub had 100% uptime from June to August 1996.

johnfn 5mo ago

The subjective experience I and others report is that GitHub feels to have gotten significantly worse over the last few months. If you look at the month over month view of "Uptime history" in the cited link[1], it confirms this: it's been sub-90 (even sub-80 last month) essentially since the start of this year (i.e. when GitHub says that commit activity 10xed). Go back even a year and it's all in the high 9s. I honestly can't explain the discrepancy between the graph in the article and the month over month stats on the same page, but the latter tracks both to my own subjective experience of GitHub and their own internal metrics. [1]: https://mrshu.github.io/github-statuses/ https://mrshu.github.io/github-statuses/

silverwind 5mo ago

I think it's just a case of brain drain, followed by reckless AI adoption which both drove the quality down.

chilmers 5mo ago

The graph is not accurate, because GitHub's historical downtime data is not accurate. For example, here is a Hacker News story about GitHub being down on July 28th 2016: https://news.ycombinator.com/item?id=12178449 https://news.ycombinator.com/item?id=12178449 Here's GitHub's historical uptime graph (on which this chart is based), saying there was no recorded downtime that day, or in fact that entire month: https://www.githubstatus.com/uptime?page=40 https://www.githubstatus.com/uptime?page=40

antiframe 5mo ago
Looks like it's not accurate by under repporting not over reporting. So their down time was likely worse!
- RadiozRadioz 5mo ago
  We don't have enough data to confirm if it's over or under reporting. This sample size of 1 is enough to prove the data is not perfectly accurate, but it's not enough to prove a skew bias in the data either way.
  - Petersipoi 5mo ago
    Oh please, show me a company that has ever over reported their downtime. That's silly.
  - antiframe 5mo ago
    That's fair. We don't know. I am making an assumption that if Microsoft saw a lot of false positive outages they would fix that, but might drag their feet if there was an outage that didn't get properly recorded (assuming it's automatic to begin with, it might be that a human needs remember to update it).
- ncruces 5mo ago
  Or things didn't change much at all except Microsoft forced them to be more honest in their reporting. See, I can just as easily make up a story that explains the chart.
abraham 5mo ago
GitHub launched a new status page Dec 2018[1]. It doesn't appear as if any history before Oct 2018 was ported over. [1] https://github.blog/engineering/infrastructure/introducing-the-new-github-status-site/ https://github.blog/engineering/infrastructure/introducing-t... [2] https://web.archive.org/web/20181211191456/https://www.githubstatus.com/history https://web.archive.org/web/20181211191456/https://www.githu...
starkparker 5mo ago
That graph has bugged me since it went viral. The methodology is horseshit: https://github.com/DaMrNelson/github-historical-uptime https://github.com/DaMrNelson/github-historical-uptime Just dumping HARs from devtools from a status site that hallucinates 100% uptime when it has no data. For example, all GitHub services had 100% uptime in June 1996: https://www.githubstatus.com/uptime?page=200 https://www.githubstatus.com/uptime?page=200 The graph gives GitHub Actions 100% uptime before it launched to GA in November 2019. That factors into the average uptime for every month on the graph before that. It's fully horseshit.

MallocVoidstar 5mo ago

The graph in the article is a lie, because GitHub's "historical data" is a lie. https://www.githubstatus.com/uptime?page=3000 https://www.githubstatus.com/uptime?page=3000 According to it, GitHub had 100% uptime from June to August 1996.