Claude Code Errors: What to Do When Claude Is Down (Beginner Fix Guide)

Kristoffer · August 3, 2026 · 11 min read

It's 11pm, you're three prompts away from a working feature, and the terminal spits back API Error 500 overloaded_error. Most Claude Code errors are not your fault and not permanent - but the difference between losing ten minutes and losing the whole evening comes down to knowing which kind of error you're looking at. This is the decision tree: how to tell in 60 seconds whether the problem is Anthropic's or yours, what the five most common messages actually mean, and how to keep shipping when Claude is genuinely down.

First, Answer One Question: Is It Claude, or Is It You?

Before you change a single thing about your setup, find out whether Anthropic is having a bad day. Beginners waste hours reinstalling things during an outage they had no part in.

Do this in order:

1. Open status.claude.com in a browser. This is Anthropic's official status page. Look for an active incident affecting Claude Code or the API.
2. If there's no incident, open a brand new Claude Code session in a different folder and send one throwaway prompt: say hello. Nothing else.
3. If say hello works, the platform is fine and the problem is your session, your project, or your usage. If it also fails, it's not you.

That's the whole triage. Two minutes, maximum.

What the status page words actually mean for you

• Investigating - Anthropic knows something is wrong but not what. Expect errors to keep coming. Stop building.
• Identified - They found the cause and are working on it. Still expect failures.
• Monitoring - The fix is deployed and things are recovering. Try again, but expect the occasional error.
• Resolved - The underlying problem is fixed. This does not mean your terminal is instantly happy.

That last one trips people up. A resolved incident can still throw errors for another 10 to 20 minutes while traffic drains and backed-up requests clear. If you see errors right after a "Resolved" update, wait, don't debug.

One more thing, and it matters: stop hammering the retry. During an overload, every re-prompt still counts against your usage even when it fails. Ten frustrated retries can burn a meaningful chunk of your window and leave you rate limited after the outage ends, which feels exactly like a second outage. Walk away for ten minutes instead.

The 5 Claude Code Errors Beginners Actually See, Decoded

1. API Error: 500 / overloaded_error

Who caused it: Anthropic. Their servers are taking more requests than they can serve, or something broke upstream.

What it means in plain English: Your request never got a proper answer. Nothing on your machine is wrong.

Next action: Check the status page. Wait 5 to 15 minutes. Do not reinstall anything, do not regenerate keys, do not delete your project.

2. 429 / rate_limit_error / "Claude Code rate limit reached"

Who caused it: Usually you, sometimes indirectly.

What it means: You've hit the usage cap for your plan window, or you fired off a burst of requests too quickly - often because you were retrying during an outage.

Next action: Note the reset time if the message gives you one, and stop sending requests. Retrying makes the wait longer, not shorter. Then read the rate limit section below, because this one is almost always preventable.

3. Invalid API key / "Login expired" / OAuth token errors

Who caused it: You, in a boring administrative way.

What it means: Claude Code no longer has valid credentials. Tokens expire, and switching between accounts or between a subscription login and an API key invalidates the old one.

Next action: Run /login and complete the browser flow again. That's it 90% of the time.

4. Context low - run /compact

Who caused it: You, by having a long and productive session.

What it means: This is not an error. Your conversation has filled the model's working memory. Claude is warning you, not failing.

Next action: Run /compact to summarise the session and keep going, or - better, if you've just finished a feature - run /clear and start the next feature fresh.

5. Silent tool-use failures (Claude edits the wrong file, or nothing at all)

Who caused it: Shared blame. Usually an ambiguous instruction or the wrong working directory.

What it means: Claude ran a tool, the tool did something unintended, and no error appeared. This is the most dangerous category because it looks like success.

Next action: Ask directly: list every file you changed in the last message and show me the diff. Then decide what to keep. If your app worked five minutes ago and doesn't now, this is usually why.

The 60-Second Restart Checklist That Fixes Most of Them

Work down this list in order. Stop when the problem goes away.

1. Run /clear to reset the conversation, or quit and start a new session.
2. Run /login and re-authenticate through the browser.
3. Check which model you're on with /model. A session can silently be on something other than what you intended.
4. Confirm you're in the right project folder with pwd. Wrong directory is the cause of an astonishing share of "Claude is not working" reports.
5. Fully quit the terminal application and reopen it. Not a new tab - the whole app.
6. Test your internet with any website. Then turn off your VPN and try again. Corporate networks and proxies block API traffic more often than you'd expect, so if this is a work laptop, test on your phone hotspot.

What this checklist will not fix: a real outage. If the status page shows an active incident, or your say hello test failed in a fresh session, none of the six steps above will help. Doing them anyway is how beginners convince themselves their project is broken when it isn't. Verify first, then act.

Keep Shipping When Claude Is Actually Down

An outage costs you an hour of AI help. It doesn't have to cost you an hour of progress.

Option 1 - drop to a smaller model. Larger models get congested first. Switch with /model and try the same task on a lighter one. It's often enough to finish the feature you were mid-way through.

Option 2 - move the task to a different builder. Browser-based tools like Lovable, Base44, and Bolt don't necessarily route through the same infrastructure as your Claude Code session, so a Claude incident doesn't automatically take them down. If you already have a project open in one, paste your spec and keep building there. This is the single best argument for keeping a backup AI builder from our tool directory set up and logged in before you need it.

Option 3 - do the work you keep postponing. Every beginner has a list of non-AI tasks they've been avoiding because building is more fun. An outage is the ideal hour for:

• Writing your app spec properly - who it's for, the core action, the screens, how it makes money
• App Store or web copy: title, subtitle, description, keywords
• Screenshots and a simple demo video
• Your landing page copy and pricing tiers
• Listing 20 places your first users actually hang out

If you skipped the planning stage, this is the hour to fix that. The complete beginner guide to building apps with AI covers what a good spec looks like, and a better spec makes every prompt after the outage cheaper and more accurate.

Why You Hit Rate Limits Faster Than You Expect

Rate limits feel arbitrary until you see what actually burns usage. The usual culprits:

• One enormous prompt. A 3,000-word brain dump costs a lot to process and usually produces worse results than three focused prompts.
• Pasting whole files into chat. Claude Code can read your files. Pasting them in duplicates that content into the conversation, and it stays there for the rest of the session.
• Leaving a bloated session running for hours. Every message carries the entire conversation history along with it. A six-hour session is expensive by the end.
• Spawning multiple agents at once. Parallel work is parallel spend.
• Re-asking the same broken request five times. Each attempt costs full price and fails for the same reason.

The fix pattern:

1. Plan in one session, build in another. Planning conversations get long and messy - don't carry that weight into your build.
2. Keep tasks small and scoped. One feature, one outcome.
3. Run /clear between features.
4. After two failed attempts, stop retrying. Re-describe the goal instead: what should happen, what actually happens, which file you think is involved.

That fourth habit alone will cut your usage noticeably, because most of the rate limit reports you see are really "I retried a doomed prompt nine times".

Login and Account Errors (Including the Two-Account Problem)

Auth breaks for three reasons, and none of them mean your account is in trouble:

• The OAuth token expired. Normal. Tokens have a lifespan.
• You switched between a subscription login and an API key. Claude Code will use one or the other, and mixing them mid-project produces confusing "invalid key" messages.
• You're juggling two accounts - personal and work. Every switch forces a fresh login flow, and it's easy to end up building on the account you didn't mean to bill.

To reset credentials cleanly:

1. Run /logout.
2. Run /login and complete the browser flow, paying attention to which account the browser is signed into. Sign out of the browser account first if you need to.
3. Run /status to confirm which account and plan the session is now using.
4. If you use an API key on this machine, check your environment variable for a stale ANTHROPIC_API_KEY that's overriding your subscription login. That mismatch is behind a lot of "login expired" confusion.

Two warnings that matter more than the rest of this section. Never paste an API key into a random web tool that promises to test or optimise it. And never let a key end up inside your project files where it can be committed and published. If you're not sure, ask Claude directly:

Check this project for any hardcoded API keys or secrets in the code
or config files. List anything you find and tell me where it should
live instead. Do not print the key values.

Outage-Proof Your Project Before the Next One

Outages are not preventable. Losing three hours of work to one is.

• Save a checkpoint after every working feature. If your app works, lock it in before you touch anything else. Then a mid-build failure costs you 20 minutes, not an evening.
• Keep your spec and prompt history in a plain text file in the project. Call it NOTES.md. Paste in the prompts that produced good results. When you have to rebuild something in another tool, you'll have the exact wording.
• Note which model built which feature. When something behaves oddly later, that one line of context saves you a lot of guessing.
• Keep a second builder account ready and logged in. Not as a replacement - as a lane to switch into.

If git means nothing to you, you don't need to learn it today. Ask Claude Code this:

I have no experience with version control. Set up simple checkpoints
for this project so I can save a working version and roll back if a
change breaks the app. Then give me two commands: one to save a
checkpoint with a short label, and one to go back to the last one.
Explain what each does in one sentence.

Run the save command every time the app works. That's the whole habit.

Quick Reference: Claude Code Errors, Cause, Fix

Does an outage refund my usage?

Assume it doesn't. Failed requests during an incident can still count, which is exactly why you should stop retrying and go do the marketing tasks instead.

Will restarting or running /clear lose my work?

No. /clear and restarting only clear the conversation, not your files. Your project on disk is untouched. What you lose is the context Claude had about what you were doing - which is why the plain text notes file is worth the two minutes.

Should I switch tools permanently after a bad outage?

No. Every provider has incidents, including all the browser builders. Switching tools resets your progress and teaches you nothing. What actually protects you is the habits: checkpoints after every feature, a spec in the repo, and a second builder ready to go. If an error genuinely has you stuck after working through this guide, ask in the community when an error has you stuck - someone has almost certainly hit the same message this week.

Right now, before the next incident: open your project, ask Claude for the two checkpoint commands above, save a checkpoint of your current working version, and create a NOTES.md with your app spec pasted in. Five minutes of work that buys back an entire evening later.