Thirteen incidents in seventeen days is not a bad week, it is a pattern, and patterns are what capacity planning is supposed to catch before customers do.
Two outages did most of the damage
On August 6, GitHub Actions entered a degraded state at 15:05 UTC that did not fully resolve until 02:04 UTC the next day, a ten-hour-forty-two-minute incident triggered by a routine deployment to an internal service that processes events and generates Actions jobs. At its peak, 71 percent of workflow runs experienced infrastructure failures outright, and 75 percent of the runs that did start were delayed by more than five minutes. Eleven days later, on August 17, a separate incident ran from 13:28 to 21:15 UTC, nearly eight hours of elevated errors and latency spanning Issues, Pull Requests, the API, Actions and Copilot simultaneously. GitHub’s own numbers put that single afternoon’s downtime at close to a full year’s worth of Actions’ allowable budget under a three-nines target.
The root cause is not exotic, it’s familiar
GitHub’s own incident reviews point to two recurring themes across the month: capacity headroom that was not sized for the load actually hitting the service, and change management that let routine configuration changes and deployments push past limits nobody was watching closely enough to catch before customers noticed. Neither is a novel failure mode. Both are the same categories that show up in most large-scale CI/CD outages, which is part of why the pattern is worth taking seriously rather than dismissing as bad luck: it is the kind of failure that recurs until the underlying capacity and rollout process actually changes.
Ninety-nine point three three is not what most teams think they’re getting
Actions now sits at 99.33 percent uptime over a rolling 90 days, translating to roughly fourteen and a half hours of downtime in that window, a full order of magnitude worse than the 99.99 percent GitHub maintains for Git operations and webhooks. Most teams treat GitHub Actions as an assumed constant when they design their deployment pipeline, the same way they treat the ability to git push. That assumption held reasonably well in prior years. The August 2026 numbers say it currently does not, and a CI/CD pipeline with no fallback path turns every one of these incidents into a full stop on releases, incident response deploys included, at exactly the moment a team is least able to absorb the delay.
What a resilient pipeline looks like instead
The fix is not migrating off GitHub, for most teams that is disproportionate to the problem. It is building the pipeline so that an Actions outage degrades gracefully rather than blocking everything: a documented manual deployment path that does not depend on Actions, self-hosted runners for the release gates that cannot wait out a multi-hour incident, and alerting that distinguishes “GitHub is down” from “our own change broke the build” so on-call engineers are not debugging the wrong problem during an outage.
If your release process has no path to production when GitHub Actions is degraded, that is a gap worth closing before the next multi-hour incident, not after it costs you a release window. Contact Excello Digital for help building CI/CD pipelines that keep shipping when your platform provider has a bad day.