Summary
- GitHub reported degraded performance for API requests at 03:53:19 UTC.
- The incident title specified GraphQL API Requests, while the status update referred to API Requests without the same qualifier.
- GitHub posted mitigation at 04:09:01 UTC and resolution at 04:09:10 UTC, about 16 minutes after the first notice.
- The status record did not quantify failed requests, affected customers or geography.
- GitHub said a detailed root-cause analysis would follow, but it was not present in the incident record reviewed for this report.
How expensive can 16 minutes be when GraphQL sits inside automation? Duration measures how long the provider reported degradation. It does not count every failed call, delayed job or retry that a customer may have to reconcile after service returns.
GitHub’s incident began at 03:53:19 UTC with degraded performance for API requests. Mitigation was posted at 04:09:01 and resolution at 04:09:10. The visible provider interval was therefore about 16 minutes.
The chronology is unusually precise. The scope is less so. The incident title names GraphQL API Requests, while the update language says API Requests. That difference should be preserved rather than silently broadening or narrowing the event.
The title and update define an uncertain boundary
GraphQL is a specific API surface through which clients request structured data. It can sit beneath dashboards, integrations, repository tools and internal automation.
If only GraphQL was degraded, REST or other services may have behaved differently. If the update’s broader wording reflected a wider API issue, the title may describe only the initial or most visible component. The status page does not settle that interpretation.
The safe account centres the event on the named GraphQL incident and reports the provider’s broader wording as a scope ambiguity. It does not claim every GitHub API failed.
GitHub also published no request-failure percentage, customer count, region or latency distribution. A short interval could contain a low error rate or a sharp spike; the public record does not distinguish them.
Retry cost follows calls, not minutes
An interactive user may refresh and continue. Automated systems can react differently. A scheduled workflow may fail, a queue may back off, and a client may amplify load through rapid retries.
Recovery at the provider does not automatically replay customer work. Some jobs will retry by policy, some will remain failed, and others may require a person to restart them.
Idempotency matters for mutations. A caller needs to know whether the server rejected an action, completed it before a response was lost or accepted it for later processing. Repeating without checking can create duplicate effects.
That is why a 16-minute provider duration can produce a longer customer recovery period. The residual unit is not minutes but requests and jobs waiting for a trustworthy final state.
Resolution closes availability, not explanation
GitHub posted mitigation nine seconds before resolution. Those messages indicate that the provider saw recovery and then closed the active incident.
They do not establish the initiating cause. The record promised a detailed root-cause analysis, but that account was not present in the incident page examined here. No infrastructure fault, deployment error, capacity problem or dependency should be inferred.
The next useful evidence is the promised analysis: affected component, trigger, detection, mitigation, safeguards and accurate impact metrics. It should also clarify whether “API Requests” was shorthand for GraphQL or a wider boundary.
Customers can meanwhile inspect logs between 03:53:19 and 04:09:10 UTC, including retries after the window. Failed jobs, elevated latency, duplicate attempts and unprocessed queues are the relevant local evidence.
GitHub resolved the visible incident quickly. Precision about that success should coexist with precision about what remains unknown. The service recovered in roughly 16 minutes; the workload cost, technical cause and exact API scope were not resolved by the status text itself.