11 ms·

GitHub appears to be struggling with measly three nines availability

474 points by richtr 6mo ago

b00ty4breakfast 6mo ago
Until paying customers start leaving en masse, they will continue to shovel out subpar service.
ankit7000 6mo ago
[flagged]
pilif 6mo ago
see also: https://thenewstack.io/github-will-prioritize-migrating-to-azure-over-feature-development/ https://thenewstack.io/github-will-prioritize-migrating-to-a... A migration like this is a monumental undertaking to the level of where the only sensible way to do a migration like this is probably to not do it. I fully expect even worse reliability over the next few years before it'll get better.
embedding-shape 6mo ago
From GitHub CTO in 2025 when they announced they're moving everything to Azure instead of letting GitHub's infrastructure remain independent: > For us, availability is job #1, and this migration ensures GitHub remains the fast, reliable platform developers depend on That went about as well as everyone thought back then. Does anyone else remember back in ~2014-2015 sometime, when half the community was screaming at GitHub to "please be faster at adding more features"? I wish we could get back to platforms (or OSes for that matter) focusing in reliability and stability. Seems those days are long gone.
- awestroke 6mo ago
  Perhaps when they switch over fully to Azure they'll forget to disable IPv6 access. One can dream
- comboy 6mo ago
  I think stability and reliability have vastly improved over the last years in general (not necessarily talking about gh specifically) It's just that everybody is using 100 tools and dependencies which themselves depend on 50 others to be working.
  - hrmtst93837 6mo ago
    [flagged]
- braiamp 6mo ago
  > I wish we could get back to platforms (or OSes for that matter) focusing in reliability and stability That's only a valid sentiment if you only use the big players. Both of those have medium/smaller competitors that have shown (for decades) that they are extremely boring, therefore stable.
  - PxldLtd 6mo ago
    Try convincing the CTO that this panoply of smaller players will be around for 5yrs or worth the effort migrating to. I'm at a much smaller outfit now so we have more freedom but I'd dread to think the arguments I would've had at the 4000+ employee companies I was at before.
  - SlinkyOnStairs 6mo ago
    In that same period the big players have only gotten bigger and the "Mittelstand" in tech has been practically dying. Replaced by the flood of VC startups that are far too obsessed with "growth" to care about reliability and stability. (Note that "is this company financially viable in the long term future" is an important part of stability. Doesn't matter how rock solid the software is if the startup's bankrupt by the end of next year.)
  - lmm 6mo ago
    Like who? HN loves to rave about GitLab but they're even less stable than GitHub.
    - braiamp 6mo ago
      Gitlab service may be unreliable, but Gitlab the product to deploy is extremely fine. Many third party instances of Gitlab that don't have problems that only happens at scale.
- __alexs 6mo ago
  GitHub have not really got much better at adding new features either though :(
  - carlmr 6mo ago
    They added the service unavailable feature.
  - embedding-shape 6mo ago
    This was before Actions and a whole lot of other non-git related stuff. There was years (maybe even a decade?) where GitHub essentially was unchanged besides fixes and small incremental improvements, long time ago :)
    - wongarsu 6mo ago
      GH Actions was good for them as another billable feature, but I'm skeptical we actually gained much over external CI providers The improvements to PR review have been nice though
      - cozzyd 6mo ago
        Don't forget the security implications if you host your own actions runner.
        nine_k 6mo ago
        What are these?
      - embedding-shape 6mo ago
        > The improvements to PR review have been nice though I dunno, probably the worst UX downgrade so far, almost no PRs are "fully available" on page load, but requires additional clicks and scrolling to "unlock" all the context, kind of sucks. Used to be you loaded the PR diff and you actually saw the full diff, except really large files. You could do CTRL+F and search for stuff, you didn't need to click to expand even small files. Reviewing medium/large PRs is just borderline obnoxious today on GH.
- zahlman 6mo ago
  That's about when I joined, and all I really remember thinking was that it was cool that I could now share my repo publicly without having to try and run a server from a residential IP.
Eikon 6mo ago
As of recently (workflows worked for months) I even have part of my CI on actions that fails with [0] 2026-02-27T10:11:51.1425380Z ##[error]The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled. 2026-02-27T10:11:56.2331271Z ##[error]The operation was canceled. I had to disable the workflows. GitHub support response has been “ We recommend reviewing the specific job step this occurs at to identify any areas where you can lessen parallel operations and CPU/memory consumption at one time.” That plus other various issues makes me start to think about alternatives, and it would have never occurred to me one year back. [0] https://github.com/Barre/ZeroFS/actions/runs/22480743922/job/65120241358?pr=357 https://github.com/Barre/ZeroFS/actions/runs/22480743922/job...
- PxldLtd 6mo ago
  We've jumped ship to self-hosted Jenkins. Woodpecker CI looks cool but Jenkins seemed like a safer bet for us. It's been well worth the effort and it's simplified and sped up our CI massively. Once we got the email that they were going to charge for self-hosted runners that was the final nail in the coffin for us. They walked it back but we've lost faith entirely in the platform and vision.
  - thwarted 6mo ago
    Charging for self-hosted runners is like a corkage fee but you still need to open the bottle yourself.
  - hrmtst93837 6mo ago
    [flagged]
  - maccard 6mo ago
    I don’t know what’s worse - in 2026 someone genuinely suggesting Jenkins as a viable GHA alternative, or me agreeing with that. Jenkins has possibly the worst user experience of any piece of software I’ve had to use in the last few years. It’s slow, brittle, somehow both heavyweight and has no features, littered with security vulns due to architecture, is impossible to navigate, has absolutely no standardisation for usage. And yet it’s still more reliable than GHA.
sammy2255 6mo ago
I wonder if they are still running on a single MySQL machine
- _heimdall 6mo ago
  The article mentions some concerns related to migrating their MySQL clusters off bare metal.
- andrew_mason1 6mo ago
  They are not: https://www.youtube.com/watch?v=_Xl24s_0mZs https://www.youtube.com/watch?v=_Xl24s_0mZs
rvz 6mo ago
Ever since Microsoft's acquisition of GitHub 8 years ago, GitHub has completely enshittified and has become so unreliable, that even self-hosting a Git repository or self-hosted actions yourself would have a far better uptime than GitHub. This sounded crazy in 2020 when I said that in [0]. Now it doesn't in 2026 and many have realized how unreliable GitHub has become. If there was a prediction market on the next time GitHub would have at least one major outage per week, you would be making a lot of money since it appears that AI chatbots such as Tay.ai, Zoe and Copilot are somewhat in charge of wrecking the platform. Any other platform wouldn't tolerate such outages. [0] https://news.ycombinator.com/item?id=22867803 https://news.ycombinator.com/item?id=22867803
_pdp_ 6mo ago
https://news.ycombinator.com/item?id=47315878 https://news.ycombinator.com/item?id=47315878
_heimdall 6mo ago
I'm surprised GitHub got by acting fairly independently inside Microsoft for so long. I'm also surprised GitHub employees expected that to last The real problem today IMO is that Microsoft waited so long to drop the charade that they now felt like they had to rip the bandaid. From what I've heard the transition hasn't gone very smoothly at all, and they've mostly been given tight deadlines with little to no help from Microsoft counterparts.
- eterm 6mo ago
  If this were a place for memes, then I'd share that swimming pool meme with Microsoft holding up copilot while GitHub is drowning. Then Azure Dev Ops (formerly known as Visual Studio Team System) dead o n the ocean floor. Although given how badly GitHub seems to be doing, perhaps it's better to be ignored.
  - sixeyes 6mo ago
    why is az devops on the floor? i am having to choose between the clients existing az dops and our internal gitlab for where to host a pipeline, and i don't know what would be good at all
    - eterm 6mo ago
      It works fine,it just feels like it has been under a kind of maintenance mode for a while. There's clearly one small team that works on it. There are pros and cons to that. It hasn't even got an obnoxious Copilot button yet for example, but on the other hand it was only relatively recently you could properly edit comments in markdown. If the client has existing AzDo Pipelines then I'd suggest keeping them there.
      - sixeyes 6mo ago
        thank you very much! that copilot comment got me, haha.
- MoreQARespect 6mo ago
bentobean 6mo ago
“Microsoft Tentacle” - Now there’s a name for a new product line.
- asimovDev 6mo ago
  this comment reminded me that GitKraken was a thing. And still is, apparently
