GitHub Reports Degraded Pull Requests, Webhooks and Actions on October 21
GitHub reported degraded performance affecting Pull Requests, Webhook deliveries and GitHub Actions on October 21, 2026, and was still investigating at the time of its most recent update. The company's status page logs the event as incident nms1dpzmh9d9, titled "Delays for Pull Requests and Webhook deliveries." GitHub Status
The first investigating update was posted at 14:52 UTC and cited reports of degraded performance across Actions, Pull Requests and Webhooks. The status page lists Webhooks, Pull Requests and Actions as the affected components. A subsequent update at 15:15 UTC stated that Actions is experiencing degraded performance and that GitHub is continuing to investigate. That update did not name a root cause, and the incident was not marked resolved at the time of writing.
For engineering teams, the three affected components sit at different points in a typical delivery path. Pull Requests are the proposed code changes that colleagues review before merging, so they are where review and merge gating happen. Webhook deliveries are automated messages that tell outside systems something has happened, such as a push, a review or a merge. Delays there can postpone chat notifications, mirror syncs and any tooling that triggers on those events. Actions runs the automated workflows that build, test and, in many organisations, deploy the code. A stall in any one of these can hold up a release, and a stall across all three can make a single failure look like several.
This incident follows at least two earlier disruptions. On October 5, 2026, GitHub's Japanese status page logged an incident titled "Incident with Actions" (ID P0N7ZG5), which reported that GitHub Actions and Hosted Runners, the machines GitHub supplies to execute those workflows, experienced degraded performance due to a partial networking failure. That incident has since been resolved. GitHub Status (JP)
The larger earlier event was the August 17 outage, which lasted 7 hours and 47 minutes and disrupted github.com, authentication, GitHub Actions and APIs. GitHub described the event and the follow-up work in a company blog post. GitHub Blog
In my view, the useful question for platform and SRE leads is less about any single status-page entry than about how their own pipelines behave when an upstream event feed or runner pool degrades. Can webhook consumers handle the same event twice, a property engineers call idempotency, so that late or replayed messages do not trigger duplicate deployments? Can a deployment be paused without losing the state of a queued release? Does anyone on call receive status-feed notifications, or do teams learn of an upstream problem only when a build fails? None of these questions is new, but a run of incidents in the same product area tends to make them concrete.
The broader context is that a public, component-level status page gives downstream teams a shared, timestamped record of what the provider has acknowledged. The 14:52 and 15:15 UTC entries on incident nms1dpzmh9d9 let an operations team match its own failed jobs and delayed hooks against a stated provider-side problem, rather than debugging its own infrastructure in isolation. That is a modest capability, but for teams that depend on a hosted forge for every commit, it can shorten the time spent chasing the wrong diagnosis.
