GitHub Resolved Two Oct. 7 Degradations Hitting Git, Pull Requests, Issues and Actions

GitHub closed out Oct. 7 with two resolved degradations that hit the core surfaces teams use to ship code: Git Operations, Pull Requests, Issues, Actions and Webhooks. Both were brief, both recovered the same day, and GitHub explicitly linked them as a recurrence.

For operators running agentic CI/CD, fix-loops, and overnight pipelines on GitHub, the distinction matters: this was not an announcement of a new feature or a scheduled change. These were availability incidents — degraded performance and availability that started, was mitigated, and was then marked resolved — with a detailed root cause analysis still pending at publication time.

What GitHub confirmed

The second and most recent incident is documented on the GitHub Status page for Git Operations, Issues, Actions and Pull Requests. GitHub first reported investigating degraded performance for Actions, Git Operations, Issues and Pull Requests at 17:17 UTC on Oct. 7, then said widespread impact had occurred from 16:52 UTC to 17:01 UTC.

That same update called the event a reoccurrence of the earlier same-day incident documented on the GitHub Status page for Git Operations, Pull Requests and Actions. GitHub said all systems had recovered at that point, that durable mitigation was in progress, and that another update would follow in 30 minutes.

The timeline then moved quickly:

• 17:27 UTC: degradation mitigated, monitoring for stability
• 18:00 UTC: all systems recovered, mitigations applied, no recurrence anticipated
• 18:04 UTC: incident marked resolved, with root cause analysis to be shared when available

That resolution note is important to read literally. Resolved means GitHub is no longer reporting active degradation for that incident. It does not mean the root cause has been published. GitHub said a detailed root cause analysis will be shared as soon as it is available.

The earlier Oct. 7 incident

The first Oct. 7 incident, tracked on the earlier GitHub Status incident page, had a similar shape but a longer investigation trail. GitHub began investigating degraded availability for Actions, Git Operations and Pull Requests at 15:14 UTC, then reported widespread impact across GitHub services between 15:06 UTC and 15:16 UTC.

Through the afternoon UTC, GitHub posted component-level updates showing partial recovery and intermittent pressure:

• Issues, Webhooks, Git Operations and Pull Requests each cycled through degraded performance or availability notices
• Pull Requests mitigation was noted at 15:31 UTC, with Actions reported operating normally at 15:32 UTC
• Partial recovery was observed at 15:41 UTC, followed by further mitigation notices through 15:56 UTC
• Full recovery across Git Operations, Pull Requests and Actions was reported at 15:58 UTC
• At 16:23 UTC GitHub said services were fully recovered and stable, with root cause identified and mitigations being applied to prevent reoccurrence
• At 16:25 UTC the incident was marked resolved, again with root cause analysis pending

Affected components for that first Oct. 7 incident were listed as Git Operations, Webhooks, Issues, Pull Requests, and Actions. The second Oct. 7 incident lists Git Operations, Issues, Pull Requests, and Actions. Webhooks was not listed as affected in the later incident header, though the earlier incident shows how closely Webhooks, Issues and Pull Requests moved together during the disruption window.

How this fits the last three days

The Oct. 7 pair follows a separate Oct. 6 degradation documented on the GitHub Status page for Several services are degraded. That Oct. 6 incident investigated degraded Pull Requests and Webhooks performance starting at 19:57 UTC on Oct. 6, reported brief degradation across issues, pull requests and webhooks, paused enterprise migrations while causes and mitigations were validated, and was marked resolved at 23:40 UTC on Oct. 6.

The three incidents are distinct status entries with distinct IDs and resolution times. The explicit recurrence link, however, is only between the two Oct. 7 incidents: the 17:25 UTC update in the later incident directly references the earlier same-day incident. Operators should not conflate the Oct. 6 enterprise-migration pause with the Oct. 7 Git Operations and Actions degradations, but the clustering across Oct. 6–7 is relevant context for retry policy and on-call staffing.

That clustering also follows the distinct Oct. 5 Actions and hosted-runners degradation covered in GitHub Actions Degraded for Four Hours: 47% of Workflow Runs Failed at Peak. That earlier event is not one of the incidents resolved on Oct. 7, and is cited here only to help teams set failure signatures across a noisy week.

Why it matters for AI fleets

Signal	What to record
Impact windows	15:06–15:16 UTC and 16:52–17:01 UTC on Oct. 7
Surfaces	Git Operations, Pull Requests, Issues, Actions; Webhooks in the first Oct. 7 incident
Status	Both Oct. 7 incidents resolved; mitigations applied; RCA pending
Recurrence	Second Oct. 7 incident explicitly flagged as reoccurrence of the first

Short, platform-wide degradations are disproportionately disruptive to agentic workflows. A nine- to ten-minute window of failed clones, fetches, pushes, PR polling, issue updates, webhook deliveries, or queued workflow runs can cascade into hours of agent retries if loops treat a platform incident as a code failure.

Fleet operators should tag Oct. 7 failures in that window as provider-side degradation, not model or patch failure. Cap rapid retries for git and API calls, require backoff with jitter before re-queueing Actions, and separate webhook-missed events from webhook-invalid events before replaying. For overnight pipelines, preserve the run transcript and the GitHub Status timestamps so reconciliation does not re-apply a fix that already merged during partial recovery.

What is still unknown

GitHub has not yet published root cause analyses for either Oct. 7 incident. The first incident said at 16:23 UTC that root cause had been identified and mitigations were being applied, but the final 16:25 UTC resolution still deferred the detailed analysis. The second incident said at 18:00 UTC that mitigations had been applied with no recurrence anticipated, but likewise deferred the detailed analysis at 18:04 UTC.

Until those analyses appear, teams should treat mitigation as operational but not yet explained. Do not assume a single underlying change, do not assume Webhooks behavior from the first incident applies to the second, and do not close out internal incident reviews that depend on GitHub’s cause statement.

For now, the publishable facts are the scope, timing, recovery, and pending RCA — all drawn from GitHub Status as the primary source. If you ran CI or agents between 15:00 UTC and 18:05 UTC on Oct. 7, reconcile those runs against the two impact windows before attributing failures to your own stack.