Why AI agents stop running
An agent that has stopped and an agent with nothing to report look identical from the outside. That is what makes this the most expensive failure in the category. Here are the reasons agents actually stop, roughly in order of how often they happen, and what each one looks like when you go looking.
Direct answer
Why did my AI agent stop running?
Almost always one of six things: the process crashed and nothing restarted it, the host rebooted, an API key expired or was revoked, the model account ran out of credit, a tool or website the agent depends on changed, or the schedule never fired because the machine was asleep. The first step is checking whether the process is alive, not rewriting the prompt.
Symptom to cause
| What you see | Most likely cause | First thing to check |
|---|---|---|
| Nothing at all, no logs | Process died, or schedule never fired | Is the process alive |
| Stopped overnight | Host rebooted | System uptime |
| Fails every run at a precise time | Credential expired or revoked | Logs, for an auth error |
| Runs but produces nothing | Out of credit | Provider billing page |
| Quality got worse, gradually | Model or dependency changed | Provider and API changelogs |
| One step fails, rest works | A tool or site changed | That tool in isolation |
1. The process died and nothing brought it back
The single most common cause, and the most mundane. Long-running processes get killed: the kernel reclaims memory under pressure, an unhandled exception escapes, a dependency segfaults. On a laptop this is invisible. On a server without a restart policy, it is equally invisible.
- Symptom: everything worked, then nothing, with no error anywhere you look.
- Check: is there still a process? On a server, is the service active rather than merely enabled?
- Fix: a supervisor that restarts on failure, and an alert when it does so repeatedly. A restart loop is a different problem wearing the same mask.
2. The host rebooted
Automatic security updates reboot machines. Power blips restart Mac Minis. Cloud providers migrate instances. If the agent was started by hand in a terminal, none of it survives.
- Symptom: the agent stopped at a time nobody was working, often overnight.
- Check: system uptime. If it is shorter than the outage, you have your answer.
- Fix: the agent has to start on boot, not when someone types a command.
3. A credential expired, rotated, or was revoked
Provider keys are not permanent. They get rotated on a schedule, revoked after a leak scan, or invalidated when a team member who created them leaves. The agent then fails on every run, usually with a 401 buried in a log nobody reads.
- Symptom: consistent failure starting at a precise moment, on every run.
- Check: the logs, for an auth error rather than a model error.
- Fix: store credentials in one place so rotation is one edit, and make auth failures loud rather than another retry.
4. The money ran out
A prepaid balance hit zero, a card expired, or a spending limit you set months ago was reached. The agent is alive and correctly configured, and every model call fails.
- Symptom: the agent runs, logs an attempt, and produces nothing useful.
- Check: the provider's billing page before anything else.
- Fix: a balance you can see, and an alert before zero rather than at zero.
5. The world changed underneath it
This is the one that gets misdiagnosed as a prompt problem. A model was deprecated. An API changed a field name. A site the agent reads redesigned its markup. The agent is running perfectly and doing the wrong thing.
- Symptom: output quality degraded rather than stopped, or one specific step now fails.
- Check: the changelog of whatever it depends on, and whether the failure is one tool or all of them.
- Fix: pin what you can, and treat a dependency change as an event worth re-testing after.
6. The schedule never fired
The agent did not fail. It was never asked to run. A cron job on a sleeping laptop does not queue up and catch up later; the moment simply passes.
- Symptom: no logs at all for the run, as opposed to a failed run.
- Check: whether anything was recorded for that timestamp.
- Fix: run the schedule somewhere that does not sleep, and record every trigger even when the work is a no-op.
The detection problem underneath all six
Notice that five of the six are easy to fix and hard to notice. That asymmetry is the actual problem. An agent that reports nothing on a quiet day and an agent that has been dead since Tuesday produce the same silence, so the only reliable signal is a heartbeat: proof the agent ran, sent whether or not it had anything to say.
Related guides
Observability
AI agent monitoring
Monitoring an AI agent is not uptime monitoring. Five signals worth watching, why output volume lies to you, and how to catch a silent stop within a run.
Read guideThe homework, itemised
Stop babysitting your AI agents
Running an AI agent is easy. Keeping it running is the homework: restarts, key rotation, silent failures, runaway spend. The whole list, and who does it.
Read guideThe rota
AI agent maintenance checklist
The recurring work an always-on AI agent creates, sorted by how often it comes up: daily checks, weekly reviews, monthly rotations, and quarterly re-testing.
Read guideFrequently asked questions
How do I know if my AI agent is still running?
Do not infer it from output, because an agent with nothing to report is indistinguishable from a dead one. Use a heartbeat: have the agent record every scheduled run, including runs where it found nothing, so the absence of a record is itself the alarm.
My agent worked yesterday and does nothing today. Where do I start?
In this order: is the process alive, did the host reboot, is there an auth error in the logs, and is there credit on the account. Four checks, and they cover most stoppages. Rewriting the prompt is the last step, not the first.
Why do agents fail silently instead of erroring?
Because most agent loops are written to be resilient, and resilience looks like swallowing errors and trying again. That is right for a flaky network call and wrong for an expired key, so failures that will never succeed on retry should be loud and should stop.
Does a VPS stop agents from crashing?
No. A VPS removes one cause, the closing laptop lid, and leaves the rest. Processes still get killed under memory pressure, hosts still reboot for updates, keys still expire. What a VPS gives you is the option to configure a restart policy, which you still have to configure.
How does Qoren handle this?
Environments are health-monitored and agents restart rather than staying down, scheduled runs are recorded whether or not they produce output, credentials live in an encrypted vault so a rotation is one edit, and the credit balance is visible with a hard stop instead of a surprise bill.
Run OpenClaw, Hermes or Codex agents 24/7, without the homework.
Qoren runs the machine, the secrets, the updates and the logs, with a hard cap on credit spend. Start from a template and have an agent working today.