DEV TOOLS Signal 51
GitHub Actions outage hits days after CTO's reliability promise, August uptime at 98.13 percent
↗
A database primary failure triggered another GitHub Actions disruption on August 26, just six days after CTO Vladimir Fedorov pledged platform reliability improvements following a near-eight-hour outage on August 17.
Actions uptime for August sits at 98.13 percent, and GitHub has logged at least 23 incidents every month this year. Teams relying on GitHub for CI/CD are absorbing repeated pipeline stalls with no clear resolution timeline, despite GitHub attributing much of the strain to AI-driven usage growth.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
Wednesday's outage began at 1511 UTC from a database primary issue; a replica failover did not fully mitigate degradation, and GitHub throttled inbound traffic while investigating upstream Vitess problems before restoring service by 1800 UTC.
GitHub's status history shows monthly incident counts ranging from 23 to 37 across January through August, with February being the worst at 37 and August already at 23 with days remaining.
CTO Vladimir Fedorov's August 17 postmortem promised to earn user trust through scaling and reliability, but GitHub has not responded to questions about the latest disruption.
THE READ
What the cluster adds up to.
The outage followed a now-familiar pattern: a database primary failed, GitHub failed over to a replica, and the failover did not fully resolve the problem. Engineers then throttled inbound traffic while investigating upstream Vitess issues before gradually restoring normal operation between 1511 and 1800 UTC. The incident is the 23rd logged on GitHub's status page for August, with the month not yet over.
This disruption landed six days after CTO Vladimir Fedorov published a postmortem of the August 17 outage, a near-eight-hour event that affected Issues, Pull Requests, APIs, Actions, and Copilot. In that postmortem, Fedorov promised to earn trust through scaling and reliability. The timing undermines that pledge, and GitHub did not respond to questions from The Register about the new incident.
GitHub's uptime page shows Actions at 98.13 percent for August, close to slipping into 97 percent territory. The monthly incident counts across the year, 25 in January, 37 in February, 32 in March, 26 in April, 23 each in May and June, 26 in July, and 23 so far in August, indicate a sustained reliability problem rather than an isolated rough patch.
GitHub has attributed much of the strain to AI, blaming bots and agents for skyrocketing usage that its infrastructure has not kept pace with. The company claims it is handling 2.9 billion commits, 24 million new repos, and 130 million merged pull requests per month. Whether that explanation holds for teams whose pipelines stall on a database failover is a separate question from aggregate load.
For engineering teams using Actions as their primary CI/CD platform, the practical consequence is repeated, unpredictable pipeline interruptions with no demonstrated improvement trajectory. The database-failover-and-throttle mitigation path suggests GitHub's recovery mechanisms themselves are not reliably absorbing the load, and the company's silence on the latest event offers little signal that the scaling Fedorov promised is close.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER