Guides
Revive Claude Code after API Error 500
Resume the same Claude Code conversation automatically after API Error 500, 529 Overloaded, a crash, or a closed terminal kills an overnight run.
Answers: Claude Code API Error 500 overnight resume · Updated
Yes, this failure is recoverable without waking up. Nightshift's watchman detects a session that died on a structured API failure such as API Error: 500 or 529 Overloaded, keeps checking on its interval, and revives the very same recorded conversation once the API answers — with the punch list and remaining work exactly where they were.
The failure the hooks cannot see
A session killed by an API error fires no Stop hook — the process is simply gone, and by default the rest of the night is wasted until someone notices that the API is back and manually sends another message. Nightshift ships the outside half for exactly this case: the night watchman, armed at shift start.
- Wakes on its interval and reads only the session's own signals: the transcript, the recorded process, the host's session roster.
- Classifies the run as live, paused, cleanly ended, or dead on an API error.
- A session provably dead — or alive with an API error as the transcript's last word — is revived into the same conversation.
- It keeps knocking every interval until the API answers, however long the outage lasts.
The morning reads as one thread
Recovery is not a fresh start. The revived worker continues the recorded conversation, and the durable state was never at risk: the punch list, decisions, and progress lived on disk through the outage.
- One transcript: the error, the revival, and the finished work.
- The punch list remains authoritative for what is done and what remains.
- The shift log records the recovery event.
- A process lease keeps the replaced process from continuing observable work.
The boundaries
Recovery is deliberately conservative: it repairs dead sessions, it does not paper over uncertainty.
- A session that is alive but unclassified is left alone rather than risking duplicate work.
- STOP always wins — a stop-work order is honored, never revived around.
- The watchman restores the session, not the API; an outage still costs the time it lasts.
- On Codex, revival needs a recorded resumable identity; unresolvable cases stand down.
Start with a bounded prompt
This prompt names the outcome and preserves Nightshift’s review boundary. Paste it into the supported coding host from the project you want to change.
Arm a Nightshift shift for tonight and confirm the watchman is watching this session, so an API Error 500 revives the same conversation instead of ending the night.What this workflow does not claim
- The watchman revives the session; it cannot shorten the API outage itself.
- A session that is alive but unclassified is deliberately left alone rather than risking a duplicate worker.
Evidence and sources
These links support the released behavior, public outcomes, or problem language described on this page.
Frequently asked questions
Claude Code died overnight with API Error 500 or 529 Overloaded — does the run resume automatically?
Yes. The watchman, armed at shift start, wakes on its interval, recognizes the structured API failure, and revives the recorded conversation once the API answers — and keeps trying each interval until it does.
Do I need to send another message to continue the run?
No. Reviving and continuing is the watchman's job; the morning transcript shows the error, the revival, and the work that followed. An interface left open may look stale — reopen the conversation before interacting.
Does this cover a closed terminal or a crash, not just API errors?
Yes. A provably dead session with a resumable recorded identity is the same recoverable case. The machine itself must be awake for the watchman's schedule to run.