yurii_l 6mo ago
Maybe they need to improve release strategy with Copilot AI Review =)
cedws 6mo ago
While GitHub obsess over shoving AI into everything, the rest of the platform is genuinely crumbling and its security flaws are being abused to cause massive damage. Last week Aqua Security was breached and a few repositories it owns were infected. The threat actors abused widespread use of mutable references in GitHub Actions, which the community has been screaming about for years, to infect potentially thousands of CI runs. They also abused an issue GitHub has acknowledged but refused to fix that allows smuggling malicious Action references into workflows that look harmless. GHA can’t even be called Swiss cheese anymore, it’s so much worse than that. Major overhauls are needed. The best we’ve got is Immutable Releases which are opt in on a per-repository basis.
- ljm 6mo ago
  I worry that CI just got overcomplicated by default when providers started rocking up with templated YAML and various abstractions over it to add dynamic behaviour, dependencies, and so on. Perhaps mixing the CI with the CD made that worse because usually deployment and delivery has complexities of its own. Back in the day you'd probably use Jenkins for the delivery piece, and the E2E nightlies, and use something more lightweight for running your tests and linters. For that part I feel like all you need, really, is to be able to run a suite of well structured shell scripts. Maybe if you're in git you follow its hooks convention to execute scripts in a directory named after the repo event or something. Forget about creating reusable 'actions' which depend on running untrusted code. Provide some baked in utilities to help with reporting status, caching, saving junit files and what have you. The only thing that remains is setting up a base image with all your tooling in it. Docker does that, and is probably the only bit where you'd have to accept relying on untrusted third parties, unless you can scan them and store your own cached version of it. I make it sound simpler than it is but for some reason we accepted distributed YAML-based balls of mud for the system that is critical to deploying our code, that has unsupervised access to almost everything. And people are now hooking AI agents into it.
  - Hasnep 6mo ago
    I'm trying out SelfCI [1] for one of my projects and it's similar to what you were describing. My whole CI pipeline is just a shell script that runs the actual build and test commands, I can write a script in another language like python if I need more complexity and I can run it all locally at any time to debug. [1] https://app.radicle.xyz/nodes/radicle.dpc.pw/rad%3Az2tDzYbAXxTQEKTGFVwiJPajkbeDU https://app.radicle.xyz/nodes/radicle.dpc.pw/rad%3Az2tDzYbAX...
pluc 6mo ago
I'm amazed Microslop let us keep GitHub this long. Probably because they're training AI on it? To have a direct line to developers? I don't see why else they would've bothered with something that was so anti everything they stood for
- g947o 6mo ago
  What does Microsoft stand for?
  - cozzyd 6mo ago
    Making Incrementally Crappier Repositories, Operating Systems, Office and any Future Technology
    - jmaw 6mo ago
      you misspelled MicroSlop
  - pluc 6mo ago
    Control. Gatekeeping. Profits. Proprietary technology. Licenses.
martinald 6mo ago
I wonder how much of this is down to the massive amount of new repos and commits (of good or bad quality!) from the coding agents. I believe that the App Store is struggling to keep up with (mostly manual tbf) app reviews now, with sharp increases in review times. I find it hard to believe that an Azure migration would be that detrimental to performance, especially with no doubt "unlimited credit" to play with? You can provision Linux machines easily on Azure and... that's all you need? Or is the thinking that without bare metal NVMe mySQL it can't cope (which is a bit of a different problem tbf).
- grafporno 6mo ago
  This reminds me of when i looked up how many actions runs the openclaw repo triggers. 700k as of now.
- garettmd 6mo ago
  I think part of the issue is that Azure has been struggling to reliably provision Linux VMs. Whether that's due to increased load, poor operational execution, or a combination of them, it's hard for anyone on the outside to know.
cl0ckt0wer 6mo ago
Cheap, fast, and good. I see which two they chose.
- akshitgaur2005 6mo ago
  They didn't even choose two, only one :)
- bengale 6mo ago
  Two?
mikeve 6mo ago
Just to add a little bit of nuance to this not because I'm trying to defend GitHub, they definitely need to up their reliability, but the 90% uptime figure represents every single service that GitHub offers being online 90% of the time. You don't need every single service to be online in order to use GitHub. For example, I don't use Copilot myself and it's seen a 96.47% uptime, the worst of the services which are tracked.
- crote 6mo ago
  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.
- klabb3 6mo ago
  > 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.
- pier25 6mo ago
  96% is horrible uptime though
- ruszki 6mo ago
  Here is the same thing in 2019: https://web.archive.org/web/20190510070456/https://www.githubstatus.com/ https://web.archive.org/web/20190510070456/https://www.githu... It seems that the same metric is about a magnitude worse than before.
- 6mo ago
dijit 6mo ago
I’m surprised it’s even as high as three nines, at one point in 2025 it was below 90%; not even a single nine.[0] (which, to be fair includes co-pilot, which is the worst of availabilities). People on lobsters a month ago were congratulating Github on achieving a single nine of uptime.[1] I make jokes about putting all our eggs in one basket under the guise of “nobody got fired for buying x; but there are sure a lot of unemployed people”- but I think there’s an insidious conversation that always used to erupt: “Hey, take it easy on them, it’s super hard to do ops at this scale”. Which lands hard on my ears when the normal argument in favour of centralising everything is that “you can’t hope to run things as good as they do, since there’s economies of scale”. These two things can’t be true simultaneously.. this is the evidence. [0]: https://mrshu.github.io/github-statuses/ https://mrshu.github.io/github-statuses/ [1]: https://lobste.rs/s/00edzp/missing_github_status_page#c_3cxesk https://lobste.rs/s/00edzp/missing_github_status_page#c_3cxe...
- tpmoney 6mo ago
  > These two things can’t be true simultaneously Sure they can. Perhaps a useful example of something like this would be to consider cryptography. Crypto is ridiculously complex and difficult to do correctly. Most individual developers have no hope of producing good cryptographic code on the same scale and dependability of the big crypto libraries and organizations. At the same time these central libraries and organizations have bugs, mistakes and weaknesses that can and do cause big problems for people. None of that changes the fact that for most developers “rolling your own crypto” is a bad idea.
  - dijit 6mo ago
    That’s an excellent example. OpenSSL, by virtue of trying to do everything is the most buggy implementation of TLS generally available today leading to the point where there have been hard forks designed to reduce the scope to limit this damage. I’d go so far as to say that there are more crypto libraries than there are “default” options for SaaS Git VCS (Gitlab and Github are the mainstay in companies and maybe Azure Devops if you hate your staff- nobody sensible is using bitbucket) but for TLS implementations there’s RustTLS, GnuTLS, BoringSSL, LibreSSL, WolfSSL, NSS, and AWS-LC that come to mind immediately.
iwontberude 6mo ago
Three nines is more than enough
- Ygg2 6mo ago
  In the future, no one will need more than one and a half nines.
  - iwontberude 6mo ago
    Yeah I agree
amelius 6mo ago
It's time to look for a decentralized Non-Hub alternative.
- AlienRobot 6mo ago
  Github without hub? I don't think that exists.
  - bigDinosaur 6mo ago
    Email?
    - amelius 6mo ago
      More like Git, without the Hub. Perhaps the Hub aspects can be stored in Git as well?
      - esafak 6mo ago
        https://radicle.xyz/ https://radicle.xyz/
- technoweenie 6mo ago
  https://tangled.org https://tangled.org builds on atproto for the social features.
William_BB 6mo ago
To me, Github has always seemed well positioned to be a one-stop solution for software development: code, CI/CD, documentation, ticket tracking, project management etc. Could anyone explain where they failed? I keep hearing that Github is terrible
- CharlieDigital 6mo ago
  We use GH and are investing more in the platform features. Codespaces specifically is quite good for agent heavy teams. Launch a full stack runtime for PRs that are agent owned. > keep hearing that Github is terrible I do not doubt people are having issues and I'm sure there have been outages and problems, but none that have affected my work for weeks. GH is many things to many teams and my sense is that some parts of it are currently less stable than others. But the overall package is still quite good and delivers a lot of value, IMO. There is a bit of an echo chamber effect with GH to some degree.
  - maccard 6mo ago
    We use GitHub actions and we have more build failures from actions than we do any other source.
