GitHub outage, September 2026: Delays in commit processing

GitHub reported and resolved an incident: Delays in commit processing. It lasted 1 hour.

Resolved

From GitHub's official status page, in their words.

What happened

Started
Resolved
Duration
1 hour
Impact
minor
Affected
Pull Requests
  1. Investigating
  2. Identifiednot posted
  3. Monitoringnot posted
  4. Resolved

Why it happened

GitHub has not given a cause in its updates. We never guess one.

How it was resolved

On September 1, 2026, between approximately 14:01 and 16:01 UTC, updates in response to pushes were delayed, temporarily showing stale diffs. The median time to refresh a diff after a push rose from the normal level of about 3 seconds to over 2 minutes at the peak, and more than 140,000 customer accounts had at least one delayed refresh during the most affected 75 minutes. Pushing commits and opening pull requests continued to work normally. The incident was caused by a sharp, concentrated surge in push volume that saturated worker pools and job queueing infrastructure. Autoscaling did not increase capacity as intended, so the backlog did not clear on its own. The incident was mitigated by manually scaling the affected worker pools and increasing push-processing capacity. This allowed the system to process the backlog, after which refresh times returned to normal. To reduce the likelihood and impact of similar incidents, we are adding quotas and throttling earlier in the push path so a single concentrated source of load cannot saturate shared capacity, improving worker-pool autoscaling so capacity is added automatically, and improving monitors for background job processing so on-call is paged before customers experience delayed pull request updates.

GitHub's closing update

This incident on the GitHub status page

Timeline

Oldest first, from the first notice to the resolution. From GitHub's official status page, in their words.

  1. investigating

    We are investigating reports of degraded performance for Pull Requests

  2. investigating

    Diffs in the PR view may be stale for several minutes. We are investigating and scaling up resources.

  3. investigating

    Time to update pull request diffs have improved to normal thresholds.

  4. resolved

    On September 1, 2026, between approximately 14:01 and 16:01 UTC, updates in response to pushes were delayed, temporarily showing stale diffs. The median time to refresh a diff after a push rose from the normal level of about 3 seconds to over 2 minutes at the peak, and more than 140,000 customer accounts had at least one delayed refresh during the most affected 75 minutes. Pushing commits and opening pull requests continued to work normally. The incident was caused by a sharp, concentrated surge in push volume that saturated worker pools and job queueing infrastructure. Autoscaling did not increase capacity as intended, so the backlog did not clear on its own. The incident was mitigated by manually scaling the affected worker pools and increasing push-processing capacity. This allowed the system to process the backlog, after which refresh times returned to normal. To reduce the likelihood and impact of similar incidents, we are adding quotas and throttling earlier in the push path so a single concentrated source of load cannot saturate shared capacity, improving worker-pool autoscaling so capacity is added automatically, and improving monitors for background job processing so on-call is paged before customers experience delayed pull request updates.

What this means for a business (and what to check now)

  • Retry anything that failed during the 1 hour.
  • Enter any payments, bookings or jobs you took another way.
  • If a deadline fell inside the window, keep this page as your record of the outage.

The full guide: what to do when a service you rely on is down

Other GitHub incidents

Hear about the next GitHub incident as it starts

Free email alerts when the official status changes, with what to do while it is down.