GitHub's Nov. 9 Actions and Webhooks Degradation Slowed Agent Run Starts and Triggers After Two Timeout Incidents

GitHub spent Nov. 8 and Nov. 9 fighting three separate degradations, and the one that closed the sequence hit exactly the two surfaces agent fleets lean on: workflow run starts and webhook delivery. The GitHub Status incident page for Webhooks and Actions lists both components as affected, opens the investigation at 10:00 UTC on Nov. 9, and reaches a monitoring state at 11:45 UTC. If your fix loops, scheduled CI or issue-triggered agents ran anything between 10:00 and 11:45 UTC, correlate your delivery records and run-start timestamps against that window before attributing failures to your own stack.

The Nov. 9 timeline, read literally

The updates on the incident page trace a fast-moving morning:

Time (UTC, Nov 9)	GitHub’s update
10:00	Investigating reports of degraded performance for Actions and Webhooks
10:28	Investigating delays in Actions runs start times and webhook deliveries
10:47	Mitigation applied, monitoring for recovery
11:06	The degradation affecting Actions has been mitigated
11:17	Webhooks is experiencing degraded availability
11:42	Webhooks is experiencing degraded performance
11:45	The degradation affecting Webhooks has been mitigated; monitoring

Two details in that sequence matter more than the timestamps. First, the 10:28 update is GitHub explicitly naming run start delays — GitHub confirmed delays in when runs started, not failed or lost runs. An agent loop that fires a workflow dispatch and polls for a run that takes longer than usual to start looks identical to a broken trigger. Second, Actions was declared mitigated at 11:06 while Webhooks kept degrading for another 39 minutes, cycling from availability to performance trouble before its own mitigation at 11:45. Treat the two components as separate recovery tracks when you reconcile logs, and treat 10:00 as the moment GitHub opened its investigation, not as a verified impact start.

Two resolved incidents preceded it

The Nov. 9 incident did not arrive on a clean platform. Earlier the same day, GitHub tracked “Increased timeouts due to surge in anonymous users” on a separate status page, from 05:59 UTC until it was resolved at 09:09 UTC. GitHub said some users who were not logged in could see errors, that “CI jobs and release downloads may fail with a 504 Gateway Timeout status if they make anonymous calls,” and — repeatedly — that “Logged-in users and authenticated requests have not been affected.” That incident resolved with a promise that a detailed root cause analysis will be shared as soon as it is available.

The day before, on Nov. 8, a third incident hit API Requests between 10:36 and 12:32 UTC, with GitHub describing degraded performance “primarily for unauthenticated users” — primarily, not exclusively. GitHub said it had identified a problematic component and was redeploying it, then mitigated and resolved the incident with the same pending-RCA language.

The pattern across the three is partial, not clean: the first two incidents concentrated damage on anonymous and unauthenticated traffic, while the Nov. 9 incident struck Actions run starts and Webhooks, and GitHub has published no cause for any of them in the evidence available at publication time.

What can plausibly break in an agent fleet

Webhooks are how near-real-time agent triggers arrive — a push, a pull request event, an issue comment that wakes a coding agent or a triage bot. GitHub confirmed degraded Webhooks availability and performance in this window; that means deliveries may have arrived late, and depending on your endpoint’s timeout and retry behavior, some triggers may not have produced an agent run at all. Whether you see an error depends on your client: a delivery that lands late can look like silence. Likewise, GitHub confirmed delayed Actions run starts, so dispatches and pushes may have sat waiting to start, and an agent that polls briefly for a run ID or a check conclusion can time out and give up during the gap.

Practical reconciliation for anyone who ran agents between 10:00 and 11:45 UTC on Nov. 9:

• Correlate before classifying. Compare failed runs against webhook delivery records and run-start timestamps in the window before attributing them to provider degradation, your own code, or your triggers. The failure mode behind the loop guards in CI Failure to Fix: The AI Agent CI Loop That Doesn’t Thrash starts with misattributing a late platform to a code failure.
• Replay webhooks by event, not by absence. Separate deliveries your endpoint can prove it received from ones it cannot, and re-drive the trigger explicitly rather than assuming the event landed. This is the same missed-vs-invalid distinction that mattered in the Oct. 7 incident covered in GitHub Resolved Two Oct. 7 Degradations Hitting Git, Pull Requests, Issues and Actions.
• Check for accidental re-dispatches. After the mitigation updates, any dispatches an agent retried during the window may now run alongside their originals. Look for overlapping or duplicated workflow runs and duplicate agent PRs before merging anything from that hour.
• Mind which calls are anonymous. The Nov. 9 timeout incident explicitly reported logged-in users and authenticated requests as unaffected; the Nov. 8 incident affected unauthenticated users primarily. Anonymous scheduled jobs and release downloads were the exposed path named in the Nov. 9 incident’s 06:30 UTC update.

Why three in 30 hours is the story

Any one of these would be a routine blip. The pattern is what deserves attention: two anonymous-traffic timeout incidents — Nov. 8 from 10:36 to 12:32 UTC and Nov. 9 from 05:59 to 09:09 UTC — followed the same morning by an incident in the automation surfaces agents depend on, none with a published cause. That echoes the clustering GitHub showed across Oct. 5–7, including an Actions degradation covered earlier, before two same-day Git and Pull Requests incidents. Recurrence without a published root cause is the condition under which retry budgets, backoff with jitter, and timestamp-based failure attribution stop being nice-to-haves.

The two resolved timeout pages each promise a detailed root cause analysis; the Actions and Webhooks page remains in monitoring and promises none. Until causes are published, treat mitigation as operational but unexplained, and reconcile any agent work from Nov. 8 10:36–12:32 UTC and Nov. 9 05:59–11:45 UTC against the windows above before attributing failures to your own stack.