- conartist6 6mo ago
  It always starts out good enough, but the reason they pursue horizontal integration is that it ensures that you won't be able to get out even if (when) you eventually want to. You'll be as glued as a fly to flypaper. That's the reason you hear the complaints: they're from people who no longer want to be using this product but have no choice. Because Microsoft doesn't need to innovate or even provide good service to keep the flies glued, they do what they've been doing: focus all their resources on making the glue stickier rather than focusing on making people want to stay even if they had an option to leave.
- esafak 6mo ago
  They got acquired by Microsoft.
kgwxd 6mo ago
Just use git, problem solved.
ankit7000 6mo ago
[dead]
neonihil 6mo ago
Nothing unexpected. Microsoft has a remarkable talent for turning good products into useless ones. Skype is another good showcase of such talent.
- throw10920 6mo ago
  Windows (including Notepad and Explorer), too. I think ~Office~ ~Office 365~ ~Microsoft 365~ Copilot 365 is still technically useful despite the insane branding and licensing and AI slop features, but I doubt it'll last much longer.
- narrowtux 6mo ago
  When will they introduce GitHub for Business?
  - Traubenfuchs 6mo ago
    My company is on GitHub Enterprise.
  - brummm 6mo ago
    That has existed for a long time and predates the MS acquisition. It's called Github Enterprise.
ankit7000 6mo ago
[dead]
Alifatisk 6mo ago
Have anyone checked out the status page? It's actually way worse than I thought, I believe this is the first time I am actually witnessing a status page with truly horrible results. https://mrshu.github.io/github-statuses https://mrshu.github.io/github-statuses
- apetresc 6mo ago
  Well then clearly you haven't taken a look at https://status.claude.com https://status.claude.com.
  - bombcar 6mo ago
    This is ... surprisingly honest? The one above is "missing" status page; and most status pages would legally have to be filed in the "fiction" section of the library.
  - dathinab 6mo ago
    At that 3rd party side GH is currently noticeable worse then claude ... Like they are down to one 9 availability and very very close to losing that to (90.2x%). This also fit more closely to my personal experience, then the 99.900-99.989 range the article indicates... Through honestly 99.9% means 8.76h downtime a year, if we say no more then 20min down time per 3 hours (sliding window), and no more then 1h a day, and >50% downtime being (localized) off-working hours (e.g. night, Sat,Sun) then 99.9% is something you can work with. Sure it would sometimes be slightly annoying. But should not cause any real issues. On the other hand 90.21%... That is 35.73h outage a year. Probably still fine if for each location the working hour availability is 99.95% and the previous constraints are there. But uh, wtf. that just isn't right for a company of that size.
    - kbelder 6mo ago
      You may have fumbled the calculator at one point. 20Min per 3 hours is 88.8% uptime. 99.9% uptime is 11 seconds down.
      - 6mo ago
anonym29 6mo ago
Not owned by companies that help the US Federal Government illegally spy on their own citizens and murder children overseas: Gitlab Bitbucket Sourceforge Forgejo Codeberg Radicle Launchpad Owned by companies that help the US Federal Government illegally spy on their own citizens and murder children overseas: Github
- christoph-heiss 6mo ago
  Neither Forgejo nor Codeberg are owned by _any_ company. Very important distinction.
- megous 6mo ago
  Codeberg is nice.
ajhenrydev 6mo ago
I worked on the react team while at GitHub and you could easily tell which pages rendered with react vs which were still using turbo. I wish we took perf more seriously as a culture there
- CodingJeebus 6mo ago
  Did react render better than turbo or the opposite? I assume a well-optimized turbo page would perform better
  - ajhenrydev 6mo ago
    React destroyed perf and used more resources than turbo
    - CodingJeebus 6mo ago
      That's what I figured and has been my experience as well.
    - pier25 6mo ago
      Was there any discussion to use something other than react?
pscanf 6mo ago
I only use GitHub (and actions) for personal open-source projects, so I can't really complain because I'm getting everything for free¹. But even for those projects I recently had to (partially) switch actions to a paid solution² because GitHub's runners were randomly getting stuck for no discernible reason. ¹ Glossing over the "what they're getting in return" part. ² https://www.warpbuild.com/ https://www.warpbuild.com/
e-dant 6mo ago
Think the world would be a better place if 70-80% uptime were more tolerated. We really don’t need everything available all the time. More time to talk to each other, to think, more “slow time”. Just don’t like the slop that’s getting us there.
Anon1096 6mo ago
Anyone who used the phrase "measly" in relation to three nines is inadvertently admitting their lack of knowledge in massive systems. 99.9 and 99.95 is the target for some of the most common systems you use all day and is by no means easy to achieve. Even just relying on a couple regional AWS services will put your CEILING at three nines. It's even more embarrassing when people post that one GH uptime tracker that combines many services into 1 single number as if that means anything useful.
- bitmasher9 6mo ago
  Three 9s is a perfectly reasonable bar to expect for services you depend on. Without GitHub my company cannot deploy code. There is no alternative method to patch prod. In addition many development activities are halted, wasting labor costs. We wouldn’t couple so much if we knew reliability would be this low. It will influence future decisions.
- deleted 6mo ago
  [deleted]
dathinab 6mo ago
wait they still have 3 ninth, it really doesn't feel like that but then their status center isn't really trust-able anymore and a lot of temporary issues I have been running into seem to be temporary, partial, localized failures which sometimes fall under temp. slow to a point of usability. Temporary served outdated (by >30min) main/head. etc. so that won't even show up in this statistics
yifanl 6mo ago
https://mrshu.github.io/github-statuses/ https://mrshu.github.io/github-statuses/ Even ignoring Copilot, they seem to be barely at 2 nines of uptime for any service component.
flykespice 6mo ago
Why dont they just vibecode their way into stability? /s
sauercrowd 6mo ago
I'm somewhat surprised with Github's strategy in the AI times. I understand how appealing it is to build an AI coding agent and all that, but shouldn't they - above everything else - make sure they remain THE platform for code distribution, collaboration and alike? And it doesnt need to be humans, that can be agents as well. They should serve the AI agent world first and foremost. Cause if they dont pull that off, and dont pull off building one of the best coding agents - whcih so far they didnt - there isn't much left. There's so many new features needed in this new world. Really unclear why we hear so little about it, while maintainers smack the alarm bell that they're drowning in slop.
- deleted 6mo ago
  [deleted]
- astralasia 6mo ago
  Microsoft’s real goal is selling Copilot seats and pushing Azure, not building a neutral playground for third-party agents. There is just no money for them in being the backend for someone else's AI. As for the AI spam, GitHub's internal metrics have always been tied to engagement and PR volume. Blocking all that AI slop would instantly drop their growth numbers, so it is easier for them to just pass the cleanup cost onto open-source maintainers.
  - sauercrowd 6mo ago
    No disagreement here. Just very short sighted.
m4tthumphrey 6mo ago
GitLab isn't much better right now either unfortunately.
ChrisArchitect 6mo ago
Feb 10th post OP; More recently: Addressing GitHub's recent availability issues https://github.blog/news-insights/company-news/addressing-githubs-recent-availability-issues-2/ https://github.blog/news-insights/company-news/addressing-gi... (with a smattering of submissions here the last few weeks but no discussion)
BANRONFANTHE 6mo ago
[flagged]
lijok 6mo ago
ITT lots of complaining, not much building. Microsoft does not give a fuck what you think - they only care if the revenue line goes up. And the revenue line keeps going up despite this instability. Want to build the next unicorn? Build a GitHub competitor.
jghn 6mo ago
Why have five nines when you can have nine fives?
1970-01-01 6mo ago
IPv6 ignorance is the canary. There's plenty of architecture ignorance below the surface. The real question is why aren't they failing annual security audits? https://docs.github.com/en/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/accessing-compliance-reports-for-your-organization https://docs.github.com/en/enterprise-cloud@latest/organizat...
- PunchyHamster 6mo ago
  Coz the audits have same quality as architecture lmfao
