Summary
- GitHub opened incident sj1tzyrx599x at 18:03:05.539 UTC on 1 August and resolved it at 18:44:28.733 UTC.
- The public incident span was 41 minutes and 23.194 seconds.
- GitHub first reported increased error rates from specific upstream AI model providers, without naming a model or provider.
- At 18:20:20.807 UTC it identified degraded Fable 5 availability in Copilot products and IDE surfaces and recommended another model or Auto.
- GitHub marked mitigation at 18:20:48.941 UTC, 28.134 seconds after the model-specific update, and said Fable 5 was available again at 18:23:40.021 UTC.
- The provider, cause, request denominator, error rate, user count and geography were undisclosed; GitHub promised a detailed root-cause analysis.
The first 17 minutes described a class, not a route
At 18:03:15.483, GitHub reported increased errors from “specific” upstream AI model providers. That phrasing narrowed the incident away from all Copilot functions but did not tell a customer which selection to avoid. Fable 5 was named at 18:20:20.807, 17 minutes and 5.324 seconds after the error-rate update.
The record cannot say whether that interval reflects technical fault isolation, confirmation with a supplier, publication review or a combination. It can show only the progression of public information: from a provider class to one named model.
Once named, mitigation was almost immediate
The model-specific notice was followed 28.134 seconds later by a monitoring update saying the degradation had been mitigated. Fable 5 was explicitly available again at 18:23:40.021, another 2 minutes and 51.080 seconds later.
This timing should not be read as a 28-second technical repair. The upstream intervention may have begun earlier, while GitHub was still investigating. The timestamps reveal disclosure and state transitions, not the full private operating sequence.
A workaround needed a model name
GitHub recommended choosing another model or Auto in the Fable-specific update. Before that disclosure, a user could know that an upstream provider class was impaired but not whether switching away from Fable was the appropriate action.
Once again, alternative routing offered continuity without guaranteeing equivalence. The status page gives no Auto destination, switching-success rate, latency or behavioural comparison. It records the option, not its measured customer outcome.
Same day does not establish same cause
Earlier on 1 August, GitHub had a separate incident involving GPT-5.6 Luna and an upstream model provider. Temporal proximity and similar wording are not enough to establish that the same provider, infrastructure or failure mechanism produced both episodes.
The Fable record names neither provider nor root cause. Treating the incidents as one shared outage would create a relationship the sources have not published. They are best analysed as two observations of a common dependency pattern, not proof of one common fault.
The public span ended with extended monitoring
After mitigation at 18:20:48.941 and the Fable-available update at 18:23:40.021, GitHub did not close until 18:44:28.733. The final monitoring period therefore extended 20 minutes and 48.712 seconds beyond the availability confirmation.
GitHub did not disclose what it measured during that time or the stability threshold for closure. The duration shows caution in the public workflow but cannot quantify residual errors.
Enterprises should preserve selection and fallback events
Teams can log model choice, error class, retry, Auto selection when visible, response latency and whether the result entered a downstream workflow. During a generic provider alert, temporarily broadening or narrowing allowed models may be an explicit operational decision rather than an invisible UI preference.
This incident supplies no evidence of compromised prompts, exposed code or corrupted output. The published symptom was availability and error rate. Any security or integrity conclusion would require separate evidence.
Root-cause analysis should address recognition as well as repair
The promised analysis should explain when GitHub first knew Fable was implicated, how provider health maps to model identity, what triggered mitigation, how Auto responded and how many requests or users were affected. It should also state whether the earlier Luna episode was unrelated or shared any dependency—without leaving readers to infer it.
The current record supports a narrow finding: Fable 5 degraded during a 41:23.194 public incident, and the status page moved from generic upstream errors to a named route before recovery. It does not identify the provider, causal mechanism, measured reach or relationship to the earlier event.
