alt.hn

3/31/2026 at 7:01:29 PM

GitHub's Historic Uptime

 https://damrnelson.github.io/github-historical-uptime/

by todsacerdoti

3/31/2026 at 7:45:26 PM

Is the pre-2018 data actually accurate? There seem to have been a number of outages before then: https://hn.algolia.com/?dateEnd=1545696000&dateRange=custom&...

Maybe that's just the date when they started tracking uptime using this sytem?

by fishtoaster

3/31/2026 at 8:12:22 PM

Data comes from the official status page. It may be more a marketing/communication page than an observability page (especially before selling)

by OlivOnTech

3/31/2026 at 9:17:13 PM

The status page was often down when GH was down, back in the days.

by pikzel

4/1/2026 at 1:41:14 AM

I could imagine a leadership or viewpoint change in how they reported when/what was down.

I've seen so many times where Company A will complain that their vendors aren't accurate enough about uptime and how Company A notices first that their vendors are down, but then they themselves have a very laggy or inaccurate status page.

We want our vendors to be accurate to the minute on these, but many CTOs don't care to admit when they too have problems.

by tibbon

3/31/2026 at 10:05:55 PM

Aha we need a status page of status page.

by xiaoyu2006

4/1/2026 at 1:47:15 AM

Sup dawg I heard you like status pages.

by BrenBarn

4/1/2026 at 3:24:26 AM

i assume they simply fixed the status page in 2018.. lol.

by w0m

3/31/2026 at 7:34:09 PM

Even better IMO is this status page: https://mrshu.github.io/github-statuses/

"The Missing GitHub Status Page" with overall aggregate percentages. Currently at 90.84% over the last 90 days. It was at 90.00% a couple days ago.

by mholt

3/31/2026 at 7:46:13 PM

It has been pretty rough. Their own numbers report just a single `9` for Actions in Feb 2026 with 98% uptime. But that said -- I don't get the 90% number.

Anecdotally, it seems believable that 1 in 50 times (2%) in Feb that Actions barfed. Which is not very nice, but it wasn't at 1 in 10 times (10%).

by montroser

3/31/2026 at 7:56:54 PM

It looks like the aggregate stats are more of a venn diagram than an average. So if 1/N services are down, the aggregate is considered down. I don't think this is an accurate way to calculate this. It should be weighted or in some way show partial outages. This belief is derived from the Google SRE book, in particular chapters 3 (embracing risk) and 4 (service level objectives)

https://sre.google/sre-book/embracing-risk/

https://sre.google/sre-book/service-level-objectives/

by verdverm

3/31/2026 at 8:33:44 PM

If you're using all services, then any partial outage is essentially a full outage. Of course, you can massage the numbers to make it look nicer in the way you described but the conservative approach is better for the customers. If you insist, one could create this metric for selected services only to "better reflect users".

That being said, even when looking at the split uptimes, you'd have to do a very skewed weighting to achieve a number with more than one 9.

by ablob

3/31/2026 at 9:08:11 PM

> That being said, even when looking at the split uptimes, you'd have to do a very skewed weighting to achieve a number with more than one 9.

It's definitely bad no matter how it you slice the pie.

