GitHub Recovered. Reconcile Releases
Service recovery still leaves operations to reconcile.
GitHub reported disruption to Actions, Issues and Pull Requests on 12 October, starting at 12:21 UTC. Its scope included the interface, Checks API, queues, issue changes and review requests via REST and GraphQL.
Pull Requests recovered at 13:02 UTC; incomplete mitigation and a notification backlog prolonged recovery.
Update, 15 October: GitHub marked the incident resolved at 20:16 UTC on 12 October. Its public record still contained no root-cause report or affected-user count when checked today.
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.
