githubbad.html

github and the crime against software A software article by Efron Licht May 2026 ALL ARTICLES LICENSE Feeds RSS ATOM JSON Introduction If a house was on fire there could be but two parties. One in favor of putting out the fire. Another in favor of the house burning. Abraham Lincoln As I begin this article, Github is down, again. While there have been plenty of articles talking about github’s struggles with reliability, security, and performance like this one by the verge, they are only scratching the surface. Github serves as a sort of ‘signal’ of infrastructural decay within both Github and the world of big tech software services in general. While I could point to similar decay in nearly every big tech corporate service, from AWS to Google Search, Github serves as a striking example due to being nearly syonymous with software development. I remember a conversation with a recruiter in 2022 where they simply did not believe that I was a ‘real programmer’ because I didn’t have a github account. What github is supposed to be - a high-performance, high-availability, high-capacity distributed system - is my personal professional specialty, so I can bring a little more insight into the problem than your average tech reporter. It’s not just availability: github is rife with problems. These include but are not limited to (parts in bold will be proven). A small sample of recent problems with github Github has dozens of incidents a month according to their own public communications, which means the real rate is probably in the hundreds Github does not expose a public bug list or any issues page, hiding their problems deep in email chains Github constantly lies to its users about it’s uptime and priorities Even by its own metrics it is in violation of its SLA Github clearly prioritizes flashy AI features over fundamental reliability The increased ‘agentic’ load on github is the direct result of their own actions and those of their parent company, Microsoft, and that makes reliability problems their own fault.

Github often breaks on firefox and safari, browsers with millions of users Github tolerates clear ‘follower-buying’ and ‘star-buying’ on their services and promotes obviously astroturfed repositories: there is literally a website called githubstars.com that openly advertises buying stars, see this published paper by carnegie mellon, even though, quote, “fake stars are highly related to malicious activities” Github’s pull request page (and especially the comment/review page) are laggy and extraordinarly RAM-hungry (I’ve seen heap spikes of >512 MiB!) Github often resets or changes project and user settings: new features are ‘on by default’ even when extremely dangerous Github clearly prioritizes flashy ‘AI’ projects over actual paying customers Github Actions are badly designed, slow, and poorly documented, quite possibly the worst of the “shell scripts written in YAML” style of build systems and I’ve seen dozens The github actions logs leak memory and have crashed my browser over multiple years, there’s still no way to just pipe the stdout somewhere The default cache behavior of github’s ‘default’ actions (i.e, setup-go) are ludicrously naive and worse than nothing; many of them literally never do cache invalidation. > I could go on and on. It is a fractal of bad design, to quote the famous rant about PHP. Github’s front-end… is comically bloated and slow often breaks on safari and firefox constantly changes it’s UX without warning or explanation, often deliberately replacing parts of the UX that used to do something useful with more and more funnels to their “AI” systems Table of Contents autogenerated on 2026-05-29 introduction a-small-sample-of-recent-problems-with-github github-constantly-lies-to-its-users-about-it-s-uptime-and-priorities

the-increased-agentic-load-on-github-is-the-direct-result-of-their-own-actions-and-those-of-their-parent-company-microsoft github-s-front-end-code-is-a-mess-comparisons-of-github-gitlab-and-codeberg images-repository-landing-page-for-github-gitlab-codeberg experiment-design experiment-procedure running-the-experiment creating-the-repo uploading-the-repo-to-github-gitlab-and-codeberg collecting-network-sample-data collect-heap-ram-usage-after-load anaysis-of-heap-usage-and-historical-comparisons use-testcompress-to-collect-information-on-compression-support analyzing-the-network-archive-har-with-anhar in-1 explanation-of-sections lemma-it-s-not-mere-enshittification third-party-analysis-pagespeed-web-dev mobile pagespeed-has-great-recommendations-on-how-to-improve-performance-i-ll-highlight-some-of-the-more-interesting-ones-and-my-own-thoughts-as-we-go-along comparison-of-github-gitlab-and-codeberg gitlab summary grade-d suggestions-developer suggestions-user codeberg-forgejo summary-1 grade-c suggestions-developer-1 suggestions-user-1 commentary github summary-2 grade-f commentary-1 suggestions-developer-2 suggestions-user-2 eblog-fly-dev-startingsystems3-html summary-3 grade-a suggestions-developer-3 suggestions-user-3 conclusion appendix anhar-source anhar-results bonus-content-testcompress testcompress-source bonus-content-testcompress-results Github constantly lies to its users about it’s uptime and priorities While github’s official status page claims something like 99.8% uptime - anyone who’s used it recently knows the real number has zero nines in it. Sites like the missing github status page do a good job of showing what it really looks like. Github is well aware they’re in hot water lately, and they’ve thrown out some press releases to try and deflect the criticism. Last month, github threw out a press release titled ‘an update on github availability’ to try and address some of this criticism. Microsoft: The main driver is a rapid change in how software is being built. Since the second half of December 2025, agentic development workflows have accelerated sharply.

