GitHub traced two hours of delayed Actions runs to timeouts on one git data partition

Twenty-five percent late and 4% never triggered are two different failures. A run that starts five minutes behind still reports a status when it finishes ^[3]. A run that was never created reports nothing at all, so the required check stays uncreated and there is nothing to re-run ^[4].

GitHub's post-incident summary attributes the delays and the merge problems to one component: background jobs that process pull request updates and generate merge commits, timing out while reading a single partition of git data ^[6]. The backlog those timeouts produced delayed pull request-triggered workflows and degraded the accuracy and availability of mergeability information ^[7]. It also took away the merge button ^[5]. The manual override people reach for during an Actions incident was produced by the jobs that were failing.

Timeouts on that one partition delayed up to a quarter of Actions runs at peak, some by more than five minutes ^[3][6]. The remediation list GitHub published is the right one for a saturating dependency: better resource saturation detection, isolation of impact, stronger backpressure ^[9]. Its immediate mitigations were to shed load, shift traffic away from the affected infrastructure, and restore the component to health ^[8].

The dev.to writeup that relayed the incident recommends auditing CI/CD for single points of failure, and suggests hybrid setups where critical stages run on self-hosted runners or an alternative platform ^[10]. Against the cause it reports, self-hosted runners do not fire. They execute work GitHub has already dispatched, and the failing jobs sat upstream of dispatch, in pull request update and merge-commit processing ^[6]. The scoping in the summary is the useful part for anyone designing a fallback: impact was limited to workflow runs triggered by pull request events ^[1]. A gate job that also runs on push does not wait on merge-commit generation, if that scoping is exact.

Both headline percentages are peak figures ^[3][4]. The window ran about 123 minutes ^[12]. At the peak, 4% is roughly one pull request event in 25 producing no run ^[13]. The figures are given as percentages of runs, with no absolute counts ^[14]. For them to describe your exposure, your pushes have to land in the bad minutes and your merge gate has to be a required check fired by a pull request event.

The writeup called GitHub's rapid detection and communication "commendable" ^[11], though detection on the provider side does not tell you which of your own pull requests lost a run. Over a window that long, an alert on pull requests whose required checks have not been created within a few minutes is what separates a slow queue from a run that will never exist ^[4].