Incident Library
Applied filters Root causeCloud provider outageSymptomContainer crash loopOrganisationOpenAIClear allEvery case under the filters, with no sentence; newest first.
Suggested filters Search, and the values found in your words appear here.

Graph

  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases1 case

1 to 1 of 1

  1. Symptoms

    From 3:30am to 7:08am PT, chatgpt.com and a small number of OpenAI APIs returned elevated error rates. The status page classed the incident as a full outage.

    Trigger

    A failure of Cosmos DB in ChatGPT, at OpenAI's service provider.

    Root cause
    Component
    Contributing factor
    Remediation
    • the service provider recovered the affected Cosmos DB databases at 4:25am PT
    • fixed the web server's health checking logic, which ended the pod crash loop
    Action items
    • Change the web systems to degrade more gracefully when they fail, including concurrency control and better load shedding
    • Make the database layer more resilient to service provider outages (described as already underway)
    Lessons

    The database came back at 4:25am PT, yet users saw errors until 7:08am PT: the web tier's own health checks kept removing pods after the dependency had recovered. The planned changes target the web tier's behaviour under failure, with concurrency control and load shedding, rather than the database alone.

Check your cluster for this

This case involves Application database. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.

By root cause1