If GH pages is not serving content, my work is not blocked. (I don't use GH pages for anything personally)

by verdverm

3/31/2026 at 8:34:42 PM

That's how you count uptime. You system is not up if it keeps failing when the user does some thing.

The problem here is the specification of what the system is. It's a bit unfair to call GH a single service, but it's how Microsoft sells it.

by marcosdumay

4/1/2026 at 4:32:37 AM

As a “customer”, I consider github down if I can’t push, but not down if I can’t update my profile photo (literally did this today, sending out my github to potential employers for the first time in a long time). This stuff is notoriously hard to define

by tbossanova

3/31/2026 at 9:03:28 PM

> That's how you count uptime.

It's not how I and many others calculate uptime. There is not uniformity, especially when you look at contracts.

by verdverm

4/1/2026 at 1:51:43 AM

Thinking back to when I was hosting, I think telling a customer "your web server was running fine it's just that the database was down" would not have been received well.

by bandrami

3/31/2026 at 8:27:56 PM

I mean I think it's useful. It answers the question, "what percentage of the time can I rely on every part of GitHub to work correctly?". The answer seems to be roughly 90% of the time.

by mort96

3/31/2026 at 8:33:29 PM

Nobody cares about every part of GitHub working correctly. I mean, ok, their SREs are supposed to, but tabling the question of whether that's true: if tomorrow they announced a distributed no-op service with 100% downtime, you should not have the intuition that the overall availability of the platform is now worse.

by naniwaduni

3/31/2026 at 8:47:44 PM

In a nutshell, why would the consumer care (for the SLO) care about how the vendor sliced the solution into microservices?

by formerly_proven

3/31/2026 at 8:59:43 PM

It will depend on the contract.

When I was at IBM, they didn't meet their SLOs for Watson and customers got a refund for that portion of their spend

by verdverm

3/31/2026 at 7:46:38 PM

An aggregate number like that doesn’t seem to be a reasonable measure. Should OpenAI models being unavailable in CoPilot because OpenAI has an outage be considered GitHub “downtime”?

by fontain

3/31/2026 at 8:29:55 PM

As long as they brand it as a part of GitHub by calling it "GitHub Copilot" and integrate it into the GitHub UI, I think it's fair game.

by mort96

4/1/2026 at 3:56:04 PM

The third-party aspect is irrelevant, but while high downtime on any product looks bad for the company and the division, I consider GitHub Copilot an entirely separate product from GitHub, and GitHub Copilot downtime doesn't interfere with my use of GitHub repos or vice versa, so I'd consider its downtime separately.

GitHub Actions, on the other hand, is frequently used in the same workflows as the base GitHub product, so it's worth considering both separately and together, much like various Azure services, whereas I see no reason at all to consider an aggregate "Microsoft" downtime metric that includes GitHub, Azure, Office 365, Xbox Live, etc.

The most useful, metric, actually, is "downtimes for the various collections of GitHub services I regularly use together", but that would obviously require effort to collect the data myself.

by jasomill

4/1/2026 at 5:05:02 PM

My use of GitHub is like yours; I depend on Actions, but I couldn't give less of a damn about Copilot. However, Microsoft has tried to get people to adopt Copilot-heavy workflows, where Copilot plays an integral part in the pull request review process. If your process is as Microsoft pushes for -- wait for Copilot to comment, then review and resolve the stuff Copilot points out -- then Copilot being down means you can't really handle pull request, at least not in accordance with your standard process. For people who embrace Copilot in the way Microsoft wants them to, a GitHub Copilot outage has a serious impact on their GitHub experience.

by mort96

3/31/2026 at 8:34:21 PM

What is Google's uptime (including every single little thing with Google in the name)?

by mememememememo

3/31/2026 at 8:45:07 PM

I don't think that's a fair comparison. Google Maps, Google Calendar, Google Drive, Google Search, Google Chrome, Google Ads, etc. are all clearly completely different products which have very little to do each other, they're just made by the same company called Google.

GitHub is a different situation. There's one "thing" users interact with, github.com, and it does a bunch of related things. Git operations, web hooks, the GitHub API (and thus their CLI tool), issues, pull requests, Actions; it's all part of the one product users think of as "GitHub", even if they happen to be implemented as different services which can fail separately.

EDIT: To illustrate the analogy: Google Code, Google Search and Google Drive are to Google what Microsoft GitHub, Microsoft Bing and Microsoft SharePoint are to Microsoft.

by mort96

3/31/2026 at 9:00:20 PM

Completely agree, it makes it worse actually as Github's secondary functions so to speak are things we implicitely rely on.

When I merge to master I expect a deploy to follow. This goes through git, webhooks and actions. Especially the latter two can fail silently if you haven't invested time in observation tools.

If maps is down I notice it and immediately can pivot. No such option with Github.

by Kaliboy

3/31/2026 at 9:38:23 PM

It depends, for example - I would consider Google Drive uptime as part of say Google Docs’ overall uptime because if I can’t access my stored documents or save a document I’ve been working on for the past 3 hours because Drive is down I would be very pissed and wouldn’t care if it’s Drive or Docs that is the problem underneath I still can’t use Google Docs as a service at that point.

by dogma1138

3/31/2026 at 8:06:45 PM

I think reasonable people can disagree on this.

From the point of view of an individual developer, it may be "fraction of tasks affected by downtime" - which would lie between the average and the aggregate, as many tasks use multiple (but not all) features.

But if you take the point of view of a customer, it might not matter as much 'which' part is broken. To use a bad analogy, if my car is in the shop 10% of the time, it's not much comfort if each individual component is only broken 0.1% of the time.

by fwip

3/31/2026 at 8:33:14 PM

> But if you take the point of view of a customer, it might not matter as much 'which' part is broken. To use a bad analogy, if my car is in the shop 10% of the time, it's not much comfort if each individual component is only broken 0.1% of the time.

Not to go too out of my way to defend GH's uptime because it's obviously pretty patchy, but I think this is a bad analogy. Most customers won't have a hard reliability on every user-facing gh feature. Or to put it another way there's only going to be a tiny fraction of users who actually experienced something like the 90% uptime reported by the site. Most people are in practice are probably experienceing something like 97-98%.

by remus

3/31/2026 at 8:59:19 PM

Sorry, by 'customer' I meant to say something like a large corporate customer - you're buying the whole package, and across your org, you're likely to be a little affected by even minor outages of niche services.

But yeah, totally agree that at the individual level, the observed reliability is between 90% and 99%, and probably toward the upper end of that range.

by fwip

3/31/2026 at 8:35:36 PM

Or if your kettle is not working the house is considered not working?

by mememememememo

3/31/2026 at 10:12:16 PM

I've been on a flight that was late leaving the gate because the coffeemaker wasn't working.

by Polizeiposaune

3/31/2026 at 8:56:50 PM

A better analogy is if one bulb in the right rear brake light group is burnt out. Technically the car is broken. But realistically you will be able to do all the things you want to do unless the thing you want to do is measure that all the bulbs in your brake lights are working.

by wang_li

3/31/2026 at 10:13:07 PM

That's an awful analogy because "realistically you will be able to do all the things you want to do". If a random GitHub service goes down there's a significant chance it breaks your workflow. It's not always but it's far from zero.

One bulb in the cluster going out is like a single server at GitHub going down, not a whole service.

by Dylan16807

3/31/2026 at 7:45:01 PM

These are two pages telling two different things, albeit with the same stats. The information is presented by OP in a way to show the results of the Microsoft acquisition.

by skipants

4/1/2026 at 1:37:21 AM

holy shit that's nearly five weeks of down time.

Well, I mean, I guess that's fair really. How long has github been around? Surely it's got five weeks of paid time off by now...

by goodmythical

3/31/2026 at 7:50:03 PM

It’s biaised to show this without the dates at which features were introduced. A lot of the downtimes in the breakdown are GitHub Actions, which launched in August 2019; so yeah what a surprise there was no Actions downtime before because Actions didn’t exist.

by hk__2

3/31/2026 at 8:03:16 PM

You can click on "Breakdown" and then on "Actions" to hide it.

by cuu508

3/31/2026 at 8:05:44 PM

Even worse, those features show "100% uptime" pre-existence on the breakdowns page too.

by mbauman

3/31/2026 at 9:57:54 PM

This is the real questionable part of the graphic. It seems that no-data pre 2018 was just considered 100% uptime (which is hardly historically accurate).

by siruwastaken

3/31/2026 at 8:35:01 PM

Check the breakdown page. Like yes the magnitude is reduced obviously for individual services. But they all show the same trend.

by voxic11

4/1/2026 at 7:39:25 AM

I checked the breakdown page, as I wrote:

> A lot of the downtimes in the breakdown are GitHub Actions

by hk__2

3/31/2026 at 7:34:22 PM

I got Claude to make me the exact same graph a few weeks ago! I had hypothesized that we'd see a sharp drop off, instead what I found (as this project also shows) is a rather messy average trend of outages that has been going on for some time.

The graph being all nice before the Microsoft acquisition is a fun narrative, until you realize that some products (like actions, announced on October 16th, 2018) didn't exist and therefore had no outages. Easy to correct for by setting up start dates, but not done here. For the rest that did exist (API requests, Git ops, pages, etc) I figured they could just as easily be explained with GitHub improving their observability.

by shrinks99

3/31/2026 at 8:42:49 PM

It feels like they launched actions and it quickly turned out to be an operations and availability nightmare. Since then, they've been firefighting and now the problems have spread to previously stable things like issues and PRs

by padjo

3/31/2026 at 9:48:51 PM

They rushed to launch Actions because GitLab launched them before.

BTW, GitLab called it "CI/CD" just as a navigation section on their dashboard, and that name spread outside as well, despite being weird. Weird names are easier to remember and associate with specific meaning, instead of generic characterless "Actions".

by deepsun

3/31/2026 at 10:29:10 PM

We added Actions for CI in 2020. A year later realized our entire deploy pipeline just assumed it would be up.

Webhook doesn't fire, nothing errors out, and you find out when someone asks why staging hasn't moved in two days.

by nulltrace

4/1/2026 at 2:02:51 PM

[dead]

by jamiemallers

3/31/2026 at 7:39:19 PM

Github actions needs to go away. Git, in the linux mantra, is a tool written to do one job very well. Productizing it, bolting shit onto the sides of it, and making it more than it should be was/is a giant mistake.

The whole "just because we could doesn't mean we should" quote applies here.

by irishcoffee

3/31/2026 at 7:53:14 PM

But GitHub actions is not Git?

by psini

4/2/2026 at 12:17:29 AM

Sorry yes, that was my point. GitHub turned git into some dysmorphic DVCS version of c++ on the web. Git is fine. Maybe 10% of people use plain git, it’d all wrapped in shitty web apps. Let git be git, and let ci/cd be ci/cd, the way Linux intended.

However, I don’t work on web apps. Maybe it’s better for the JavaScript folks. I hope to never write a line of js in my lifetime.

by irishcoffee

3/31/2026 at 7:55:40 PM

The same philosophy would suggest that running some other command immediately following a particular (successful) git command is fine; it is composing relatively simple programs into a greater system. Other than the common security pitfalls of the former, said philosophy has no issue with using (for example) Jenkins instead of Actions.

by lcnPylGDnU4H9OF

3/31/2026 at 9:34:02 PM

[flagged]

by irishcoffee

3/31/2026 at 11:10:38 PM

Yes.

by lcnPylGDnU4H9OF

3/31/2026 at 7:33:13 PM

FWIW if people are looking for a reason why, here's why I think it's happening: https://thenewstack.io/github-will-prioritize-migrating-to-a...

by phillipcarter

3/31/2026 at 8:34:57 PM

It's absolutely this. Our Azure outages correlate heavily with Github outages. It's almost a meme for us at this point.

by llama052

3/31/2026 at 8:17:05 PM

You'd think they'd do all the testing elsewhere and use a much shorter window of time to implement Azure after testing. I don't think this fully explains over 6 years of poor uptime.

by nmaleki

3/31/2026 at 8:35:55 PM

The fact that even they struggle with github actions is a real testimate to the fact that nobody wants to host their own CD workers.

by hadlock

3/31/2026 at 9:24:53 PM

> The fact that even they struggle with github actions is a real testimate to the fact that nobody wants to host their own CD workers.

What a weird takeaway

by esseph

3/31/2026 at 9:04:14 PM

It certainly explains the issues _now_, IMO.

by phillipcarter

3/31/2026 at 7:26:16 PM

I remember a lot of unicorn pages back in the days. Maybe the status page was just not updated that regularly back then?

by dewey

3/31/2026 at 7:47:39 PM

I think the unicorn is only for web pages. Things like git api services might be broken independently (and often are!) and they might show up on the status page after some time.

by imglorp

3/31/2026 at 8:53:02 PM

Historical *

https://www.merriam-webster.com/grammar/everything-youve-eve...

by topbanana

3/31/2026 at 9:38:11 PM

Bless you, was very much not what I was expecting from the title.

by tclancy

3/31/2026 at 11:10:51 PM

One could argue that, given how singularly awful it is, GitHub's historical uptime might qualify as "historic".

by teach

3/31/2026 at 7:25:20 PM

I feel like by now GitHub has a worse downtime record than my self hosted services on my single server where I frequently experiment, stop services or reboot.

by BadBadJellyBean

3/31/2026 at 7:35:33 PM

It's ok because we're still paying for it. QoS degradation is worth it. No need to have 99.999% then you can have 90.84% and still people to pay for it.

by agilob

3/31/2026 at 8:39:34 PM

Those electricity savings can better used to fuel the token bonfire

by verdverm

3/31/2026 at 8:43:29 PM

It does have a worse downtime record than my tiny VPS that has a recurrent packet routing problem and keeps going offline. Measurably so.

by marcosdumay

4/1/2026 at 5:13:39 AM

Scale changes the math. Your uptime chart would look like a crime scene too if a million people were pushing random crap at your server all day and every tiny hiccup could land on an open PR or a hot write path you forgot about. GitHub looks like old code glued to ancient VMs that people are scared to touch, so a small outage can drag into a wierdly long one.

by hrmtst93837

3/31/2026 at 9:22:35 PM

Github's migration to Azure has so far been a hilariously bad advertisement for Azure

by frenchie4111

3/31/2026 at 8:32:51 PM

I'm not a GitHub apologist, but that graph isn't at scale, at all. It's massively zoomed in, with a lower band of 99.5%. It makes it look far worse than it is.

by otterley

3/31/2026 at 9:02:51 PM

If you plotted it from zero, then a horrible service and a great service would be indistinguishable. Their SLA for enterprise customers is 99.9%. The low end of that chart is 5x that amount downtime. It is a reasonable scale for the range people are concerned about and it looks bad because it is bad.

by pavon

3/31/2026 at 8:37:33 PM

It's an uptime chart and shouldn't need to show much more than the 99% range.

If you started the y-axis at zero, you wouldn't see much of anything. Logarithmic scale would still be a bit much imo.

by verdverm

3/31/2026 at 8:59:44 PM

> If you started the y-axis at zero, you wouldn't see much of anything.

That's... kind of my point.

As a reliability engineer, I'm disappointed in GitHub's 99.5% availability periods, especially as they impact paying customers. On the other hand, most users are non-paying users, and a 99.5% availability for a free service seems to me to be a reasonable tradeoff relative to the potential cost of improving reliability for them.

by otterley

4/1/2026 at 2:25:11 PM

> the other hand, most users are non-paying users, and a 99.5% availability for a free service seems to me to be a reasonable tradeoff relative to the potential cost of improving reliability for them.

If they are using your data, you're still paying just not in cash.

As a former reliability engineer, I'm trying hard to remember back when we had multiple months in a row never reaching 100% uptime, and I can't. Yes, we've seen runs of painful months, but also runs of easy months without down time.

But let's talk root cause here, the cost of improving them here, is someone caring. This isn't simply a hard problem, it's a well understood hard problem that no one who makes decisions cares about. Which as a reliability engineer is an embarrassment. Uptime is one of those foundational aspects that you can build on top of. If you're not willing to invest in something as core as your code or service works. What are you even doing?

by grayhatter

4/1/2026 at 6:29:49 PM

> If you're not willing to invest in something as core as your code or service works. What are you even doing?

I think Microsoft is collecting rents. :)

