I Wasn't Ready For This: GitHub Just Broke Actions & Pages
In this article
> **Bottom line:** On August 7, 2026, GitHub confirmed degraded availability for Actions and Pages, leaving workflows stuck queued or silently failing and Pages deploys stalled mid-build.
I had three personal repos and one client project sitting in "in progress" limbo for the better part of an hour.
The real story isn't the outage itself — it's how many teams discovered, in real time, that their entire deployment pipeline has a single point of failure they never priced in.
If you don't have a manual deploy path that doesn't touch Actions, you found out the hard way today, or you're about to.
I was mid-merge on a client's Next.js site when the checks just... stopped updating. Not failed.
Not passed. Stopped. The little yellow dot sat there for twelve minutes before I even thought to check GitHub's status page, and by then two more of my repos had joined the same purgatory.
That's the moment it hit me: I had zero backup plan. None.
After years of treating CI/CD as infrastructure I could trust the way I trust electricity, I was staring at a build queue that wasn't moving and a client Slack message I didn't know how to answer yet.
The Setup: A Normal Thursday Until It Wasn't
Nothing about this morning was unusual.
I pushed a small fix to a Pages-hosted docs site around 10 AM, kicked off a release workflow on a separate repo, and opened a PR on a client's app that was supposed to auto-deploy to staging the second it merged.
Standard Thursday stuff.
Within twenty minutes, all three were behaving strangely in different ways. The docs site's Pages build sat queued with no runner picked up.
The release workflow showed a green checkmark on a job that, when I actually opened the logs, had clearly never finished executing — empty output, no artifact uploaded.
And the staging deploy just never triggered at all, despite the merge going through cleanly.
GitHub's status page eventually caught up and flagged degraded performance across Actions and Pages. No surprise there — these incidents happen, and GitHub isn't unique in that.
What surprised me was watching my own reaction in real time: I didn't have a plan B. I had a pipeline, and the pipeline was the plan.
The Core Insight: You Don't Have a Deploy Strategy, You Have a Dependency
Here's the uncomfortable thing I had to sit with for the rest of that morning. Most of us don't actually have a deployment *strategy*.
We have a deployment *dependency* — one vendor, one queue, one region — and we've been calling it a strategy because it worked every day up until the day it didn't.
The Silent Failure Is Worse Than the Outage
The part that actually rattled me wasn't the queued jobs. Queued jobs are honest — they tell you something's wrong. It was the release workflow that reported success on a job that hadn't run.
That's the failure mode that should scare every team relying on green CI as a merge gate or a deploy trigger: not "it's down," but "it lied and said it wasn't."
If your team auto-merges on green checks, or your deploy pipeline fires off a production release the moment Actions reports success, today was a live demonstration of why that automation needs a human sanity check somewhere in the chain.
I didn't have one. I got lucky that the lying job was on a personal repo and not the client's production branch.
Pages Outages Hit Different Than Actions Outages
Actions being slow is an inconvenience — your merge waits, your release ships an hour late, you grumble. Pages being down is customer-facing.
If your docs site, your marketing page, or your product's public-facing status page is hosted on GitHub Pages, an outage there isn't an internal delay, it's a broken link your users hit directly.
I run two client sites on Pages specifically because it's free, fast, and I never had to think about it.
Today was the first time in three years I had to think about it, and the answer I came up with — "there is no answer, I just wait" — is not a great answer to give a client who's paying you for reliability.
The Timing Problem Nobody Talks About
The thing about CI/CD outages is they don't respect your release calendar. This one landed on a Thursday morning, which for most teams is prime merge-and-ship territory before the Friday freeze.
If this had hit during an actual incident response — say, you're trying to ship a hotfix for something else that's on fire — you'd be fighting two outages at once with the tool you need most completely unavailable.
That's the scenario I keep coming back to. Not "GitHub had a bad morning," but "what happens when I need Actions the one time it isn't there."
The Reality Check: This Isn't a GitHub Problem, It's an Everyone Problem
I want to be fair here, because it's easy to dunk on GitHub in the moment and less easy to admit the same risk sits under AWS CodePipeline, GitLab CI, CircleCI, and literally every hosted CI/CD product on the market.
Centralized build infrastructure means centralized failure. That's not a GitHub-specific flaw, it's the trade-off you accept the second you stop self-hosting your runners.
Where I think the critique is fair: GitHub Actions has become the default nervous system for an enormous share of the open source and commercial software world.
When it degrades, it's not one company's bad day — it's thousands of teams' bad day, simultaneously, with no coordination between them.
That blast radius is bigger than most individual outages because of how much has consolidated onto one platform.
And I'll say the quiet part too — a lot of the "advice" you'll see today about "just add a fallback CI provider" is easy to write and genuinely painful to implement.
Running true multi-provider CI redundancy means duplicating secrets management, duplicating runner configuration, and maintaining two systems that both need care and feeding.
Almost nobody actually does this, including me, including probably you.
The Practical Takeaway: What I'm Actually Changing This Week
I'm not going to pretend I'm about to build a fully redundant multi-cloud CI setup by Friday. That's not realistic for a one-person shop or most small teams.
But there are a few concrete things worth doing that don't require rearchitecting anything:
- **Add a manual deploy script that bypasses Actions entirely.** A single `deploy.sh` that builds locally and pushes to your hosting target directly. You hope you never run it. Today I wished I had one.
- **Stop trusting a green check as proof of execution.** Spot-check logs on anything that gates a production deploy, especially right after you notice a platform is degraded.
- **Decouple your public-facing status/docs pages from your primary CI dependency.** If your own status page lives on the same infrastructure that's currently down, your users can't find out why your product is down either.
- **Bookmark the status page and actually check it first.** I lost twenty minutes assuming it was something I did wrong before I thought to check if it was GitHub.
That's twenty minutes I didn't need to lose.
None of this is glamorous. It's the CI/CD equivalent of knowing where your fire extinguisher is. You don't think about it until the one morning you really, really need to.
Has an Actions or Pages outage ever caught your team mid-deploy, and did you actually have a fallback — or did you improvise like I did?
I'd genuinely like to know what other people's plan B looks like, because mine, as of this morning, didn't exist.
---
