On Wednesday afternoon UTC, GitHub Actions fell over. Again.
The status page logged it at 15:11 UTC on 26 August, with Pages degrading a minute later. The Register reports that GitHub found a problem with a database primary, failed over to a replica, and that the failover didn't fully fix it. Inbound traffic was throttled while they chased upstream Vitess issues. Actions was back to normal around 18:00 UTC.
Three hours. Not catastrophic on its own. The problem is the shape of the year around it.
The pattern, not the incident
GitHub's own status history shows at least 23 reliability issues every single month of 2026: 25 in January, 37 in February, 32 in March, 26 in April, 23 in May and June, 26 in July, and 23 in August with a week still to run, per The Register's count. Actions sat at 98.13% uptime for August. That's roughly 13 hours of degradation in a month, against a service most teams treat as always-on.
Nine days before this, on 17 August, GitHub was down for 7 hours and 47 minutes. CTO Vlad Fedorov's postmortem is worth reading in full, and it's unusually blunt: github.com, authentication, Actions, APIs, pull requests, issues and Copilot all disrupted, and "if you were trying to ship software that day, we let you down."
The cause was capacity, not a bad deploy. Fedorov is explicit that neither the 6 August Actions failure nor the 17 August outage came from a code or configuration change. Traffic hit a new peak, a critical component in the Central US data centre didn't scale with it, and the pressure spread into authentication. During recovery, Copilot errors triggered a client-side retry loop that added load on top of the load.
The growth numbers explain the pressure. Monthly commits went from 1.4 billion in April to 2.9 billion in August. Completed Actions runs climbed to about 115 million a month. GitHub has thrown hardware at it: over 3 million CPU cores, 120 petabytes of high-speed storage, and a migration to Azure that now carries roughly 58% of platform load, up from 12% in May.
They're building fast. They're still behind. Six days after Fedorov promised to earn back trust through reliability, Actions went down again.
What this actually costs an Australian team
Here's the part I care about, because it's the part that lands on my desk.
15:11 UTC is 12:41am in Adelaide. Most of these incidents happen while Australia sleeps, which sounds like good news until you look at what's actually running. Nightly builds. Scheduled data syncs. Overnight integration jobs that feed a morning report. Dependabot and security scans. If your pipeline is your automation platform, GitHub's bad night is your bad morning.
Then there's the other half: it's the middle of GitHub's working day and yours is over, so nobody on your side is watching when the retries start stacking up.
Six things worth doing this week
None of this is exotic. Most of it is a couple of days of work.
1. Separate build from deploy. If a production rollback requires a fresh CI run, GitHub's uptime is your uptime. Build the artefact once, push it to a registry you control (ECR, ACR, S3), and make deployment a promotion of an existing artefact rather than a rebuild. Then an Actions outage delays new work instead of trapping you in a broken release.
2. Write down the break-glass path. One page. How to deploy from a laptop with no CI: which credentials, which commands, who's allowed to run them, what gets logged. Test it once a quarter. The worst time to discover nobody remembers how to deploy manually is at 3am during an incident.
3. Don't assume self-hosted runners save you. They don't. The Actions control plane is GitHub's, and it's the thing that schedules your jobs. When it's degraded, your idle runners sit there waiting for work that never arrives. Self-hosted runners solve cost, capacity and network access. They do not solve availability.
4. Fix your own retry behaviour. GitHub's postmortem names retry storms as something they're now capping with retry limits, retry budgets and variable timeouts. Your workflows are on the other side of that. A job that retries a failing GitHub API call ten times with no backoff makes recovery slower for everyone, including you. Exponential backoff, a cap, and a hard fail.
5. Keep a repo mirror. A scheduled push mirror to Azure DevOps, GitLab or a git bundle in object storage costs almost nothing and means an extended outage doesn't stop you reading your own source code. This one takes an afternoon.
6. Alert on your own signals. Subscribe to the GitHub status webhook, but don't rely on it as your only warning. Status pages lag. A simple check on "has the nightly job posted its success message by 6am" tells you something GitHub's page won't.
And one to check with whoever owns the contract: what does your GitHub plan actually promise, and what's a service credit worth next to a day of lost delivery? Usually not much. That's fine, it just means the resilience has to live on your side.
The uncomfortable bit
Everyone knew vendor lock-in was a risk. Most teams accepted it anyway, because Actions is good, it's right there next to the code, and building your own CI is nobody's idea of a fun quarter. That trade was reasonable when GitHub was boring and reliable.
It's less reasonable now. Not because GitHub is bad, but because the demand curve has clearly outrun the platform, and AI-driven traffic isn't going to slow down to let them catch up. Fedorov says the fix isn't complete. I believe him.
You don't need to leave GitHub. You need to stop treating it as infrastructure that can't fail.
We build and run CI/CD pipelines and cloud infrastructure for Australian businesses, mostly on AWS and Azure. If your delivery pipeline has a single point of failure you haven't looked at properly, get in touch.
Sources