827a 6mo ago
I don't want to give too much credit to Github, because their uptime is truly horrendous and they need to fix it. But: I've felt like its a little unfair to judge the uptime of company platforms like this; by saying "if any feature at all is down, its all down" and then translating that into 9s for the platform. I never use Github Copilot; it does go down a lot, if their status page is to be believed; I don't really care when it goes down, because it going down doesn't bring down the rest of Github. I care about Github's uptime ignoring Copilot. Everyone's slice of what they care about is a little different, so the only correct way to speak on Github's uptime is to be precise and probably focus on a lot of the core stuff that tons of people care about and that's been struggling lately: Core git operations, website functionality, api access, actions, etc.
- lucideer 6mo ago
  You're right that labelling any outage as "Github is down" is an overgeneralisation, & we should focus on bottlenecks that impact teams in a time sensitive matter, but that isn't the case here. Their most stable service (API) has only two 9s (99.69%). They're not even struggling to get their average to three 9s, they're struggling to get ANY service to three 9s. They're struggling to get many services to two 9s. Copilot may be the least stable at one 9, but the services I would consider most critical (Git & Actions) are also at one 9.
  - calvinmorrison 6mo ago
    ONLY TWO NINES! Meanwhile vital government services here have a whopping 25% availability.
    - lucideer 6mo ago
      Two things can be bad.
    - bigfishrunning 6mo ago
      Lemme guess, those government services are run by the lowest bidder?
DailyGeo 6mo ago
The availability expectations gap is interesting from an education standpoint. Students are tought that 99.9% sounds impressive without contextualizing what that means in practice — roughly 8 hours of downtime per year. For a platform that millions of developers depend on as critical infrastructure during work hours, that math hits very differently than it does for a consumer app.
outside2344 6mo ago
I have a little bit of sympathy for Github because if everyone is like me then they are getting 5-6x the demand they were last year just based on sheer commits alone, not to mention Github Copilot usage.
jtokoph 6mo ago
Pretty soon, the only 9 they’re going to have is the 9 8s…
jedberg 6mo ago
GitHub is in a tough spot. From what I've heard they've been ordered to move everything to Azure from their long standing dataceners. That is bound to cause issues. Then on top of that they are using AI coders for infra changes (supposedly) which will also add issues. And then on top of all that, their traffic is probably skyrocketing like mad because of everyone else using AI coders. Look at popular projects -- a few minutes after an issue is filed they have sometimes 10+ patches submitted. All generating PRs and forks and all the things. That can't be easy on their servers. I do not envy their reliability team (but having been through this myself, if you're reading this GitHub team, feel free to reach out!).
- nilkn 6mo ago
  > Look at popular projects -- a few minutes after an issue is filed they have sometimes 10+ patches submitted. All generating PRs and forks and all the things. I think this is a really important point that is getting overlooked in most conversations about GitHub's reliability lately. GitHub was not designed or architected for a world where millions of AI coding agents can trivially generate huge volumes of commits and PRs. This alone is such a huge spike and change in user behavior that it wouldn't be unreasonable to expect even a very well-architected site to struggle with reliability. For GitHub, N 9s of availability pre-AI simply does not mean the same thing as N 9s of availability post-AI. Those are two completely different levels of difficulty, even when N is the same.
  - pojzon 6mo ago
    Not even talking about how useless it is to create tens of PRs to solve the same issue. But GitHub karma botting is a thing now. Remember those elitist ppl who removed answers on stackoverflow coz their answer is better with 90000 answers? Yup, now they are on GitHub farming karma with bots.
  - zackwu 6mo ago
    yeah this is indeed a good insight. Back in the days, who would expect so many bots to "review" code and leave overly verbose comments under every PR in a popular repo?
dzonga 6mo ago
when GitHub moved to react instead of server rendered pages ie erb/turbolinks/pjax was the start to the end. the pages got slower, rendering became a nightmare. then they introduced GitHub actions (half baked) - again very unreliable then they introduced Copilot - again not very reliable it's easy to see why availability has gone down the drain. are they still on the rails monolith ? they speak about it less these days ?
- onionisafruit 6mo ago
  I’m not disagreeing, but I think you have the order wrong. Half baked actions was released before they moved to react. I’m talking about the version that used hcl for config instead of yaml.
unhidden 6mo ago
The 37 minutes of downtime last week cost us a deploy window during market hours. What's underappreciated: it's not just the raw downtime, it's that every CI/CD pipeline, every webhook, every deployment gate has GitHub as a single point of failure now. The centralization risk is real.
fHr 6mo ago
[flagged]
caconym_ 6mo ago
Legitimately worse uptime than my self-hosted services. That's pretty funny.
swisniewski 6mo ago
To be honest, I’m not surprised that GitHub has been having issues. If you have ever operated GitHub Enterprise Server, it’s a nightmare. It doesn’t support active-active. It only supports passive standbys. Minor version upgrades can’t be done without downtime, and don’t support rollbacks. If you deploy an update, and it has a bug, the only thing you can do is restore from backup leading to data loss. This is the software they sell to their highest margin customers, and it fails even basic sniff tests of availability. Data loss for source code is a really big deal. Downtime for source control is a really big deal. Anyone that would release such a product with a straight face, clearly doesn’t care deeply about availability. So, the fact that their managed product is also having constant outages isn’t surprising. I think the problem is that they just don’t care.
- sc68cal 6mo ago
  My $JOB ended up giving up on GHES and migrating to GHEC because of these exact issues.
- hawaiianbrah 6mo ago
  I worked on GHES for a couple of years. Before that, it sounded like it was a sort of volunteer rotation, there wasn’t durable funding for a team when we joined. Mind boggling that the money maker of the company was staffed like that. It is a complicated project. Thankfully their durable funding story has improved in recent years and they are staffing GHES up at levels they haven’t for at least 7 years. Hopefully it improves. I’m not there anymore, I was laid off last year.
Andrei_dev 6mo ago
Our security scanning runs on GitHub Actions — every PR gets checked before merge. When GitHub goes down, the security gate goes down with it. PRs pile up, devs get impatient, start merging without waiting for checks. That's exactly when bad code gets through. And they keep throwing engineers at Copilot while the stuff that CI/CD actually depends on keeps falling over.
- lvkv 6mo ago
  Do you have one or more public examples of this?
  - Andrei_dev 6mo ago
    [flagged]
pacman1337 6mo ago
The irony no one is talking about: AI makes quality code worse. Was bad enough already so imagine it now. I am expecting many more services to drop from 3 nines to 1 nine.
kylehotchkiss 6mo ago
https://status.claude.com https://status.claude.com _anthropic has entered the room_
mosaibah 6mo ago
[dead]
azalemeth 6mo ago
Embrace, extend, extinguish. Except the last one isn't quite going to plan...
graphememes 6mo ago
It's wild because they are one of the most used properties on earth and their uptime is actually incredible.
- alfalfasprout 6mo ago
  It's not though... it's sitting a hair above 90%
  - graphememes 6mo ago
    My comment is that I expect it to be more frequent and less given the scale and usage. Quite honestly, we have the most insane expectations about uptime and availability in my opinion. I'm glad that we can meet them. But still, insane.
    - SahAssar 6mo ago
      If something is unfixably broken 1 out of 10 times I use it I will just consider it broken. 1 out of 100 is unreliable but usable. That goes for most things physical and digital.
- MeetingsBrowser 6mo ago
  Define incredible. https://mrshu.github.io/github-statuses/ https://mrshu.github.io/github-statuses/ Overall uptime is 90% (single nine), and the best individual service at 99.8% (two nines). The core git functionality itself is at 98.98%, which works out to being down roughly a full business day each month.
  - graphememes 6mo ago
    Not bad
    - MeetingsBrowser 6mo ago
      At the risk of going recursive, how do you define not bad? Could be worse?
Robdel12 6mo ago
It is annoying. But I bet they’re effectively being DDoS’d every day by AI agents now. I think the past year of that growth has destroyed any of their spare resources. It’s not really a scale problem I’d like to work on, tbh. Seems very hard. Plus, the azure migration.
pfdietz 6mo ago
Hey, it's better than nine threes.
Achiyacohen 6mo ago
[dead]
malephex 6mo ago
Ruby?
- gfody 6mo ago
  I suspect mysql over rails.. I imagine the push for azure is to facilitate migrating from mysql to sql server (azure sql)
nubinetwork 6mo ago
Has Microsoft fixed teams crashing outlook? It's been broken since Wednesday, and the last thing I heard on Friday was that they were going to wait until Monday... really goes to show how much Microsoft cares these days...
2OEH8eoCRo0 6mo ago
There must be a lot of software "engineering" going on at github
frellus 6mo ago
Love the Register, but ... everyone has sort of known this for the past 10+ years if they've relied on GitHub with any sort of velocity.
ahstilde 6mo ago
yeah, between github and claude they're's an outage 75% of the time: https://www.aakash.io/tech-chase/github-and-claude-are-down-three-out-of-four-days https://www.aakash.io/tech-chase/github-and-claude-are-down-...

