GitHub pull request, Actions and webhook delays traced to event streaming hotspots

What happened

GitHub suffered a multi-service performance incident on October 21, 2026 that left pull request updates, the Actions continuous integration service and webhook deliveries running late for more than two hours. According to GitHub's status page, the company opened an investigation at 14:52 UTC after users reported degraded performance across all three services. By late afternoon UTC the incident was resolved for the main user-facing services, though one downstream system — the audit log — was still draining a backlog.

A bottleneck in the event pipeline

The culprit, per GitHub's updates, was not any single product but the plumbing underneath them. At 15:36 UTC the company said added load on its event streaming platform had created hotspots, and that it was diverting traffic away from the worst-affected areas and bringing extra processing capacity online.

That explanation matters because pull request activity, Actions workflow status changes and webhook deliveries all ride on the same event infrastructure. A bottleneck in one shared layer surfaced simultaneously as delays across several products that, from a user's perspective, look unrelated.

How the incident unfolded

Actions was explicitly flagged as degraded at 15:15 UTC, followed 21 minutes later by the root-cause note about the streaming platform. By 15:58 UTC GitHub said the platform was showing signs of recovery, though customers were still feeling the effects.

At 16:17 UTC and again at 16:25 UTC, GitHub reported that pull request updates and webhook deliveries were recovering as event processing came back, while two things lagged: audit log events, delayed by up to 100 minutes, and Actions workflow status updates. Pull requests were declared fully operational at 16:33 UTC.

A minute later, GitHub's update painted a mixed picture: audit log delays had grown to roughly 110 minutes even as the other services healed, and webhook deliveries were still working through backlogs. Actions and webhooks were marked normal at 16:57 UTC, and at 16:59 UTC the company said audit log events remained about 100 minutes behind while it processed the queue.

The recovery tail

The final update, posted at 17:09 UTC, confirmed that pull request updates, Actions and webhook deliveries had all recovered. Audit log events were still catching up, and GitHub estimated the remaining backlog would take approximately two to three more hours to clear.

Counting from the first investigation notice, the user-facing disruption lasted a little over two hours. For anyone relying on the audit log — typically security and compliance teams — the effective delay stretched well past that window.

Why it matters

GitHub functions as shared infrastructure for a large share of the software industry, so even modest delays propagate quickly. Slow pull request updates stall review and merge cycles; delayed Actions status updates leave teams unsure whether a build actually passed; and late webhook deliveries quietly hold up every downstream automation keyed to repository events, from deploy triggers to issue trackers to chat notifications.

The incident is also a useful illustration of how event-driven architectures couple products together. A single streaming platform developing hotspots was enough to degrade at least four systems at once, which is worth remembering when designing similar pipelines — and when reading status pages, since "recovered" services can still be flushing backlogs. Consumers of GitHub webhooks may want to make sure their handlers tolerate late, out-of-order or duplicate deliveries after incidents like this one.

Finally, the audit log lag deserves attention of its own. Organizations that alert on audit events for security monitoring effectively had a blind window approaching two hours, and anyone reconstructing a timeline afterwards should remember that logged timestamps can reflect processing delays rather than when actions actually occurred.