GitHub Actions hit in 17 of GitHub's 34 incidents since October
GitHub posted 8 incidents from November 3 to 5. Its October write-ups trace Actions failures to links between its data center and a cloud region.
The short read
GitHub Actions is in 17 of GitHub's 34 status-page incidents since October 1, against 1 of 14 in September.
- GitHub posted 8 incidents from November 3 to 5, five of them touching Actions. None has a root cause yet.
What you can do with this
Set timeout-minutes on every Actions job, since the default is 6 hours, and keep a dated log of each outage. On a plan with GitHub's SLA, credit claims close 30 days after the quarter ends.
GitHub’s status page recorded 8 incidents from November 3 to 5, and 5 of them hit GitHub Actions. Counted through GitHub’s public status API, Actions appears in 17 of the 34 incidents since October 1, against 1 of 14 in September. If your tests or deploys run on Actions, it has been less dependable this autumn.
GitHub’s own write-ups point to why, and they come later in this piece. The count has a limit worth stating: a status page shows what a company chooses to declare, and the service tags on each incident are GitHub’s. It measures how often GitHub said something was wrong, not how long your jobs waited.
Three days, eight incidents
The largest one began at 09:49 UTC on November 4. Pull requests, Git operations, issues, the API and Actions were degraded for about two hours. RuntimeWire reported the incident and GitHub’s 11:30 UTC mitigation that morning. Two more incidents the same afternoon came from “an issue with events that might trigger Actions,” and GitHub warned that customers might see delayed status updates for their jobs.
On November 5 some workflow runs had “delays or errors when starting”. That night, from 23:36 UTC, four services including Actions slowed again for about 45 minutes. Across the three days the incidents ran about 520 minutes combined, by our sum of their open-to-resolved times. Each of the eight still ends with the same line: a root cause analysis “will be shared as soon as it is available.”
The move to Azure is the likely backdrop
GitHub is moving its production systems into an Azure region. Its September availability report says that as of October 7, 120 of 160 production services ran in Central US and 13 of 51 primary MySQL databases had moved. GitHub missed its September 30 goal to deploy every service there, and it aimed to unlock all available capacity by the end of October.
Two October write-ups describe a similar failure in Actions. On October 19, an Actions service lost connections to cache servers in one cloud region and retried from every server at once. The surge overloaded a shared link between GitHub’s data center and that region, and 5.13% of jobs on GitHub-hosted runners started late. On October 30, maintenance on a gateway between an Actions service and Redis clusters in the Central US Azure region set off a connection storm, with about 90% of connection attempts failing.
A third incident, on October 27, came from moving 7 database tables to Azure Central US. We cannot say the November incidents share these causes, because GitHub has not explained them. In our view, a service split between an old data center and a new region has more links that can fail. That fits a run of incidents in the middle of the move.
What to do now
- Cap your jobs. A job’s
timeout-minutesdefaults to 360, so a stuck job can hold a runner for 6 hours. Set a limit near your normal run time. - Subscribe to the status page. It sends alerts by email, text message, Slack, webhook or RSS, so you know whether a failure is yours or GitHub’s before you debug it.
- Keep a manual deploy path. If a release depends on one Actions workflow, write down how to ship without it. That is our advice, and the trade-off is a second process to maintain.
- Log outages for a credit claim. GitHub’s SLA promises 99.9% uptime per calendar quarter and lists Actions among the services it covers. It counts an Actions run as down when its log shows no output five minutes after the trigger fired. Claims close 30 days after the quarter ends, so January 30 for this quarter. Our SLA comparison shows what a credit is worth.
GitHub’s report for October should give root causes for some of these incidents. Until it does, set the timeouts and keep the log.
Sources
- GitHub status page and incident history, with incident counts from its public API (
/api/v2/incidents.json), read November 6, 2026 - GitHub status: Incident with Pull Requests, Git Operations and Issues (November 4, 2026)
- GitHub status: Incident with Actions and Pages (November 4, 2026)
- GitHub status: Incident with Actions (November 5, 2026)
- GitHub status: Degraded performance for multiple GitHub services (November 5 to 6, 2026)
- GitHub status: Degraded availability for GitHub Actions, GitHub Pages and Webhooks (October 19, 2026)
- GitHub status: Elevated 404s for GitHub App tokens (October 27, 2026)
- GitHub status: Incident with Actions, Pages, and Webhooks (October 30, 2026)
- GitHub availability report: September 2026 (October 14, 2026)
- RuntimeWire: GitHub mitigates errors affecting pull requests, Git operations and issues (November 4, 2026)
- GitHub Docs: Workflow syntax for GitHub Actions
- GitHub Online Services SLA