By nearly every measure, the direction is already clear: repository creation, pull request activity, API usage, automation, and large-repository workloads are all growing quickly. Beyond the fact that a graph with no labeled axes or individual data points is always a matter of suspicion, it is disengenous beyond belief to use the passive voice when saying “agentic development workflows have accelerated sharply”, as though this is something that has snuck up on github without their knowledge or consent. Github is owned by microsoft, a company which has shoved AI, “agents” or otherwise, into every single product in a zillion overlapping ways. Almost every single github page has three different AI buttons on it in the hotbar, two of which are dedicated entirely to starting agents. Many have four. The increased ‘agentic’ load on github is the direct result of their own actions and those of their parent company, Microsoft Men are wisely presumed to intend the natural consequences of their conduct, and to seek what their acts seem to promote. Charles Sumner, “The Crime Against Kansas” Github and microsoft are constantly pushing their users to use “AI” and “Agents” under every circumstance. It is hard to overstate just how badly they want you to use this stuff: there are not one, not two, not three, but four different ways to fire up copilot just within the top right quarter of the landing page of your average repository. Four. (While writing this article, I discovered there was a THIRD agent button on every page. For repos which project which don’t explicitly disable agents, a FOURTH button shows up. This is diseased.) Further, github subsized the cost of using these tools in order to drive adoption for years, effectively paying for a distributed denial of service on itself. Microsoft: This exponential growth does not stress one system at a time. A pull request can touch Git storage, mergeability checks, branch protection, GitHub Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches, and databases. At high scale, small inefficiencies compound: queues deepen, cache misses become database load, indexes fall behind, retries amplify traffic, and one slow dependency can affect several product experiences.

Github’s database engineers do not have an easy job - it is a legitimate challenge, one that I would struggle with myself - but Github does not have small inefficiencies, they have enormous, staggering inefficiencies, something we’ll get into later. Microsoft: Our priorities are clear: availability first, then capacity, then new features. This is a lie. Github - and the microsoft organization more widely - clearly prioritize flashy AI features over fundamental reliability Github has a public changelog. In thirty days since they posted their update, their patch notes contain the words “copilot” 59 times, “agent” 8 times, “performance” 0 times, and “reliability” 0 times. The changelog has a feature to filter by category: copilot is it’s own category: performance and reliability do not exist at all. This is not just limited to github itself, it’s endemic cross the whole organization. Visual Studio Code, also owned by microsoft, is the most popular IDE (code editor) in the world, and is directly integrated with github and it’s “agentic” features, with more and more being shoveled in even as basic features like the built-in terminal degrade to near-unusability. As I opened VS Code this morning to work on my second draft, visual studio code pushed an update with a brand new “agent window”. Microsoft also included a section of the patch notes with “notable fixes”: it’s empty. I am not blind. I am a human being. Don’t piss on my shoes and tell me it’s raining. Microsoft: We are reducing unnecessary work, improving caching, isolating critical services, removing single points of failure, and moving performance-sensitive paths into systems designed for these workloads. This is distributed systems work: reducing hidden coupling, limiting blast radius, and making GitHub degrade gracefully when one subsystem is under pressure. We’re making progress quickly, but these incidents are examples of where there’s still work to do. This is an admission that the system is designed wrong. Performance is downstream of software architecture. If the bones are good, you can fix performance problems as they pop up: if the bones are bad, no amount of hacks will suffice: you’ll have to start over. The roots of Github’s reliability problems are on their back-end and within their databases, and these are hidden from us.