Live › incident › INC-github-dnslv7xdl4fj
Go to dashboardBetween 0655 and 0801 UTC on 10/27, a database migration at GitHub caused authenticated API and git requests using GitHub App server-to-server tokens (excluding Actions tokens) to return false 404 errors. The incident was an availability problem, and GitHub reports it as resolved, with no attacker access involved.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-27 20:24 UTC. All times on this page are UTC.
Teams whose automation or CI authenticates to GitHub with GitHub App server-to-server tokens (excluding Actions tokens) saw failed git and API calls during the window. The sources describe a resolved outage with no data exposure, so no action is required beyond reviewing failed jobs from that period.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| GitHub | vendor | – | – |
Unknown from the sources.
Unknown from the sources.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
Between 0655 and 0801 UTC on 10/27, customers experienced increased failure rates for API and git requests authenticated with server-to-server tokens for GitHub Apps (excluding Actions tokens). During this window, authenticated git operations mistakenly returned 404 for 1.24% (2.6x) of requests on average and 2.49% (5.3x) at peak.
These failures were caused by a scheduled maintenance event where GitHub migrated 7 tables between two MySQL clusters in our IAD and Azure Central US datacenters. One of the affected tables stores installation records for GitHub App server-to-server tokens (excluding Actions). We've successfully completed several of these migrations in recent months without notable customer impact. However, in this case, the migration coincided with a scheduled cleanup job on the installation records table, which deleted approximately 59 million records from 0444-0617 UTC. As a result, the gh-ost tooling used in the migration experienced inter-cluster replication delays (up to 1 hour at peak).
At 0655 UTC, we begin transitioning reads of the target tables to the new MySQL cluster, with 100% of reads cutover at 0721 UTC. Customer impact began, but was not detected, throughout the read cutover and persisted until completion of the write cutover at 0801 UTC. We are updating our processes and automation to prevent a repeat of this incident, including disabling overlapping cleanup jobs prior to these migrations and blocking the cutover of reads when replication delays are high.
This page as .md · .json · in your agent: get_signal("INC-github-dnslv7xdl4fj")