474 points by richtr 6mo ago

b00ty4breakfast 6mo ago

Until paying customers start leaving en masse, they will continue to shovel out subpar service.

ankit7000 6mo ago

[flagged]

pilif 6mo ago

see also: https://thenewstack.io/github-will-prioritize-migrating-to-azure-over-feature-development/ https://thenewstack.io/github-will-prioritize-migrating-to-a... A migration like this is a monumental undertaking to the level of where the only sensible way to do a migration like this is probably to not do it. I fully expect even worse reliability over the next few years before it'll get better.

embedding-shape 6mo ago

From GitHub CTO in 2025 when they announced they're moving everything to Azure instead of letting GitHub's infrastructure remain independent: > For us, availability is job #1, and this migration ensures GitHub remains the fast, reliable platform developers depend on That went about as well as everyone thought back then. Does anyone else remember back in ~2014-2015 sometime, when half the community was screaming at GitHub to "please be faster at adding more features"? I wish we could get back to platforms (or OSes for that matter) focusing in reliability and stability. Seems those days are long gone.

awestroke 6mo ago
Perhaps when they switch over fully to Azure they'll forget to disable IPv6 access. One can dream
comboy 6mo ago
I think stability and reliability have vastly improved over the last years in general (not necessarily talking about gh specifically) It's just that everybody is using 100 tools and dependencies which themselves depend on 50 others to be working.
- hrmtst93837 6mo ago
  [flagged]
braiamp 6mo ago
> I wish we could get back to platforms (or OSes for that matter) focusing in reliability and stability That's only a valid sentiment if you only use the big players. Both of those have medium/smaller competitors that have shown (for decades) that they are extremely boring, therefore stable.
- PxldLtd 6mo ago
  Try convincing the CTO that this panoply of smaller players will be around for 5yrs or worth the effort migrating to. I'm at a much smaller outfit now so we have more freedom but I'd dread to think the arguments I would've had at the 4000+ employee companies I was at before.
- SlinkyOnStairs 6mo ago
  In that same period the big players have only gotten bigger and the "Mittelstand" in tech has been practically dying. Replaced by the flood of VC startups that are far too obsessed with "growth" to care about reliability and stability. (Note that "is this company financially viable in the long term future" is an important part of stability. Doesn't matter how rock solid the software is if the startup's bankrupt by the end of next year.)
- lmm 6mo ago
  Like who? HN loves to rave about GitLab but they're even less stable than GitHub.
  - braiamp 6mo ago
    Gitlab service may be unreliable, but Gitlab the product to deploy is extremely fine. Many third party instances of Gitlab that don't have problems that only happens at scale.
__alexs 6mo ago
GitHub have not really got much better at adding new features either though :(
- carlmr 6mo ago
  They added the service unavailable feature.
- embedding-shape 6mo ago
  This was before Actions and a whole lot of other non-git related stuff. There was years (maybe even a decade?) where GitHub essentially was unchanged besides fixes and small incremental improvements, long time ago :)
  - wongarsu 6mo ago
    GH Actions was good for them as another billable feature, but I'm skeptical we actually gained much over external CI providers The improvements to PR review have been nice though
    - cozzyd 6mo ago
      Don't forget the security implications if you host your own actions runner.
      - nine_k 6mo ago
        What are these?
    - embedding-shape 6mo ago
      > The improvements to PR review have been nice though I dunno, probably the worst UX downgrade so far, almost no PRs are "fully available" on page load, but requires additional clicks and scrolling to "unlock" all the context, kind of sucks. Used to be you loaded the PR diff and you actually saw the full diff, except really large files. You could do CTRL+F and search for stuff, you didn't need to click to expand even small files. Reviewing medium/large PRs is just borderline obnoxious today on GH.
zahlman 6mo ago
That's about when I joined, and all I really remember thinking was that it was cool that I could now share my repo publicly without having to try and run a server from a residential IP.

Eikon 6mo ago

As of recently (workflows worked for months) I even have part of my CI on actions that fails with [0] 2026-02-27T10:11:51.1425380Z ##[error]The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled. 2026-02-27T10:11:56.2331271Z ##[error]The operation was canceled. I had to disable the workflows. GitHub support response has been “ We recommend reviewing the specific job step this occurs at to identify any areas where you can lessen parallel operations and CPU/memory consumption at one time.” That plus other various issues makes me start to think about alternatives, and it would have never occurred to me one year back. [0] https://github.com/Barre/ZeroFS/actions/runs/22480743922/job/65120241358?pr=357 https://github.com/Barre/ZeroFS/actions/runs/22480743922/job...

PxldLtd 6mo ago
We've jumped ship to self-hosted Jenkins. Woodpecker CI looks cool but Jenkins seemed like a safer bet for us. It's been well worth the effort and it's simplified and sped up our CI massively. Once we got the email that they were going to charge for self-hosted runners that was the final nail in the coffin for us. They walked it back but we've lost faith entirely in the platform and vision.
- thwarted 6mo ago
  Charging for self-hosted runners is like a corkage fee but you still need to open the bottle yourself.
- hrmtst93837 6mo ago
  [flagged]
- maccard 6mo ago
  I don’t know what’s worse - in 2026 someone genuinely suggesting Jenkins as a viable GHA alternative, or me agreeing with that. Jenkins has possibly the worst user experience of any piece of software I’ve had to use in the last few years. It’s slow, brittle, somehow both heavyweight and has no features, littered with security vulns due to architecture, is impossible to navigate, has absolutely no standardisation for usage. And yet it’s still more reliable than GHA.

sammy2255 6mo ago

I wonder if they are still running on a single MySQL machine

_heimdall 6mo ago
The article mentions some concerns related to migrating their MySQL clusters off bare metal.
andrew_mason1 6mo ago
They are not: https://www.youtube.com/watch?v=_Xl24s_0mZs https://www.youtube.com/watch?v=_Xl24s_0mZs

rvz 6mo ago

Ever since Microsoft's acquisition of GitHub 8 years ago, GitHub has completely enshittified and has become so unreliable, that even self-hosting a Git repository or self-hosted actions yourself would have a far better uptime than GitHub. This sounded crazy in 2020 when I said that in [0]. Now it doesn't in 2026 and many have realized how unreliable GitHub has become. If there was a prediction market on the next time GitHub would have at least one major outage per week, you would be making a lot of money since it appears that AI chatbots such as Tay.ai, Zoe and Copilot are somewhat in charge of wrecking the platform. Any other platform wouldn't tolerate such outages. [0] https://news.ycombinator.com/item?id=22867803 https://news.ycombinator.com/item?id=22867803

_pdp_ 6mo ago

https://news.ycombinator.com/item?id=47315878 https://news.ycombinator.com/item?id=47315878

_heimdall 6mo ago

I'm surprised GitHub got by acting fairly independently inside Microsoft for so long. I'm also surprised GitHub employees expected that to last The real problem today IMO is that Microsoft waited so long to drop the charade that they now felt like they had to rip the bandaid. From what I've heard the transition hasn't gone very smoothly at all, and they've mostly been given tight deadlines with little to no help from Microsoft counterparts.

eterm 6mo ago
If this were a place for memes, then I'd share that swimming pool meme with Microsoft holding up copilot while GitHub is drowning. Then Azure Dev Ops (formerly known as Visual Studio Team System) dead o n the ocean floor. Although given how badly GitHub seems to be doing, perhaps it's better to be ignored.
- sixeyes 6mo ago
  why is az devops on the floor? i am having to choose between the clients existing az dops and our internal gitlab for where to host a pipeline, and i don't know what would be good at all
  - eterm 6mo ago
    It works fine,it just feels like it has been under a kind of maintenance mode for a while. There's clearly one small team that works on it. There are pros and cons to that. It hasn't even got an obnoxious Copilot button yet for example, but on the other hand it was only relatively recently you could properly edit comments in markdown. If the client has existing AzDo Pipelines then I'd suggest keeping them there.
    - sixeyes 6mo ago
      thank you very much! that copilot comment got me, haha.
MoreQARespect 6mo ago

bentobean 6mo ago

“Microsoft Tentacle” - Now there’s a name for a new product line.

