OpenAI’s own report on the September 3 ChatGPT outage shows why an AI outage plan needs a named owner and a manual fallback before the next one.
- ChatGPT and Codex returned errors for about 37 minutes on the morning of September 3, 2026, after a routing change, according to OpenAI.
- Recovery took longer because returning traffic overloaded services. Your own team will do the same thing when it comes back.
- OpenAI says it has updated alerts to page properly outside business hours. Check whether yours do.
On September 3, 2026, starting at about 7:43 a.m. Pacific time, ChatGPT and Codex began returning errors, and OpenAI says the broad disruption was mitigated by about 8:20 a.m. That was 8:43 to 9:20 a.m. in Calgary and 10:43 to 11:20 a.m. in Toronto, and it put every company’s AI outage plan to a live test in the middle of a working morning. If your support replies, sales follow-ups or code reviews ran through ChatGPT that day, you were tested whether you had written a plan or not.
Thirty-seven minutes is short. What your team did during those minutes is the part worth measuring.
What the evidence says
- OpenAI’s incident report blames a routing configuration change, rolled back by engineers.
- Users saw “not found” errors on web, mobile and desktop, plus some sign-in failures.
- Returning traffic overloaded some services and slowed recovery.
- An outage plan is a short list of tasks, owners and manual steps. Most teams have none.
What did OpenAI say went wrong?
OpenAI’s report says its routing system misread a configuration update and stopped sending requests to available services. Engineers rolled the change back. Then, as routing came back, the returning traffic overloaded some services and stretched the recovery. Users saw errors across ChatGPT on web, mobile and desktop, and in Codex on the command line and desktop app.
Some could not sign in or create accounts.
The report is unusually plain about its own gaps. Among its fixes, OpenAI lists staged rollouts with automatic rollback, better handling of returning traffic, and alerts that now “properly page outside business hours.” We take that last line at face value (it is a vendor statement, not something we can check). It is also a useful prompt for your own on-call arrangements.
The same status history shows a separate September 2 incident, when a configuration update caused errors for some users of ChatGPT Work Mode. Two configuration incidents in two days do not prove a trend. They do show that these services change often, and that change is where failures start. Bookmark the Claude status page as well, so the fallback vendor has a live check of its own.
Who owns the work in an AI outage plan?
Someone in your company should own each task that depends on an AI tool, and that person should know what happens when the tool goes dark. Most small teams have no such owner, because the tool was adopted by individuals and paid for on a card. An outage is when you find out who should have owned it.
Someone in your company should own each task that depends on an AI tool, and that person should know what happens when the tool goes dark. For most small teams that owner does not exist. The tool was adopted by individuals, paid for on a card, and folded into daily work without anyone writing down which tasks now depend on it. An outage is when you find out.
Start with the list. Which tasks would stop or slow if ChatGPT, Codex or Claude returned errors for an hour on a Tuesday morning? Customer replies, meeting notes, first drafts of quotes and code review are common answers. Each one needs a named owner and a manual path, even if the manual path is slower.
- First reply to customer emails Owner: Support lead; Manual fallback: Saved reply templates; Longest acceptable delay: Example: 2 hours
- Code review on pull requests Owner: Engineering lead; Manual fallback: Human reviewer rota; Longest acceptable delay: Example: half a day
- Meeting summaries Owner: Meeting organizer; Manual fallback: Notes taken by hand; Longest acceptable delay: Example: end of day
The delays in the table are examples. Fill in your own.
What should you measure after an outage?
Measure the time between the first error and the moment your team switched to its fallback, and compare it with the vendor’s own outage length. If OpenAI’s disruption lasted about 37 minutes and your team spent 30 of them retrying, refreshing and asking each other in chat, your real cost was the lost half hour, not the outage itself.
The second measure is the backlog. OpenAI’s report says returning traffic overloaded its services. Your team does the same: once the tool comes back, everyone resubmits at once, and the queue of half-finished drafts takes time to clear. Note how long it took to get back to normal after service returned. That number belongs in your baseline.
A short status check helps too. Bookmark the vendor’s status page and agree that the person who notices errors checks it first and posts in one channel. That one habit saves the ten people who would otherwise each check on their own.
Why it matters in Canada
US vendors report outage times in Pacific time, and Canadian teams in Eastern and Atlantic time zones feel them later in the working day. An early-morning Pacific failure lands at midday in Halifax.
If you bought on a self-serve plan, read your terms for any uptime commitment. Where there is none, the fallback is yours to build. Our earlier piece on an AI vendor fallback plan covered what to do when a model is withdrawn. A morning outage is the smaller, more frequent version of the same problem.
What would change our view
If outages at the major AI vendors became rare enough that none affected working hours over a full quarter, a written fallback for every task would be overkill, and a single status-page habit would do. Two incidents in the first week of September point the other way for now.
Try This Week
- Task: list every daily task that stops if your main AI tool is down for one hour.
- Owner: the operations lead, or whoever pays the AI subscription.
- Metric: minutes from first error to switching to the manual path.
- Baseline: today it is unknown. Ask three people what they did on the morning of September 3.
- Threshold: under 10 minutes to switch, with one person posting status in one channel.
- Deadline: Friday, September 11.
When you have the list, set it beside the work you already track for AI return on investment and the controls in our AI agent security checklist. More on running AI at work sits in AI in Business and in our AI for business guide.
FAQ
How long was the ChatGPT outage on September 3, 2026?
OpenAI says errors began at about 7:43 a.m. Pacific time and the broad disruption was mitigated by about 8:20 a.m., roughly 37 minutes.
What caused the ChatGPT outage?
OpenAI says a routing configuration change stopped requests from reaching its services. Engineers rolled the change back.
What should an AI outage plan include?
A list of tasks that depend on the tool, a named owner for each, a manual fallback and the longest delay you can accept.
