Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Actions and Pages are experiencing degraded availability

githubstatus.com

Post reply on HN
Print view View original

231–240 of 446 posts

Re: GitHub Actions and Pages are experiencing degraded availability

#231

Post by mgh95 »

Wafje wrote: post #228
richwater wrote: post #227

Gotta wonder what they're up to over there. Is the AI slop that bad? Culture change?

Unprecedented load. From the GitHub COO on April 3rd: Platform activity is surging. There were 1 billion commits in 2025. Now, it's 275 million per week, on pace for 14 billion this year if growth remains linear (spoiler: it won't.) GitHub Actions has grown from 500M minutes/week in 2023 to 1B minutes/week in 2025, and now 2.1B minutes so far this week. So we're pushing incredibly hard on more CPUs, scaling services,…

I find this hard to believe in this context. They should be utilizing load shedding or admission control and killing/rejecting jobs rather than hard failures if it is a scaling issue. It's much more likely an actual software defect than just more load. If this was the case (which they would likely prefer) free/public tiers would be removed first to preserve paying customers services.

Re: GitHub Actions and Pages are experiencing degraded availability

#232

Post by maccard »

Wafje wrote: post #228
richwater wrote: post #227

Gotta wonder what they're up to over there. Is the AI slop that bad? Culture change?

Unprecedented load. From the GitHub COO on April 3rd: Platform activity is surging. There were 1 billion commits in 2025. Now, it's 275 million per week, on pace for 14 billion this year if growth remains linear (spoiler: it won't.) GitHub Actions has grown from 500M minutes/week in 2023 to 1B minutes/week in 2025, and now 2.1B minutes so far this week. So we're pushing incredibly hard on more CPUs, scaling services,…

They’ve said that, but it doesn’t add up. The outages started shortly after the migration to Azure became the top priority, and before the load massively increased form agentic coding (by their own dates).

Re: GitHub Actions and Pages are experiencing degraded availability

#233

Post by marricks »

javier123454321 wrote: post #229

This is unconscionable. It's an incredibly bad look to be up an entirety of a workday. When my company migrated from Bitbucket, I never thought that we'd be going to a worse service.

My own company had a migration from GitLab to supposedly greener pastures but at least when a self hosted gitlab server had an issue someone could figure out what was going on. Absolutely zero control over GitHub.

Re: GitHub Actions and Pages are experiencing degraded availability

#234

Post by timwis »

abidlabs wrote: post #224

It's not too hard to switch over from GitHub actions to other runners. For example, I wrote up the steps needed in order to use Hugging Face Jobs instead, which also enables GPU runners and other flavors. I use this for several of the repos I manage (such as Trackio): https://huggingface.co/blog/github-ci-hf-jobs

Is that not still down though because it still relies on GH actions to orchestrate?

Re: GitHub Actions and Pages are experiencing degraded availability

#236

Post by woodruffw »

mgh95 wrote: post #231
Wafje wrote: post #228

Earlier quoted context omitted.

Unprecedented load. From the GitHub COO on April 3rd: Platform activity is surging. There were 1 billion commits in 2025. Now, it's 275 million per week, on pace for 14 billion this year if growth remains linear (spoiler: it won't.) GitHub Actions has grown from 500M minutes/week in 2023 to 1B minutes/week in 2025, and now 2.1B minutes so far this week. So we're pushing incredibly hard on more CPUs, scaling services,…

I find this hard to believe in this context. They should be utilizing load shedding or admission control and killing/rejecting jobs rather than hard failures if it is a scaling issue. It's much more likely an actual software defect than just more load. If this was the case (which they would likely prefer) free/public tiers would be removed first to preserve paying customers services.

Why not both? Higher base load combined with insufficient internal controls for ratelimiting/load-shedding (as in, they don’t know who to shed) would be explanatory.

Re: GitHub Actions and Pages are experiencing degraded availability

#237

Post by [deleted] »

blixt wrote: post #150

It would seem like GitHub is in a precarious situation. We have many agents per employee working in parallel pushing way more commits than was humanly possible before AI, triggering GitHub actions a lot more than the workflows were built for, causing Actions costs to escalate (they really aren't cheap if you compare to hosting it yourself), meanwhile working with YAML workflows is just a pain, and just writing code w…

[deleted]

Re: GitHub Actions and Pages are experiencing degraded availability

#238

Post by axod »

willio58 wrote: post #194
axod wrote: post #171

Earlier quoted context omitted.

https://damrnelson.github.io/github-historical-uptime/ Seems pretty conclusive. Very similar story when they bought skype.

God that's sad. I almost feel bad for all the engineers there, though I'm sure they made good money and probably left

Do they still have any engineers? From the downtime it seems like they don't any more. Yep - the competent ones likely all left.

Re: GitHub Actions and Pages are experiencing degraded availability

#239

Post by slicendice »

Github is a terrible platform. We have had multiple enterprise tickets open with no response for multiple weeks after they fraudulently charged our company for services we cancelled weeks in advance. If you value any kind of real customer support or response time, I would avoid Github like the plague. They will steal your money and there is no one to even talk to about it. Their customer support is non existent (probably because their platform is in shambles).

Re: GitHub Actions and Pages are experiencing degraded availability

#240

Post by mgh95 »

woodruffw wrote: post #236
mgh95 wrote: post #231

Earlier quoted context omitted.

I find this hard to believe in this context. They should be utilizing load shedding or admission control and killing/rejecting jobs rather than hard failures if it is a scaling issue. It's much more likely an actual software defect than just more load. If this was the case (which they would likely prefer) free/public tiers would be removed first to preserve paying customers services.

Why not both? Higher base load combined with insufficient internal controls for ratelimiting/load-shedding (as in, they don’t know who to shed) would be explanatory.

If they can't implement something as simple as "decode upstream headers and determine if 429/503" I don't know what to say. Since this has knocked out all customers it indicates they likely don't have anything of this form implemented.
Post reply on HN