asimovDev 6mo ago
this comment reminded me that GitKraken was a thing. And still is, apparently

yurii_l 6mo ago

Maybe they need to improve release strategy with Copilot AI Review =)

cedws 6mo ago

While GitHub obsess over shoving AI into everything, the rest of the platform is genuinely crumbling and its security flaws are being abused to cause massive damage. Last week Aqua Security was breached and a few repositories it owns were infected. The threat actors abused widespread use of mutable references in GitHub Actions, which the community has been screaming about for years, to infect potentially thousands of CI runs. They also abused an issue GitHub has acknowledged but refused to fix that allows smuggling malicious Action references into workflows that look harmless. GHA can’t even be called Swiss cheese anymore, it’s so much worse than that. Major overhauls are needed. The best we’ve got is Immutable Releases which are opt in on a per-repository basis.

ljm 6mo ago
I worry that CI just got overcomplicated by default when providers started rocking up with templated YAML and various abstractions over it to add dynamic behaviour, dependencies, and so on. Perhaps mixing the CI with the CD made that worse because usually deployment and delivery has complexities of its own. Back in the day you'd probably use Jenkins for the delivery piece, and the E2E nightlies, and use something more lightweight for running your tests and linters. For that part I feel like all you need, really, is to be able to run a suite of well structured shell scripts. Maybe if you're in git you follow its hooks convention to execute scripts in a directory named after the repo event or something. Forget about creating reusable 'actions' which depend on running untrusted code. Provide some baked in utilities to help with reporting status, caching, saving junit files and what have you. The only thing that remains is setting up a base image with all your tooling in it. Docker does that, and is probably the only bit where you'd have to accept relying on untrusted third parties, unless you can scan them and store your own cached version of it. I make it sound simpler than it is but for some reason we accepted distributed YAML-based balls of mud for the system that is critical to deploying our code, that has unsupervised access to almost everything. And people are now hooking AI agents into it.
- Hasnep 6mo ago
  I'm trying out SelfCI [1] for one of my projects and it's similar to what you were describing. My whole CI pipeline is just a shell script that runs the actual build and test commands, I can write a script in another language like python if I need more complexity and I can run it all locally at any time to debug. [1] https://app.radicle.xyz/nodes/radicle.dpc.pw/rad%3Az2tDzYbAXxTQEKTGFVwiJPajkbeDU https://app.radicle.xyz/nodes/radicle.dpc.pw/rad%3Az2tDzYbAX...

pluc 6mo ago

I'm amazed Microslop let us keep GitHub this long. Probably because they're training AI on it? To have a direct line to developers? I don't see why else they would've bothered with something that was so anti everything they stood for

g947o 6mo ago
What does Microsoft stand for?
- cozzyd 6mo ago
  Making Incrementally Crappier Repositories, Operating Systems, Office and any Future Technology
  - jmaw 6mo ago
    you misspelled MicroSlop
- pluc 6mo ago
  Control. Gatekeeping. Profits. Proprietary technology. Licenses.

martinald 6mo ago

I wonder how much of this is down to the massive amount of new repos and commits (of good or bad quality!) from the coding agents. I believe that the App Store is struggling to keep up with (mostly manual tbf) app reviews now, with sharp increases in review times. I find it hard to believe that an Azure migration would be that detrimental to performance, especially with no doubt "unlimited credit" to play with? You can provision Linux machines easily on Azure and... that's all you need? Or is the thinking that without bare metal NVMe mySQL it can't cope (which is a bit of a different problem tbf).

grafporno 6mo ago
This reminds me of when i looked up how many actions runs the openclaw repo triggers. 700k as of now.
garettmd 6mo ago
I think part of the issue is that Azure has been struggling to reliably provision Linux VMs. Whether that's due to increased load, poor operational execution, or a combination of them, it's hard for anyone on the outside to know.

cl0ckt0wer 6mo ago

Cheap, fast, and good. I see which two they chose.

akshitgaur2005 6mo ago
They didn't even choose two, only one :)
bengale 6mo ago
Two?

mikeve 6mo ago

Just to add a little bit of nuance to this not because I'm trying to defend GitHub, they definitely need to up their reliability, but the 90% uptime figure represents every single service that GitHub offers being online 90% of the time. You don't need every single service to be online in order to use GitHub. For example, I don't use Copilot myself and it's seen a 96.47% uptime, the worst of the services which are tracked.

crote 6mo ago
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.
klabb3 6mo ago
> 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.
pier25 6mo ago
96% is horrible uptime though
ruszki 6mo ago
Here is the same thing in 2019: https://web.archive.org/web/20190510070456/https://www.githubstatus.com/ https://web.archive.org/web/20190510070456/https://www.githu... It seems that the same metric is about a magnitude worse than before.
6mo ago

dijit 6mo ago

I’m surprised it’s even as high as three nines, at one point in 2025 it was below 90%; not even a single nine.[0] (which, to be fair includes co-pilot, which is the worst of availabilities). People on lobsters a month ago were congratulating Github on achieving a single nine of uptime.[1] I make jokes about putting all our eggs in one basket under the guise of “nobody got fired for buying x; but there are sure a lot of unemployed people”- but I think there’s an insidious conversation that always used to erupt: “Hey, take it easy on them, it’s super hard to do ops at this scale”. Which lands hard on my ears when the normal argument in favour of centralising everything is that “you can’t hope to run things as good as they do, since there’s economies of scale”. These two things can’t be true simultaneously.. this is the evidence. [0]: https://mrshu.github.io/github-statuses/ https://mrshu.github.io/github-statuses/ [1]: https://lobste.rs/s/00edzp/missing_github_status_page#c_3cxesk https://lobste.rs/s/00edzp/missing_github_status_page#c_3cxe...

tpmoney 6mo ago
> These two things can’t be true simultaneously Sure they can. Perhaps a useful example of something like this would be to consider cryptography. Crypto is ridiculously complex and difficult to do correctly. Most individual developers have no hope of producing good cryptographic code on the same scale and dependability of the big crypto libraries and organizations. At the same time these central libraries and organizations have bugs, mistakes and weaknesses that can and do cause big problems for people. None of that changes the fact that for most developers “rolling your own crypto” is a bad idea.
- dijit 6mo ago
  That’s an excellent example. OpenSSL, by virtue of trying to do everything is the most buggy implementation of TLS generally available today leading to the point where there have been hard forks designed to reduce the scope to limit this damage. I’d go so far as to say that there are more crypto libraries than there are “default” options for SaaS Git VCS (Gitlab and Github are the mainstay in companies and maybe Azure Devops if you hate your staff- nobody sensible is using bitbucket) but for TLS implementations there’s RustTLS, GnuTLS, BoringSSL, LibreSSL, WolfSSL, NSS, and AWS-LC that come to mind immediately.

iwontberude 6mo ago

Three nines is more than enough

Ygg2 6mo ago
In the future, no one will need more than one and a half nines.
- iwontberude 6mo ago
  Yeah I agree

amelius 6mo ago

It's time to look for a decentralized Non-Hub alternative.

AlienRobot 6mo ago
Github without hub? I don't think that exists.
- bigDinosaur 6mo ago
  Email?
  - amelius 6mo ago
    More like Git, without the Hub. Perhaps the Hub aspects can be stored in Git as well?
    - esafak 6mo ago
      https://radicle.xyz/ https://radicle.xyz/
technoweenie 6mo ago
https://tangled.org https://tangled.org builds on atproto for the social features.

William_BB 6mo ago

To me, Github has always seemed well positioned to be a one-stop solution for software development: code, CI/CD, documentation, ticket tracking, project management etc. Could anyone explain where they failed? I keep hearing that Github is terrible

CharlieDigital 6mo ago
We use GH and are investing more in the platform features. Codespaces specifically is quite good for agent heavy teams. Launch a full stack runtime for PRs that are agent owned. > keep hearing that Github is terrible I do not doubt people are having issues and I'm sure there have been outages and problems, but none that have affected my work for weeks. GH is many things to many teams and my sense is that some parts of it are currently less stable than others. But the overall package is still quite good and delivers a lot of value, IMO. There is a bit of an echo chamber effect with GH to some degree.
- maccard 6mo ago
  We use GitHub actions and we have more build failures from actions than we do any other source.