by otterley

3/31/2026 at 9:37:07 PM

It also has 0 reflection of load. Weren't you limited to a single private repo before Microsoft took over?

by tclancy

3/31/2026 at 7:25:44 PM

Unsolicited feedback ... changing the y-axis to be hours (not % uptime) might be more intuitive for folks to understand.

The data is there, you just have to hover over each data point.

by alberth

3/31/2026 at 7:30:36 PM

It could even be both % and offline hours per year. To me the percentage is simpler to understand.

by simlevesque

3/31/2026 at 10:05:44 PM

I'd like to move off GitHub, and I deploy some websites using GitHub Pages, so I took a look at the availability of static web hosting; GH actually does really well on this metric, although Fastly, the CDN they use, should get the credit.

https://alexsci.com/blog/static-hosting-uptime/

by 8organicbits

3/31/2026 at 8:15:48 PM

Nearly every time Github has an outage, Azure is having issues also.

Actually the last 4-5 outages from Github, Our Azure environments have issues (that they rarely post on the status page) and lo and behold I'll notice that Github is also having the same problem.

I can only assume most of this is from the Azure migration path. Such an abysmal platform to be on. I loathe it.

Looks like there's an internal service health bulletin:

Impact Statement: Starting at 19:53 UTC on 31 Mar 2026, some customers using the Key Vault service in the East US region may experience issues accessing Key Vaults. This may directly impact performing operations on the control plane or data plane for Key Vault or for supported scenarios where Key Vault is integrated with other Azure services.

