GitHub’s Recovery Is Not Your Release Record
Service recovery still leaves operations to reconcile.
GitHub reported degraded Actions, Issues and Pull Requests from 12:21 UTC on 12 October.
At 12:33 UTC, the detailed scope included the Actions interface, Checks API, new workflow queues, issue changes and pull-request review requests through REST and GraphQL.
Pull Requests returned to normal at 13:02 UTC. At 13:38 UTC, GitHub said its first mitigation had not fully worked.
By 14:37 UTC, Actions, Issues and Projects had mitigations. At 15:19 UTC, notifications resumed, but delivery was still delayed by a backlog. GitHub had published no root cause, user count or completion estimate when checked at 17:25 Madrid.
The following steps are BlackTree operational guidance, not GitHub instructions or completed tests.
Separate the service states
Do not treat one recovered component as evidence that the whole developer workflow completed. Build a small incident ledger for each repository and release path, with one row for the requested operation, its provider state and its external result.
Start with work initiated during the incident window. Include workflow dispatches, check results, issue mutations, project updates, review requests and notifications that control a hand-off or approval.
Reconcile Actions with external systems
For each uncertain run, record the repository, workflow, commit, run identifier, queue time and latest visible state. Compare that record with the build system, artifact registry, deployment target and release notes before retrying.
A missing or delayed interface update is not enough to classify a deployment as absent. Confirm whether an artifact was produced, a deployment began or an external side effect completed. Use the workflow’s existing idempotency controls where a replay is necessary.
Review work-item mutations separately
Issue changes, project updates and review requests are state mutations rather than build jobs. Check the final object history before repeating them. A second request can duplicate comments, move an item twice or notify reviewers again without resolving the first result.
Treat notification delivery as its own evidence stream. Confirm the underlying issue, project or review state directly instead of using an absent notification as proof that the operation failed.
Close only after a fresh status check
Define closure for each release path: the intended commit was tested, the expected artifact exists, the deployment state is known, required work-item changes are present and any replay has an owner and reason.
Before declaring a release path clear, perform a fresh provider-status check and record its time beside the incident ledger. If the provider state changes, update the working assumptions and repeat only the reconciliation checks affected by that change.
Source: GitHub incident record.