conartist6 6mo ago
It always starts out good enough, but the reason they pursue horizontal integration is that it ensures that you won't be able to get out even if (when) you eventually want to. You'll be as glued as a fly to flypaper. That's the reason you hear the complaints: they're from people who no longer want to be using this product but have no choice. Because Microsoft doesn't need to innovate or even provide good service to keep the flies glued, they do what they've been doing: focus all their resources on making the glue stickier rather than focusing on making people want to stay even if they had an option to leave.
esafak 6mo ago
They got acquired by Microsoft.

kgwxd 6mo ago

Just use git, problem solved.

ankit7000 6mo ago

[dead]

neonihil 6mo ago

Nothing unexpected. Microsoft has a remarkable talent for turning good products into useless ones. Skype is another good showcase of such talent.

throw10920 6mo ago
Windows (including Notepad and Explorer), too. I think ~Office~ ~Office 365~ ~Microsoft 365~ Copilot 365 is still technically useful despite the insane branding and licensing and AI slop features, but I doubt it'll last much longer.
narrowtux 6mo ago
When will they introduce GitHub for Business?
- Traubenfuchs 6mo ago
  My company is on GitHub Enterprise.
- brummm 6mo ago
  That has existed for a long time and predates the MS acquisition. It's called Github Enterprise.

ankit7000 6mo ago

[dead]

Alifatisk 6mo ago

Have anyone checked out the status page? It's actually way worse than I thought, I believe this is the first time I am actually witnessing a status page with truly horrible results. https://mrshu.github.io/github-statuses https://mrshu.github.io/github-statuses

apetresc 6mo ago
Well then clearly you haven't taken a look at https://status.claude.com https://status.claude.com.
- bombcar 6mo ago
  This is ... surprisingly honest? The one above is "missing" status page; and most status pages would legally have to be filed in the "fiction" section of the library.
- dathinab 6mo ago
  At that 3rd party side GH is currently noticeable worse then claude ... Like they are down to one 9 availability and very very close to losing that to (90.2x%). This also fit more closely to my personal experience, then the 99.900-99.989 range the article indicates... Through honestly 99.9% means 8.76h downtime a year, if we say no more then 20min down time per 3 hours (sliding window), and no more then 1h a day, and >50% downtime being (localized) off-working hours (e.g. night, Sat,Sun) then 99.9% is something you can work with. Sure it would sometimes be slightly annoying. But should not cause any real issues. On the other hand 90.21%... That is 35.73h outage a year. Probably still fine if for each location the working hour availability is 99.95% and the previous constraints are there. But uh, wtf. that just isn't right for a company of that size.
  - kbelder 6mo ago
    You may have fumbled the calculator at one point. 20Min per 3 hours is 88.8% uptime. 99.9% uptime is 11 seconds down.
    - 6mo ago

anonym29 6mo ago

Not owned by companies that help the US Federal Government illegally spy on their own citizens and murder children overseas: Gitlab Bitbucket Sourceforge Forgejo Codeberg Radicle Launchpad Owned by companies that help the US Federal Government illegally spy on their own citizens and murder children overseas: Github

christoph-heiss 6mo ago
Neither Forgejo nor Codeberg are owned by _any_ company. Very important distinction.
megous 6mo ago
Codeberg is nice.

ajhenrydev 6mo ago

I worked on the react team while at GitHub and you could easily tell which pages rendered with react vs which were still using turbo. I wish we took perf more seriously as a culture there

CodingJeebus 6mo ago
Did react render better than turbo or the opposite? I assume a well-optimized turbo page would perform better
- ajhenrydev 6mo ago
  React destroyed perf and used more resources than turbo
  - CodingJeebus 6mo ago
    That's what I figured and has been my experience as well.
  - pier25 6mo ago
    Was there any discussion to use something other than react?

pscanf 6mo ago

I only use GitHub (and actions) for personal open-source projects, so I can't really complain because I'm getting everything for free¹. But even for those projects I recently had to (partially) switch actions to a paid solution² because GitHub's runners were randomly getting stuck for no discernible reason. ¹ Glossing over the "what they're getting in return" part. ² https://www.warpbuild.com/ https://www.warpbuild.com/

e-dant 6mo ago

Think the world would be a better place if 70-80% uptime were more tolerated. We really don’t need everything available all the time. More time to talk to each other, to think, more “slow time”. Just don’t like the slop that’s getting us there.

Anon1096 6mo ago

Anyone who used the phrase "measly" in relation to three nines is inadvertently admitting their lack of knowledge in massive systems. 99.9 and 99.95 is the target for some of the most common systems you use all day and is by no means easy to achieve. Even just relying on a couple regional AWS services will put your CEILING at three nines. It's even more embarrassing when people post that one GH uptime tracker that combines many services into 1 single number as if that means anything useful.

bitmasher9 6mo ago
Three 9s is a perfectly reasonable bar to expect for services you depend on. Without GitHub my company cannot deploy code. There is no alternative method to patch prod. In addition many development activities are halted, wasting labor costs. We wouldn’t couple so much if we knew reliability would be this low. It will influence future decisions.
deleted 6mo ago
[deleted]

dathinab 6mo ago

wait they still have 3 ninth, it really doesn't feel like that but then their status center isn't really trust-able anymore and a lot of temporary issues I have been running into seem to be temporary, partial, localized failures which sometimes fall under temp. slow to a point of usability. Temporary served outdated (by >30min) main/head. etc. so that won't even show up in this statistics

yifanl 6mo ago

https://mrshu.github.io/github-statuses/ https://mrshu.github.io/github-statuses/ Even ignoring Copilot, they seem to be barely at 2 nines of uptime for any service component.

flykespice 6mo ago

Why dont they just vibecode their way into stability? /s

sauercrowd 6mo ago

I'm somewhat surprised with Github's strategy in the AI times. I understand how appealing it is to build an AI coding agent and all that, but shouldn't they - above everything else - make sure they remain THE platform for code distribution, collaboration and alike? And it doesnt need to be humans, that can be agents as well. They should serve the AI agent world first and foremost. Cause if they dont pull that off, and dont pull off building one of the best coding agents - whcih so far they didnt - there isn't much left. There's so many new features needed in this new world. Really unclear why we hear so little about it, while maintainers smack the alarm bell that they're drowning in slop.

deleted 6mo ago
[deleted]
astralasia 6mo ago
Microsoft’s real goal is selling Copilot seats and pushing Azure, not building a neutral playground for third-party agents. There is just no money for them in being the backend for someone else's AI. As for the AI spam, GitHub's internal metrics have always been tied to engagement and PR volume. Blocking all that AI slop would instantly drop their growth numbers, so it is easier for them to just pass the cleanup cost onto open-source maintainers.
- sauercrowd 6mo ago
  No disagreement here. Just very short sighted.

m4tthumphrey 6mo ago

GitLab isn't much better right now either unfortunately.

ChrisArchitect 6mo ago

Feb 10th post OP; More recently: Addressing GitHub's recent availability issues https://github.blog/news-insights/company-news/addressing-githubs-recent-availability-issues-2/ https://github.blog/news-insights/company-news/addressing-gi... (with a smattering of submissions here the last few weeks but no discussion)

BANRONFANTHE 6mo ago

[flagged]

lijok 6mo ago

ITT lots of complaining, not much building. Microsoft does not give a fuck what you think - they only care if the revenue line goes up. And the revenue line keeps going up despite this instability. Want to build the next unicorn? Build a GitHub competitor.

jghn 6mo ago

Why have five nines when you can have nine fives?

1970-01-01 6mo ago

IPv6 ignorance is the canary. There's plenty of architecture ignorance below the surface. The real question is why aren't they failing annual security audits? https://docs.github.com/en/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/accessing-compliance-reports-for-your-organization https://docs.github.com/en/enterprise-cloud@latest/organizat...

PunchyHamster 6mo ago
Coz the audits have same quality as architecture lmfao

827a 6mo ago

I don't want to give too much credit to Github, because their uptime is truly horrendous and they need to fix it. But: I've felt like its a little unfair to judge the uptime of company platforms like this; by saying "if any feature at all is down, its all down" and then translating that into 9s for the platform. I never use Github Copilot; it does go down a lot, if their status page is to be believed; I don't really care when it goes down, because it going down doesn't bring down the rest of Github. I care about Github's uptime ignoring Copilot. Everyone's slice of what they care about is a little different, so the only correct way to speak on Github's uptime is to be precise and probably focus on a lot of the core stuff that tons of people care about and that's been struggling lately: Core git operations, website functionality, api access, actions, etc.

