If it feels like GitHub has been down constantly this month, you are not imagining it. GitHub incidents have landed at a rate of one per day: the status page logged exactly 20 separate incidents in the 20 days between August 8 and August 27, 2026, and that count does not even include the nine hour Actions outage on August 6. As of this writing, two are still open: an incident with Copilot AI model providers and a disruption with GitHub billing. This post walks through the full timeline, digs into what GitHub's own postmortems reveal about the underlying causes, and lays out what your on-call team should do when the platform your entire delivery pipeline runs on hits a rough patch this sustained.

To be clear about sourcing: the count comes straight from GitHub's public status page incident history, not from third party down detectors, which tend to inflate numbers with user reported noise. Twenty provider acknowledged incidents in twenty days is the conservative reading.

The full timeline: 20 GitHub incidents in 20 days

Here is every incident GitHub published between August 8 and August 27, in order.

August 10 to 13: the first wave

The middle of the month brought eight incidents in four days, spread across almost every product surface: a disruption with Copilot access to some models and a disruption with creation of fine grained personal access tokens on August 10, an incident with GraphQL API requests on August 11, an incident with pull requests and issues plus a disruption with login and release asset downloads on August 12, and then three on August 13: an incident with webhooks, errors with the Fable 5 model in Copilot, and a disruption with GHEC team sync.

Individually these were mostly short and narrow. Collectively they touched authentication, the API layer, code review, webhooks, enterprise identity, and AI features in a single four day window. If your team felt like something on GitHub was always slightly off that week, this is why.

August 17: the big one

On August 17 GitHub suffered a broad platform outage touching Git operations, webhooks, API requests, issues, pull requests, Actions, Pages, and Copilot. End to end it ran roughly eight hours. This was the incident that made mainstream news, and it is the one with the most instructive postmortem, which we will get to below.

August 18 to 24: the aftershocks

The week after the big outage produced a steady drip: an incident with Actions and intermittent failures in runner group and runner permissions pages on August 18, intermittent failures creating agent tasks on August 20, degraded Git operations over SSH on August 21, and on August 24 both delays in starting Actions runs and elevated errors on the Fable 5 model due to an upstream provider.

August 26 and 27: four incidents in one day, then more

August 26 alone logged four incidents: an incident with Actions and pull requests, a disruption with GitHub billing, another incident with Actions affecting Pages, and a disruption with some GitHub services. August 27 opened with an incident with Copilot AI model providers. The billing and Copilot incidents were still open when we published this.

Two patterns jump out of the list. Actions appears in at least six of the twenty incidents, more than any other subsystem. And AI related entries (Copilot model access, Fable 5 errors twice, agent task failures, Copilot model providers) account for five, all tied at least partly to upstream model providers that GitHub does not fully control.

What GitHub's postmortems actually say

GitHub has published real detail on the two largest events, the August 6 Actions outage and the August 17 platform outage. The mechanics matter because they explain why the smaller incidents keep coming.

August 6: a routine deploy exposed a capacity weakness

In its availability report, GitHub attributes the August 6 Actions outage to a routine deployment to an internal service that processes events and generates Actions jobs. The deploy exposed an existing capacity and concurrency weakness: as pods were replaced during the rollout, the remaining capacity saturated, services crashed, and the failure cascaded across clusters and downstream services. At peak, 71 percent of workflow runs hit infrastructure failures and 75 percent of the remainder were delayed by more than five minutes. The impact window ran from 15:05 UTC to 00:14 UTC the next day, roughly nine hours. GitHub's own words: the incident was unacceptable in both its impact and its duration.

This is the classic shape of a capacity debt failure. Nothing about the deploy was wrong. The system was running close enough to its limits that the temporary capacity dip of a normal rollout tipped it over. That distinction matters for the rest of the month: capacity debt does not disappear when the incident resolves. It gets paid down over weeks, and until it is, the system operates without its normal safety margin.

August 17: a regional capacity failure plus a retry storm

The August 17 outage started as a capacity failure in the Central US region that cascaded through authentication, Actions, APIs, pull requests, issues, and Copilot. Then it got worse: client retry logic turned Copilot's recovery into a traffic spike roughly ten times normal, which extended the outage. Recovery from the failure became its own load event. We covered the retry storm mechanics in detail in our earlier postmortem breakdown, so we will not repeat the full analysis here.

The relevant point for this post is the shape: a regional capacity problem, a cascade through shared dependencies, and an amplification loop driven by clients. Every one of those three ingredients is still present after the incident closes. The region still needs headroom rebuilt, the shared dependencies are still shared, and the clients still retry.

Why incident clusters follow big outages

Twenty incidents in twenty days is rarely twenty independent failures. After a major capacity event, a system runs degraded in ways that do not show up on a status page: backlogs are draining, caches are cold, emergency mitigations are still in place, autoscaling is tuned conservatively, and engineers are shipping fixes under pressure with less review headroom than usual. Every one of those conditions raises the probability of the next incident. The Actions heavy pattern in the timeline is consistent with a subsystem that took a major hit on August 6, a second one on August 17, and has been operating without its normal margin since.

The AI related incidents point at a second, independent stress. Copilot's model serving depends on upstream providers, and the status page entries repeatedly name upstream causes. A platform adding large AI surface area inherits the reliability of every provider behind it, and August suggests that inheritance is expensive right now.