Honestly all of the key vault functions are offline for us in that region. Just another day in paradise.

Also the fact that the azure status page remains green is normal. Just assume it's statically green unless enough people notice.

by llama052

4/1/2026 at 4:50:57 AM

My impression is that, before Microsoft acquired GitHub, GitHub went for many years without really introducing new features, so part of its stability came from the fact that it wasn’t very ambitious or proactive about improving.

by chenzhekl

4/1/2026 at 5:56:21 AM

I loved that time. Websites, or "apps" that don't change every second time I want to use them, are great.

by ahofmann

3/31/2026 at 7:42:27 PM

I'm convinced one of my org's repos is just haunted now. It doesn't matter what the status page says. I'll get a unicorn about twice a day. Once you have 8000 commits, 15k issues, and two competing project boards, things seem to get pretty bad. Fresh repos run crazy fast by comparison.

by bob1029

3/31/2026 at 7:32:33 PM

It could also be that they have more customers / clients now, or offer more capabilities.

by SamuelAdams

3/31/2026 at 7:21:50 PM

Do we have metrics for the uptime of other major services? Would be interesting to see if this is just a GitHub problem or industry-wide.

by _air

4/1/2026 at 4:53:39 PM

Reminder to keep local backups of everything important while the reliability of all these services continues to degrade.

