Keep real work moving when ChatGPT is down: a 5-minute fallback audit

The outage is a continuity test

If your team's workflow depends on a single AI assistant, the first sign of trouble is not a status banner. It is a draft that will not finish, a ticket that will not triage, a code review that stalls, and a manager asking why the pipeline is quiet. The outage made that dependency visible in the least flattering way: multiple major AI chatbots experienced a near-simultaneous outage. Users reported problems using both the web site and mobile app, so the failure was not a single browser tab, a bad VPN, or a tired intern. OpenAI's status page reported serious errors in ChatGPT and Codex, which matters because the same dependency can sit behind customer-facing drafting and internal engineering work. Early reporting hypothesized that a sudden traffic increase collapsed a Cloudflare route serving the affected companies, a reminder that shared infrastructure can turn a vendor problem into a multi-vendor problem. As of the reporting, no company had detailed the exact technical cause of the errors, and ChatGPT/OpenAI was reported as the first service to return to normal operation.

That last detail is not a comfort. It is a warning. If your team can only work when one service is green, your continuity plan is a hope, not a design. The teams that keep work moving are not the ones with the most prompts. They are the ones that pre-wire task-specific fallbacks before the outage finds them.

The audit: five moves, five minutes

The audit is not a disaster drill. It is a five-minute inventory of where the assistant is load-bearing. Do it for each workflow that touches revenue, customer trust, engineering velocity, or compliance. The goal is simple: when the tool is down, you should know what to do, who does it, and what quality bar applies.

1. Classify the task by capability, not by tool. A drafting task may need structure, tone, and domain constraints. A coding task may need repository context, tests, and review. A research task may need source quality, citation, and synthesis. A support task may need policy, empathy, and escalation. If the fallback is “use the other assistant,” you have not classified the task; you have just renamed the dependency.
2. Map the dependency. Ask where the assistant enters the workflow: intake, drafting, summarization, code generation, ticket triage, or final review. Then ask what breaks if that step disappears. If the answer is “nothing,” you may be overestimating the tool. If the answer is “everything,” you need a fallback before the next incident.
3. Pick a fallback by capability. For drafting, a human template with required sections can preserve quality. For coding, a manual review checklist and test suite can keep changes safe. For research, a source list and synthesis outline can prevent hallucinated confidence. For support, a policy matrix and escalation path can protect customers. The fallback should be boring enough to use under stress.
4. Set a human handoff. Name the person or role who owns the fallback. Define the quality bar: what is acceptable, what needs review, and what must be escalated. If no one owns the fallback, the fallback is a rumor.
5. Test it before the outage. Pick one recurring task and do it without the assistant for a short window. Not a full sprint. Not a performance review. Just enough to see whether the fallback produces usable work, where it slows down, and what needs to be tightened. If the test is too painful, the fallback is not ready.

What to keep in the runbook

After the audit, write the result in a place people can find it under pressure. A shared page is fine. A wiki page is fine. A note in the ticketing system is fine. The format matters less than the content. Each entry should answer four questions: what task is affected, what the fallback is, who owns it, and what the quality bar is. If the answer requires a meeting, it is not a runbook; it is a negotiation.

• Drafting: template, owner, review standard, and a list of phrases or claims that require human verification.
• Coding: test command, review checklist, and the minimum bar for merging without the assistant.
• Research: source list, citation rule, and the difference between a summary and a claim.
• Support: policy matrix, escalation path, and the line where a human must take over.

When the service comes back

Do not treat restoration as the end of the exercise. The useful question is not whether the service is available again, but whether the fallback kept the work honest; if it produced slower but defensible output, keep it. If it produced panic, fix the handoff. If it produced nothing, the dependency was larger than the team admitted. The next outage will not care about your vendor loyalty. It will care about whether your workflow has a spine.