Summary

  • GitHub opened a critical Actions incident at 23:34 UTC on 19 July. New workflows could be delayed or fail to start, while runs already in progress could fail.
  • The disturbance widened to API Requests, Pages and Issues. GitHub later said extended Actions downtime had caused knock-on effects, and it folded a separate Git LFS/API incident into the same investigation.
  • CircleCI reported pipelines that did not start or remained stuck, while OpenAI reported failures or delays in GitHub-dependent coding workflows. Both records independently confirm that the failure crossed company boundaries.
  • GitHub said the cause had been identified, restored Actions by 04:43 UTC and closed the incident a minute later. It promised a detailed root-cause analysis but had not published one at this report's cutoff.

The first failure appeared in the place that executes work. The more important signal came later, when the systems that describe, trigger and observe that work began to fail too.

GitHub reported degraded Actions performance at 23:34 UTC on 19 July. Within minutes it warned that new workflows could be delayed or fail to start and that runs already under way could fail. At 23:57, the company said it had identified the cause and was working to restore service, without describing that cause.

The incident then crossed the boundary of the runner fleet. API Requests entered partial outage at 00:07 UTC. Pages and Issues degraded. A second record reported failures in some Git LFS operations and in loading files through the API. At 01:11, GitHub supplied the causal bridge: the extended Actions downtime had started producing knock-on effects in other services, and a separately opened incident was related.

That statement turns a collection of red status lights into one operational event.

The control plane became the blast radius

Actions is not only rented compute. A workflow is defined in a repository, triggered by an event, broken into jobs and assigned to runners. The run still depends on GitHub to accept events, read repository state, create jobs, communicate status and retain the history used by people and other systems.

That is why a runner problem can spread without every repository or Git operation going offline. A push may exist while the pipeline triggered by it does not start. A job may be executing while the status consumed by a merge rule or external service is stale. A large file may be present in LFS while an API request needed to load it fails. A static site may remain reachable while a new Pages build cannot advance.

GitHub's timeline shows this separation. Pages was reported recovered at 01:37. Issues followed at 02:20. GitHub said Issues, API Requests and Pages had recovered by 02:43, but it was still restoring Actions jobs that used self-hosted or larger-hosted runners. API Requests were declared normal at 03:03. Actions moved to monitoring at 03:34 and was described as fully recovered at 04:43.

The sequence matters more than a single total-duration number. Each customer entered the incident through a different combination of events, APIs, runners and downstream checks. GitHub did not publish the number of failed runs, repositories, organisations or regions, so the public timestamps cannot be converted into universal customer downtime.

Downstream records show state divergence

CircleCI's service record makes the consequence concrete. It attributed workflows stuck in a running state or failing to start to GitHub API errors. It also reported errors while processing push-event webhooks. After GitHub API error rates recovered, CircleCI advised customers to retrigger pipelines that never started and to cancel and rerun pipelines still shown as running.

That is more than a generic dependency notice. It describes divergent state: an event happened in one system, but the system expected to act on it either did not begin or did not reach a trustworthy terminal state.

OpenAI separately reported failures or delays in coding workflows that depended on GitHub and tied the impact to the API partial outage and degraded Actions service. The record did not quantify users, jobs or commercial loss. Its value is narrower: it confirms that the incident reached an external workflow whose customer interface did not belong to GitHub.

These downstream notices are evidence of propagation, not evidence that CircleCI or OpenAI caused the incident. They also do not prove that every connected service failed. They show why a green upstream status is only the beginning of recovery for customers whose workflow state is held in more than one platform.

Owning the runner did not remove the orchestration dependency

GitHub's documentation says a self-hosted runner is a machine the customer deploys and manages to execute Actions jobs. The customer controls the hardware, operating system and installed software and pays to maintain it.

That control can be valuable for security, locality, capacity and specialised hardware. It is not the same as owning the entire workflow control plane.

GitHub specifically said it continued working to restore Actions jobs using self-hosted or larger-hosted runners after Issues, APIs and Pages had recovered. The statement does not prove that customer machines were broken. It shows that available customer compute could still wait on GitHub's orchestration path.

The resilience lesson is therefore precise. Self-hosting a runner can diversify execution capacity, but it does not by itself provide an independent trigger, queue, job assignment, status record or approval path. Teams that need an emergency delivery route must decide in advance which of those functions can operate without GitHub and how they will preserve an auditable release trail when normal checks are unavailable.

Recovery requires reconciliation, not just retry

A blanket rerun can create a second failure. A deployment job may have completed its external side effect before its status update was lost. Repeating it could publish the same release twice, reapply infrastructure changes, resend notifications or overwrite an artefact.

The first question is therefore not “Can the green button run again?” It is “What happened in the target system?” A team should reconcile the repository event, GitHub run history, runner logs, package or artefact state and the deployment target before replaying work. Idempotent jobs and externally verifiable release identifiers reduce this risk; they do not remove the need to check.

CircleCI's advice to cancel stuck pipelines and rerun them is appropriate for its observed state, but each customer still owns the consequences of the work inside the pipeline. A failed build can often be repeated safely. A partially completed production change may require a different recovery path.

The missing evidence is the mechanism

GitHub closed the incident at 04:44 UTC and said a detailed root-cause analysis would follow. The public timeline establishes the affected surfaces and the recovery order. It does not disclose the component that first failed, why the outage reached APIs and other services, whether one mitigation or several restored them, or what design change will prevent recurrence.

There is no public basis here to claim a security breach, lost source code, failed customer deployment, data loss, a particular geography or an SLA credit. GitHub's “critical” classification describes its incident impact level; it is not a measurement of every customer's loss.

The next useful disclosure should explain the dependency that allowed an Actions runner incident to affect API, LFS, Issues and Pages paths, and should separate the initial fault from the backlog and recovery effects. Until then, the defensible conclusion is operational: GitHub restored the service chain, but customers need to test whether their own event, job and deployment records agree before treating the incident as finished.

Sources