by davebren

3/31/2026 at 8:36:48 PM

It’s actually great to see a living example of how sensitive users* are to what to a lay person would look like a small amount of downtime.

The fact that we’re all talking about it, and not at all surprised, is a great example we can take when making the case for more 9’s of reliability.

* well, very technical power users.

by barryhennessy

3/31/2026 at 8:34:12 PM

How much of the downtime is due to all the AI code being committed?

by TimLeland

3/31/2026 at 8:39:25 PM

It is ridiculous how company owned by Microsoft, making non sense money on Azure, is let to die like this. That's have to be a soft of plan or something. So sad to watch it.

by landsman

3/31/2026 at 7:52:20 PM

GitHub is 100x the size today with 100x the product surface area. Pre-Microsoft GitHub was just a git host. Now, whether GitHub should have become what it is today is a fair question but to say “GitHub” is less stable today vs. 10 years ago ignores the significant changes. Also, much of these incidents are limited to products that are unreliable by nature, e.g: CoPilot depends on OpenAI and OpenAI has outages. The entire LLM API industry expects some requests to fail.

GitHub’s reliability could stand to be improved but without narrowing down to products these sort of comparisons are meaningless.

by fontain

3/31/2026 at 8:21:38 PM

> Pre-Microsoft GitHub was just a git host.

