[flagged]
Incident with Pull Requests, Issues, Git Operations and API Requests
191–200 of 221 posts
Re: Incident with Pull Requests, Issues, Git Operations and API Requests
#192OK now people can layoff even more engineers and feed the tasks to AI.
/s
Re: Incident with Pull Requests, Issues, Git Operations and API Requests
#193Earlier quoted context omitted.
Of all the sites/graphs I've seen of GH outages, this one is the most striking IMO: https://damrnelson.github.io/github-historical-uptime/ Unfortunately, it doesn't look like it's being updated with new data. But it wouldn't look any better for GH if it was.
FWIW, I'm not convinced that chart is necessarily an accurate representation of pre-acquisition reality. It would really surprise me if GitHub did not have a single sev-0 pre-acquisition, but it wouldn't surprise me if they were not formally captured and reported in a format that would make its way into their current status page's database.
GH going down used to be quite rare. If it failed to load I'd spend a bunch of time trying to figure out what was wrong with my internet connection, just to read on HN that it was down for everyone.
This week GH failed to load and I automatically assumed it was a GH issue - just for it to be followed up a few minutes later by a marketing coworker complaining about internet connectivity. Turns out the office internet connection was dropping about 50% of all packets.
It is bad enough that business-side managers are noticing that GH issues are slowing work down. That would've been unimaginable a few years ago.
Re: Incident with Pull Requests, Issues, Git Operations and API Requests
#194Earlier quoted context omitted.
Gitlab CI has some tech debt from accumulating geological layers of different ways to do things, but overall it's pretty good, it scales to more complicated setups, and it's not too painful. Now the best way to use GHA is to do the bare minimum. Put all your CI logic in a script that you can test locally, and just have GHA run your script. Even that is painful. And, somehow, impossible to make secure without having s…
expanding on the parent a little * GiLab — Ops centric * GitHub — Developer centric if you just want somewhere to stick a code repo and build a release every so often — dont use gitlab, you will not enjoy it . > My main problem with Gitlab is that after years I still can't find what I'm looking for in the UI. i still get lost too after several years daily driving gitlab. this is the Ops centric thing. they provide a…
I'm looking at the branch listing and I can't see a single hash. I dunno who GitHub is for but it isn't devs.
Re: Incident with Pull Requests, Issues, Git Operations and API Requests
#195https://isgithubcooked.com Normally I defend GH in the comments of these incidents but it’s been an impressively bad month by their standards, even when you filter for critical components filter out sev-2’s and 3’s.
Is it possible that there has been a change in the way the data are collected/recorded that even partially accounts for this sudden onset?
Re: Incident with Pull Requests, Issues, Git Operations and API Requests
#196Earlier quoted context omitted.
> The UI of that page is so nice Is it? Seems a text description of "Make a website outlining 'How cooked GitHub' is with a modern style" to basically any LLM would produce exactly that UI and design, literally nothing of that design a human had any influence on, besides the ones selecting what training data the used LLMs was trained with. I think most of us who've tried using LLMs for web-design can recognize that s…
Compared to near unusable pages that large organizations produce, yes this page is highly effective at conveying information. Who cares how it was produced?
Re: Incident with Pull Requests, Issues, Git Operations and API Requests
#197https://isgithubcooked.com Normally I defend GH in the comments of these incidents but it’s been an impressively bad month by their standards, even when you filter for critical components filter out sev-2’s and 3’s.
Wow, it seems that 100% of sev-3 ("critical") incidents in the last year (=365 days) have occurred between April 22, 2026 and now. Is it possible that there has been a change in the way the data are collected/recorded that even partially accounts for this sudden onset?
IMO as a github-watcher, I think they changed their definition of what constitutes a sev-0 between sev-1 for the better. In particular, they had a few "sev-1"'s around the turn of the year that would be classified as sev-0's if they happened today.
Pre-4/22 GitHub sev-1 was a normal SaaS company's sev-0, imo. So I think their new system is more reflective of reality. My guess is that a few of their big customers bullied them to have more accurate SEV categorization.
Re: Incident with Pull Requests, Issues, Git Operations and API Requests
#198https://isgithubcooked.com Normally I defend GH in the comments of these incidents but it’s been an impressively bad month by their standards, even when you filter for critical components filter out sev-2’s and 3’s.
Wow, it seems that 100% of sev-3 ("critical") incidents in the last year (=365 days) have occurred between April 22, 2026 and now. Is it possible that there has been a change in the way the data are collected/recorded that even partially accounts for this sudden onset?
Re: Incident with Pull Requests, Issues, Git Operations and API Requests
#199Re: Incident with Pull Requests, Issues, Git Operations and API Requests
#200is it me or ever since AI coding became the norm, there have been way more outages with otherwise reliable services? I get downtime on Supabase every few weeks. Even Cloudflare. And now Github
GitHub’s instability started when they announced they were wholesale migrating to azure. They’ve been struggling with uptime since before the enormous surge in agentic coding they’re seeing. I don’t doubt that AI has massively increased their load, but u think this is more suspect than that.