What a Developer Should Do When ChatGPT Goes Down

ChatGPT is down. Twitter is a gallery of error screens. Your pull request is still waiting. The outage is not the story. The story is whether you freeze or keep shipping.

OpenAI has gone dark in 2023, 2024, 2025, and 2026. So have Claude, Gemini, and Copilot, on quieter days. The useful question is not “will it happen again.” It is: in the next hour, what is actually blocked - and what only feels blocked because the chat tab is a 500.

Do not mix two incidents. You lost a copilot. Or your product’s OpenAI calls are 500ing. The first is a workflow problem. The second is an incident. Treat them as different rooms.

1. First five minutes: is it actually down?

Refresh is not diagnosis. Before you open three other chats and a thread about “the end of AI,” spend five minutes naming the failure.

• Check status.openai.com, then status.anthropic.com and Google’s AI status if you already use them. Downdetector is a mood. The vendor status page is a signal.
• ChatGPT the website is not the API, and neither is Cursor. chatgpt.com can be dead while gpt-4o in an editor, or Claude in the same editor, still answers. Name the surface: web app, API, Copilot, Cursor model picker.
• Rule out your side: VPN, DNS, corporate proxy, ad blocker, a stale session. Free-tier rate limits look like an outage if you have been pasting the same file for an hour.
• If the vendor status page is red for your region, stop refreshing forty times. You will not will it back. Switch surface or switch task.

2. Swap the chat, not the whole brain

You do not need a new philosophy of work at 14:00. You need one other model that can finish the ticket. Log into one alternative and continue the same task. Do not migrate your “stack” in the middle of an outage.

• Claude (Anthropic): often stronger on long diffs and careful refactors. If you already have a tab, this is the first door.
• Gemini / Google AI Studio: useful when you need a second opinion or a model that still has quota. Not a religion. A spare battery.
• Cursor, Claude Code, Copilot, Windsurf: if the IDE already has another model wired, switch the picker before you open a browser chat. The context of the repo is already there. That is the point of an agentic editor.
• Docs search, GitHub issues, and the official changelog beat a hallucinated API when the question is “did Next.js rename this.” An LLM is a fast junior. The changelog is the source.

3. Local models: when they save the afternoon

Ollama, LM Studio, llama.cpp - a model on your laptop does not care that chatgpt.com is 500. It also does not know last week’s Next.js release. Use it for the right jobs.

• Good: finish a function from context you paste, explain a stack trace, rewrite a regex, draft a commit message, turn notes into a test name.
• Bad: architecture of a repo the model has never seen, “what is the current App Router API,” anything that must match docs from this month.
• If you have never pulled a local model, an outage is a bad time to start. Do it on a calm Friday: install Ollama, pull one 7B or 14B instruct model, run one real prompt from your job. Thirty minutes once.

4. Work that never needed ChatGPT

The stack trace is still there. The failing test is still red. Git still has blame. An outage is a rude reminder that the model was never the source of truth - it was a fast way to talk to it.

• Read the error. Not the vibe of the error - the file, the line, the message. Then open that file.
• git blame, git log -p, the last three PRs on that path. Most “mysterious” bugs are last Tuesday.
• Official docs, MDN, the library changelog, a minimal reproduction. Slower than a chat. Less fiction.
• Debugger, a failing test, a console.log you will delete. Rubber duck: write the problem in a comment. Often the answer appears before you finish the sentence.
• If you cannot take a single step without a chat, the task was underspecified - or you outsourced the thinking. That is useful information. It is not a personality flaw. Fix the spec, then the code.

5. If the product uses the OpenAI API

This is not “I’ll paste into Claude for an hour.” This is incident response. Users would rather see “the assistant is temporarily unavailable” than a spinner that never ends.

• Name the failure: your key, your quota, your timeout, or their 5xx. The dashboard and the status page disagree more often than you want. Log the status code, not only “AI is broken.”
• If you already wired a second provider, fail over. I have written how an LLM sits behind a paid step and what a provider actually is. An outage is a bad time to design that. It is a good time to flip a flag you prepared.
• Degrade: queue the write, answer from your own FAQ, show a human sentence. Do not retry-storm. Back off. A chatbot that hammers a dying API makes the incident longer for everyone, including you.

6. A kit to assemble before the next outage

Thirty minutes of setup on a quiet day beats three hours of refreshing Twitter. You already know this. The outage is just the invoice.

• A second chat logged in: Claude or Gemini, with billing that will survive a busy afternoon. A free tab you have not opened since March is not a plan.
• The IDE with at least two models in the picker. If Cursor only has OpenAI, you bought a single point of failure and called it a workflow.
• One local instruct model already pulled. Not “I will try Ollama someday.” Already pulled.
• A notes file for the one-liners you always ask the chat: git, docker, kubectl, that jq you never remember. When the chat is dead, your notes still work offline.
• For the product: a fallback flag, a backoff, and one sentence for the UI written in advance. Incidents go faster when you are not inventing copy in Slack.

7. The lesson nobody likes

ChatGPT is a fast junior who has read the internet and none of your production incidents. When that junior is on vacation, the senior still has to ship. I use agents every day. I still need to read a diff, run the tests, and know where the docs live.

Outages will keep happening. Models will keep changing names. The skill that survives is still: specify the outcome, debug the failure, take responsibility for the merge. I already wrote how vibe coding multiplies the discipline you have - and how a vague prompt ships a mess faster. An afternoon without ChatGPT is the same test, unpaid.

Conclusion: keep shipping, keep a spare

Check the status page. Name the surface. Switch model or switch task. If the API is the product, degrade it - do not pretend the spinner is a feature. Then, on a calm day, wire the spare: a second chat, a second model in the editor, one local pull, one fallback flag.

And once a month, close the chat and finish a ticket anyway. Not from nostalgia. So the next outage is an inconvenience, not a blocker. :)