Summary
- GitHub classified the incident as major; it ran from 07:53:59.358 to 09:39:19.558 UTC, a span of 1 hour 45 minutes 20.200 seconds.
- Actions, Issues, Webhooks and Pull Requests were listed as affected services.
- GitHub said Actions jobs could take longer to start and Issues search could serve stale results.
- The provider said at 09:22:21 UTC that it had identified the source of latency, applied a fix and was waiting for processing backlogs to clear.
- GitHub resolved the incident and promised a detailed root-cause analysis; the status record did not disclose the mechanism or affected-user count.
Latency across several development surfaces has a compounding cost. A slow Actions start delays the automated test or deployment. A stale Issues search can make a team act on an incomplete view of work. Delayed Webhooks hold up systems that respond to repository events. Pull Request degradation slows review and merge coordination.
GitHub’s July 23 incident joined those surfaces into one major event. It began at 07:53:59.358 UTC and was resolved at 09:39:19.558 UTC. The precise provider-record span was 1 hour, 45 minutes and 20.200 seconds.
This duration measures incident state, not the working time lost by every customer. GitHub did not publish the number of affected users, jobs, events or repositories. Some teams may have seen no impact; others may have waited after the incident while their own pipelines caught up.
Recovery was a sequence, not one switch
The first status entry named degraded availability for Actions, Issues and Webhooks. Pull Requests were added later. GitHub then described Actions jobs taking longer to start, stale Issues search and similar effects on the other listed services.
Issues was marked mitigated at 09:18:37 UTC, Actions at 09:19:49 and Pull Requests at 09:27:35. Webhooks was reported normal at 09:35:17. Those updates show different service surfaces recovering at different times even though the incident had one shared chronology.
At 09:22:21, GitHub said it had identified the source of latency and applied a fix. Issues and Actions were recovering, while remaining services improved as processing backlogs cleared.
A backlog explains why repair and user recovery can diverge. New work may be processed normally while older jobs, events or requests remain queued. Teams then face decisions about whether to wait, retry or cancel, each of which can produce duplicates or ordering problems if the original work later completes.
The status record does not say that duplicates occurred. It demonstrates the conditions under which customers must manage that risk.
The customer pays in coordination before money can be measured
GitHub did not publish a financial-loss estimate, service-credit calculation or affected-customer denominator. Any dollar total would be invented.
The observable cost is organisational. Developers wait for tests, reviewers work from uncertain state, release managers postpone a deployment, and connected services need to determine whether a Webhook is delayed or absent. Once service returns, the team still has to reconcile what ran and in what order.
Provider status also matters as an information service. The statement that search results were stale lets customers avoid treating absence from search as absence from the underlying issue store. The later backlog notice tells operators that immediate retries may add more work.
The mechanism remains undisclosed
GitHub said it identified the source and applied a fix, but did not name the component, dependency, code change or infrastructure failure responsible. It promised a detailed root-cause analysis as soon as available.
That promise should not be replaced by speculation. Four affected products can share infrastructure, but the incident record alone does not prove which dependency was common.
This event is also separate from the hosted-runner delay incident recorded on July 22. The July 23 episode involved different timing, a broader product set and explicit stale search and multi-service latency. Similar symptoms across consecutive days do not establish one root cause.
The next evidence is the promised analysis: trigger, propagation path, why safeguards did not contain it, and how queue recovery will be protected. Until then, the reliable conclusion is narrower. GitHub restored four service surfaces within 105 minutes, while customers absorbed the uncertainty and reconciliation work created between them.