Technology

GitHub Tracking Active Incident: Pull Request and Webhook Degradation Continues

Martin HollowayPublished 2d ago5 min readBased on 3 sources
Reading level
GitHub Tracking Active Incident: Pull Request and Webhook Degradation Continues
source:githubstatus.com

GitHub's status page is currently tracking an active incident affecting GitHub.com, with a live incident page at GitHub Status as of August 17, 2026. The page offers email and SMS subscription updates for ongoing alerts. GitHub's official status account has reported degraded performance for Pull Requests, alongside a separate incident involving Webhooks X / GitHub Status.

This follows a detailed disclosure in GitHub's July 2026 availability report, published August 12, 2026. That report documented that 113,930 pull request creation attempts were impacted across 50,904 users during the July reporting period GitHub Blog. The average error rate for pull request creation was 1.75%, with a maximum error rate also noted.

Pull requests are the main way teams on GitHub coordinate changes to shared code. A developer proposes a set of edits, and teammates review them before the edits are merged in. When pull request creation fails, that whole coordination process stalls. Over fifty thousand users experiencing failed or degraded pull request creation attempts is a meaningful number. An average error rate of 1.75% is low in absolute terms, but applied to a base of over 113,000 attempts, it translates to a significant volume of failed operations. The presence of a maximum error rate alongside the average means some users or time windows experienced substantially higher failure rates than the average suggests.

The August 17 incident page does not yet provide granular metrics matching the July report's level of detail. The availability of email and SMS subscription options on the incident page suggests GitHub is treating this as an active, evolving event requiring real-time updates rather than a resolved post-mortem. The separate Webhooks incident compounds the impact. Webhooks are automated messages sent from GitHub to other systems when something happens, like code being pushed. They trigger CI/CD pipelines (the automated systems that test and deploy code), automated deployments, and third-party integrations. When pull request creation and webhook delivery degrade at the same time, the blast radius extends beyond individual developer friction into the reliability of automated workflows.

The broader context here is the dependency chain. When pull request creation fails, developers lose the ability to initiate code review. When webhooks fail or degrade, downstream systems that depend on event data, from CI runners to Slack notifications to security scanning tools, silently stall. The combination of both in separate but concurrent incidents means that both the human-facing workflow layer and the machine-facing automation layer of GitHub are under strain.

GitHub's transparency in the July availability report is worth noting. Quantifying the exact number of impacted users and operations, along with both average and maximum error rates, gives platform engineering teams the data they need to calibrate their own reliability expectations. Many platforms do not disclose this level of operational detail. The fact that GitHub publishes these figures monthly allows for trend analysis across reporting periods.

For teams operating on GitHub, the practical steps are straightforward. Subscribing to the incident page via email or SMS provides the fastest path to resolution notification. Engineering leads should verify that their CI/CD pipelines have appropriate retry logic for webhook delivery and that developers are aware that pull request failures may be transient rather than user error. Checking the July availability report against internal error logs from last month can help teams confirm whether they were in the impacted cohort.

GitHub has not yet published a root cause analysis for the current August 17 incident. The July report's metrics suggest the platform has been dealing with pull request reliability issues into the current period, though the two events may be unrelated. The presence of a dedicated incident page with subscription updates indicates active mitigation is underway.