None of this means GitHub is falling apart. It means a very large system is working through capacity debt in public, which every operator of a large system eventually does. The right way to judge GitHub is on the follow through in its next availability reports. But the right way to run your own team, in the meantime, is to assume the tail of this cluster is not over.

The real cost: what a GitHub incident does to your team

The direct impact of a GitHub incident is obvious: builds fail, merges stall, deploys stop. The indirect costs are where most teams bleed time, and they are worth naming because they are the fixable part.

First, there is the misdiagnosis tax. When CI goes red, the on-call engineer's first hypothesis is a bad commit, not a platform outage. Teams routinely spend twenty to forty minutes investigating their own code before someone checks a status page. Multiply that by twenty incidents in twenty days and the wasted hours get large fast. Worse, the intermittent incidents in this cluster, like the runner permission failures on August 18 or the SSH degradation on August 21, are the most expensive to diagnose, because a check that passes on retry looks exactly like flaky tests. Engineers burn time hunting phantom bugs in their own suites while the real cause sits on a status page nobody thought to open.

Second, there is the duplicated discovery problem. Without a defined process for third party incidents, five engineers in five Slack threads independently discover that GitHub is down, each partially informed, none owning communication. The outage is GitHub's, but the chaos is yours.

Third, there is the half finished work hazard. Incidents that degrade pull requests and webhooks, like August 12, 17, and 26, leave landmines: merges that half completed, webhook deliveries that silently never arrived, CI statuses that never reported. The cleanup often outlasts the outage, and it only happens reliably if someone was assigned to look for it.

How to protect your on-call team from a dependency's bad month

You cannot fix GitHub. You can stop each of these incidents from becoming your incident. The playbook below is short, and most of it can be set up in an afternoon.

Detect it yourself instead of discovering it

Your CI failing is not an alert that GitHub is down; it is an alert that something is wrong, addressed to the wrong hypothesis. A cheap synthetic check against the GitHub API, or GitHub's status feed piped directly into your alerting, turns "why are all our builds red" from a thirty minute investigation into a thirty second confirmation. The alert should say what it means: GitHub is degraded, this is external, here is the incident channel.

Write down the answer to "can we ship without Actions?"

Actions appeared in six incidents this month. If your deploy path runs through it, you need a documented manual alternative, even a slow and ugly one, and it needs to have been exercised at least once outside an emergency. A fallback that has never been run is a hypothesis, not a plan. The middle of a GitHub outage is the worst possible moment to learn that your break glass deploy script needs a credential nobody has.

Decide your merge freeze policy in advance

When pull requests or webhooks degrade, continuing to merge creates exactly the half finished state described above. A simple pre agreed rule ("status page red on pull requests means we pause merges and queue them") costs nothing to write down and saves real cleanup. The decision is easy; making it in advance is the entire value.

Treat vendor incidents as real incidents

Open an incident channel, assign an owner, post updates on a cadence, and close it with a short review. The review question for a third party incident is not "what was the root cause," which is GitHub's job, but "how long did it take us to correctly identify this as external, and what did it cost us." Track that number across the month and you will know exactly how much this cluster cost your team.

Audit your own retry behavior

GitHub's August 17 recovery was prolonged by clients retrying at roughly ten times normal traffic. Some of those clients are you. Anything in your stack that talks to the GitHub API should use exponential backoff with jitter and a circuit breaker. This is basic hygiene, and it is also good citizenship: retry storms are a collective action problem that every well behaved client makes smaller.

A quick readiness checklist

Independent detection: a synthetic check or status feed alert that identifies GitHub incidents without human investigation.
A named response pattern: one channel, one owner, a communication cadence, applied to vendor incidents just like internal ones.
A tested manual deploy path: exercised at least once, with credentials and steps documented.
A written merge freeze rule: the specific status page conditions that pause merges, agreed before the next incident.
Backoff and circuit breakers: on every service that calls the GitHub API.
A post incident sweep: a checklist for finding half merged PRs, missed webhooks, and stale CI statuses after each event.

Where coordination speed comes from

Look back at the costs in the section above: misdiagnosis time, duplicated discovery, unowned communication. None of them are technical problems. They are coordination problems, and coordination speed is a function of how many steps sit between an alert firing and the right people being in one conversation with context.

That is the reason Pagerly lives inside Slack rather than beside it. When the GitHub status alert fires, it lands in the channel where your team already works, the on-call engineer is already identified, and pulling in the release owner is a message rather than a page through a separate tool. The incident timeline builds itself from the conversation, which is what makes the "how long did it take us to know it was external" review question answerable with data instead of memory. Third party incidents are where this matters most, precisely because they are the incidents your runbooks forget: nobody writes a runbook for a dependency they assume is always up.

Twenty incidents in twenty days is a strong argument for dropping that assumption.

The takeaway

GitHub's August is what capacity debt looks like from the outside: two major events with candid postmortems, followed by a long tail of smaller failures concentrated in the same subsystems while headroom gets rebuilt, plus a newer class of AI provider incidents layered on top. The honest expectation is that the tail continues for a while yet.

You do not control any of that. What you control is whether the next entry on GitHub's status page costs your team three minutes or three hours. That difference comes down to preparation that fits in an afternoon: independent detection, a tested fallback for deploys, a pre agreed merge freeze rule, disciplined retries, and a response pattern that puts one owner and one channel on every vendor incident. Do that work this week, because if the pattern of the last twenty days holds, you will get a chance to use it soon.