And even just that aspect of the service is now extremely unreliable. If outages in the LLM side can cause that to break, that would indicate some serious architectural problems.

by bigfatkitten

4/1/2026 at 4:55:19 PM

Sites are supposed to get more reliable as they grow and have more resources to allocate specifically towards site reliability.

by davebren

3/31/2026 at 8:04:47 PM

The article provides a way to do just that - click breakdown then you can deselect any product areas.

Just the Git operations show way more instability post acquisition.

by tln

3/31/2026 at 7:47:24 PM

This at least makes me feel like I am not going crazy when I say "Github used to be much more reliable before Microsoft bought them"

by robshippr

4/1/2026 at 2:28:50 PM

Historical, not historic. Extremely not historic.

by addaon

4/1/2026 at 6:39:00 AM

Based on the graphics, Microsoft doesn't seem to be doing very well

by joey5403

3/31/2026 at 7:31:29 PM

The significance of the changeover would be much more impactful if the chart showed a longer history.

by mcherm

3/31/2026 at 9:33:18 PM

Honestly I think their status page just got more honest -- and they are graphing this in such a way that any partial outage to any service looks really bad on teh chart.

There were definitely partial outages to services inside that row of horizontal green dots, that the status page just wasn't advertising.

by jrochkind1

3/31/2026 at 7:37:16 PM