lucideer 6mo ago
You're right that labelling any outage as "Github is down" is an overgeneralisation, & we should focus on bottlenecks that impact teams in a time sensitive matter, but that isn't the case here. Their most stable service (API) has only two 9s (99.69%). They're not even struggling to get their average to three 9s, they're struggling to get ANY service to three 9s. They're struggling to get many services to two 9s. Copilot may be the least stable at one 9, but the services I would consider most critical (Git & Actions) are also at one 9.
- calvinmorrison 6mo ago
  ONLY TWO NINES! Meanwhile vital government services here have a whopping 25% availability.
  - lucideer 6mo ago
    Two things can be bad.
  - bigfishrunning 6mo ago
    Lemme guess, those government services are run by the lowest bidder?

DailyGeo 6mo ago

The availability expectations gap is interesting from an education standpoint. Students are tought that 99.9% sounds impressive without contextualizing what that means in practice — roughly 8 hours of downtime per year. For a platform that millions of developers depend on as critical infrastructure during work hours, that math hits very differently than it does for a consumer app.

outside2344 6mo ago

I have a little bit of sympathy for Github because if everyone is like me then they are getting 5-6x the demand they were last year just based on sheer commits alone, not to mention Github Copilot usage.

jtokoph 6mo ago

Pretty soon, the only 9 they’re going to have is the 9 8s…

jedberg 6mo ago

GitHub is in a tough spot. From what I've heard they've been ordered to move everything to Azure from their long standing dataceners. That is bound to cause issues. Then on top of that they are using AI coders for infra changes (supposedly) which will also add issues. And then on top of all that, their traffic is probably skyrocketing like mad because of everyone else using AI coders. Look at popular projects -- a few minutes after an issue is filed they have sometimes 10+ patches submitted. All generating PRs and forks and all the things. That can't be easy on their servers. I do not envy their reliability team (but having been through this myself, if you're reading this GitHub team, feel free to reach out!).

nilkn 6mo ago
> Look at popular projects -- a few minutes after an issue is filed they have sometimes 10+ patches submitted. All generating PRs and forks and all the things. I think this is a really important point that is getting overlooked in most conversations about GitHub's reliability lately. GitHub was not designed or architected for a world where millions of AI coding agents can trivially generate huge volumes of commits and PRs. This alone is such a huge spike and change in user behavior that it wouldn't be unreasonable to expect even a very well-architected site to struggle with reliability. For GitHub, N 9s of availability pre-AI simply does not mean the same thing as N 9s of availability post-AI. Those are two completely different levels of difficulty, even when N is the same.
- pojzon 6mo ago
  Not even talking about how useless it is to create tens of PRs to solve the same issue. But GitHub karma botting is a thing now. Remember those elitist ppl who removed answers on stackoverflow coz their answer is better with 90000 answers? Yup, now they are on GitHub farming karma with bots.
- zackwu 6mo ago
  yeah this is indeed a good insight. Back in the days, who would expect so many bots to "review" code and leave overly verbose comments under every PR in a popular repo?

dzonga 6mo ago

when GitHub moved to react instead of server rendered pages ie erb/turbolinks/pjax was the start to the end. the pages got slower, rendering became a nightmare. then they introduced GitHub actions (half baked) - again very unreliable then they introduced Copilot - again not very reliable it's easy to see why availability has gone down the drain. are they still on the rails monolith ? they speak about it less these days ?

onionisafruit 6mo ago
I’m not disagreeing, but I think you have the order wrong. Half baked actions was released before they moved to react. I’m talking about the version that used hcl for config instead of yaml.

unhidden 6mo ago

The 37 minutes of downtime last week cost us a deploy window during market hours. What's underappreciated: it's not just the raw downtime, it's that every CI/CD pipeline, every webhook, every deployment gate has GitHub as a single point of failure now. The centralization risk is real.

fHr 6mo ago

[flagged]

caconym_ 6mo ago

Legitimately worse uptime than my self-hosted services. That's pretty funny.

swisniewski 6mo ago

To be honest, I’m not surprised that GitHub has been having issues. If you have ever operated GitHub Enterprise Server, it’s a nightmare. It doesn’t support active-active. It only supports passive standbys. Minor version upgrades can’t be done without downtime, and don’t support rollbacks. If you deploy an update, and it has a bug, the only thing you can do is restore from backup leading to data loss. This is the software they sell to their highest margin customers, and it fails even basic sniff tests of availability. Data loss for source code is a really big deal. Downtime for source control is a really big deal. Anyone that would release such a product with a straight face, clearly doesn’t care deeply about availability. So, the fact that their managed product is also having constant outages isn’t surprising. I think the problem is that they just don’t care.

sc68cal 6mo ago
My $JOB ended up giving up on GHES and migrating to GHEC because of these exact issues.
hawaiianbrah 6mo ago
I worked on GHES for a couple of years. Before that, it sounded like it was a sort of volunteer rotation, there wasn’t durable funding for a team when we joined. Mind boggling that the money maker of the company was staffed like that. It is a complicated project. Thankfully their durable funding story has improved in recent years and they are staffing GHES up at levels they haven’t for at least 7 years. Hopefully it improves. I’m not there anymore, I was laid off last year.

Andrei_dev 6mo ago

Our security scanning runs on GitHub Actions — every PR gets checked before merge. When GitHub goes down, the security gate goes down with it. PRs pile up, devs get impatient, start merging without waiting for checks. That's exactly when bad code gets through. And they keep throwing engineers at Copilot while the stuff that CI/CD actually depends on keeps falling over.

lvkv 6mo ago
Do you have one or more public examples of this?
- Andrei_dev 6mo ago
  [flagged]

pacman1337 6mo ago

The irony no one is talking about: AI makes quality code worse. Was bad enough already so imagine it now. I am expecting many more services to drop from 3 nines to 1 nine.

kylehotchkiss 6mo ago

https://status.claude.com https://status.claude.com _anthropic has entered the room_

mosaibah 6mo ago

[dead]

azalemeth 6mo ago

Embrace, extend, extinguish. Except the last one isn't quite going to plan...

graphememes 6mo ago

It's wild because they are one of the most used properties on earth and their uptime is actually incredible.

alfalfasprout 6mo ago
It's not though... it's sitting a hair above 90%
- graphememes 6mo ago
  My comment is that I expect it to be more frequent and less given the scale and usage. Quite honestly, we have the most insane expectations about uptime and availability in my opinion. I'm glad that we can meet them. But still, insane.
  - SahAssar 6mo ago
    If something is unfixably broken 1 out of 10 times I use it I will just consider it broken. 1 out of 100 is unreliable but usable. That goes for most things physical and digital.
MeetingsBrowser 6mo ago
Define incredible. https://mrshu.github.io/github-statuses/ https://mrshu.github.io/github-statuses/ Overall uptime is 90% (single nine), and the best individual service at 99.8% (two nines). The core git functionality itself is at 98.98%, which works out to being down roughly a full business day each month.
- graphememes 6mo ago
  Not bad
  - MeetingsBrowser 6mo ago
    At the risk of going recursive, how do you define not bad? Could be worse?

Robdel12 6mo ago

It is annoying. But I bet they’re effectively being DDoS’d every day by AI agents now. I think the past year of that growth has destroyed any of their spare resources. It’s not really a scale problem I’d like to work on, tbh. Seems very hard. Plus, the azure migration.

pfdietz 6mo ago

Hey, it's better than nine threes.

Achiyacohen 6mo ago

[dead]

malephex 6mo ago

Ruby?

gfody 6mo ago
I suspect mysql over rails.. I imagine the push for azure is to facilitate migrating from mysql to sql server (azure sql)

nubinetwork 6mo ago

Has Microsoft fixed teams crashing outlook? It's been broken since Wednesday, and the last thing I heard on Friday was that they were going to wait until Monday... really goes to show how much Microsoft cares these days...

2OEH8eoCRo0 6mo ago

There must be a lot of software "engineering" going on at github

frellus 6mo ago

Love the Register, but ... everyone has sort of known this for the past 10+ years if they've relied on GitHub with any sort of velocity.

ahstilde 6mo ago

yeah, between github and claude they're's an outage 75% of the time: https://www.aakash.io/tech-chase/github-and-claude-are-down-three-out-of-four-days https://www.aakash.io/tech-chase/github-and-claude-are-down-...