I mean I'm as annoyed as the next person about the outages but I'm not sure correlating with the Microsoft acquisition tells the whole story? GitHub usage has been growing massively I'd imagine?

by yakkomajuri

3/31/2026 at 9:43:56 PM

I think you mean GitHub’s histrionic uptime.

by keybored

3/31/2026 at 8:16:52 PM

Programming is a solved problem, btw.

by wiseowise

3/31/2026 at 8:04:33 PM

I wonder if they got moved to Azure in 2019?

by redwood

3/31/2026 at 8:04:18 PM

I will chime in that Jira and Bitbucket have drastically improved performance and reliability over this same time period. It actually feels snappy and they seem to listen to feedback.

by verdverm

3/31/2026 at 7:54:15 PM

When I say that Microsoft writes very bad code some people get offended. For example for Azure Event Hubs they have almost no documentation and Java libraries that mostly do not run.

by darkhorn

3/31/2026 at 7:22:47 PM

That's pretty stark.

by josefritzishere

3/31/2026 at 7:55:21 PM

hot take: I would accept ads under every PR comment in GitHub if we could get back to 3 or 4 nines of reliability.

by qrush

3/31/2026 at 7:32:26 PM

I guess "centralizing everything" to GitHub was never a good idea and called it 6 years ago. [0]

Looking at this now, you might as well self host and you would still get better uptime than GitHub.

[0] https://news.ycombinator.com/item?id=22867803

by rvz

4/1/2026 at 7:01:17 PM

This has to feel a little vindicating.

by DerArzt

3/31/2026 at 8:06:11 PM

[dead]

by Jaco07

3/31/2026 at 7:49:36 PM

[flagged]

by theaicloser

3/31/2026 at 8:13:34 PM

Nearly all the variance is from Actions, a product that didn’t exist beforehand.

It’s despicable to see everyone punching down on GitHub. Even under Microsoft they’ve continued to provide an invaluable and free service to open source developers .

And now , while vibe coders smother them to death, we ridicule them . Shameful , really

by tonymet

3/31/2026 at 8:45:30 PM

I was with you until your comment about vibe coders. Microsoft paid for and brought this vibe coding hell upon themselves. GitHub Copilot, investment in/partnership with OpenAI, and everything else they’ve done to enshitify software and the internet.

If it brings them down, they’ve only themselves to blame. More likely it’ll just hasten the end of free public repos, which will be a shame, but we’ll find other ways to share code that aren’t reliant on one semi-benevolent megacorp.

by EdNutting

3/31/2026 at 8:51:42 PM

The smothering would happen with or without Copilot. This just sounds like an excuse to be ungrateful .

I hope GitHub shuts down free tier , maybe developers will finally be grateful .

by tonymet

3/31/2026 at 9:04:28 PM

I’m grateful for GitHub and their support for open source, but they’re not getting any sympathy for the AI mess they’re generating (and they’re contributing more to the mess than many other organisations, due to their size, position and product strategy).

They’re a big enough corporation that we can have nuanced feelings about them. Simultaneously grateful for one part of what they do, and unsympathetic for the consequences of a different part of what they do.

by EdNutting

3/31/2026 at 9:17:59 PM

true colors.

by tonymet

3/31/2026 at 9:45:59 PM

Mmm, you’ve shown yours too.

by EdNutting