Why Your AI Agents Stop Running Overnight (and the Fix)

AI agents that stop overnight are almost never broken at the model. The usual causes are a machine that went to sleep, a request that reported “accepted” while the work never ran, and a setup with exactly one host to run on. All three are plumbing, all three are checkable in an afternoon.

We hit all three in October 2026, on our own systems. This is what each looked like, what held, and what you can test this week.

What does an overnight stall look like?

An overnight stall looks like silence. A message sent at night gets no reply until morning, a batch of parallel agents all fail within minutes of each other, or a scheduled run simply never shows up in the logs. Nothing errors loudly. That quiet is the symptom, and it is why people blame the model first.

Two of our October 2026 incidents looked completely different on the surface.

In the first, several coding agents we had dispatched in parallel, in the evening, all reported a stall at roughly the same time. Nothing was rate limited. The work trees were clean: no commits, no half-finished edits. The agents had simply stopped being able to make progress.

In the second, our personal assistant agent, the one that answers messages in a chat app, ignored two late-evening messages and answered both only when the morning came. The model was fine. A test call to it worked the whole time.

The shared fingerprint is timing. If failures cluster in one window, and that window is when nobody is at the keyboard, suspect the host before you suspect the agent.

Why does a sleeping computer stop AI agents?

A laptop that goes to sleep suspends every process on it, including your agents and their network connections. Apple’s own support documentation lists sleep after inactivity as a default behaviour and offers a setting to prevent automatic sleeping on power. An agent running there does not fail. It pauses, and a pause looks like a stall.

Here is the part that cost us time. When several parallel agents stalled together in October 2026, the tempting reading was an overload: too many agents, too many requests. So the instinct was to cut concurrency and re-plan.

The clock gave it away. The stalls began after the machine’s normal sleep window. Once the machine was awake, the same number of agents ran fine. We resumed the same agents instead of starting fresh ones, because their context was intact.

Three habits came out of it:

• When several agents stall at once, check the time and the machine before the plan.
• Check the work trees for partial work. Ours were clean, which told us nothing had run, rather than something had run badly.
• Resume the stalled agent where the tooling allows it. A fresh agent starts from nothing.

Apple’s guidance also describes a “wake for network access” option on laptops. That is useful for shared folders. It is not a promise that your agent’s outbound work will be scheduled while the lid is closed, so do not build on it.

What does an HTTP 202 actually tell you?

An HTTP 202 means the server accepted the request for processing. It does not mean the work started, finished or succeeded. Mozilla’s MDN documentation describes it as non-committal and says the processing outcome is not guaranteed. If your agent dispatcher treats 202 as “done”, it will report success on work that never ran.

This was the second cause, and the nastier one, because it hid the first.

Our assistant had a fallback. If the main worker was unreachable, a cloud fallback would pick up queued messages. The fallback was dispatched by sending a request to a background function. Netlify’s documentation says plainly that a background function returns an empty 202 straight away and that the originating client never sees the result. So a bad credential, a missing address or a crash inside the function all looked identical to success: a 202 and a clean log line.

Add a second flaw. The fallback only looked back a couple of hours for unclaimed messages. Anything older aged out of the query and was abandoned. A message sent late in the evening was therefore invisible to the fallback by the early hours, even if the dispatch had worked.

So the fallback existed on paper, ran on a schedule, logged success, and rescued nothing.

What fixed it?

Two changes held. We widened the lookback window to a full day, so a queued message stays eligible all night. And we replaced the fire-and-forget request with a direct drain inside the scheduled job itself, which either sends the reply or fails in a place we can see. The claim step is atomic, so if the main worker wakes and grabs a message first, the fallback does nothing.

The fix merged and deployed in October 2026. One honest caveat: as of this writing we have not yet confirmed it end to end with a real overnight message, so we are not calling it closed. The check is scheduled and we will say so in a later post when it has run.

The pattern generalises. Wherever your system fires a request and moves on, ask what tells you the work happened. Fire-and-forget is fine for work you can afford to lose. Messages from a customer or a founder are not that.

Cause	What you see	Cheap check
Host asleep	Clustered stalls, clean work trees	Compare stall times with the machine’s sleep window
202 treated as success	Green logs, no outcome	Find one 202 and trace it to a visible result
Short lookback	Old items silently dropped	Age your oldest queued item against the query window
One host	Everything pauses together	Name the second host that would take the work

Do you need a second host?

Yes, if overnight work matters. One host means every maintenance reboot, sleep cycle or lost connection stops everything at once. A second host does not need to match the first. It needs to be able to claim the same queue, safely, when the first is silent. The claim must be atomic so two hosts do not both act.

We run our own agent fleet on this principle, and the second-host story is still partly unfinished, so here is the plain version.

In October 2026 we made an always-on machine the primary place our coding lane runs, and left the laptop as secondary, because the laptop sleeps nightly by design. That removed the original cause. What we designed but have not built is a message link between the two hosts, so each can see and nudge the other. As of this writing that design exists as an unmerged change. Do not read it as live.

If you are choosing where to start, do not start with a message bus. Start with one always-on host plus one fallback that can claim the same queue.

What can you check this week?

Run these four checks before you trust an agent to work while you are away. Each takes under an hour, and each one targets a failure we actually had rather than a hypothetical.

1. Sleep. List every machine that runs an agent. For each, find out whether it can sleep and when. Move anything unattended to a host that cannot.
2. 202s. Find every place a request is fired and forgotten. For one of them, break it on purpose (a wrong credential is enough) and see whether anything tells you. If nothing does, you have found a silent failure.
3. Lookback. Compare the age of your oldest unprocessed item with the lookback of whatever is meant to rescue it. The lookback must be longer than your longest quiet stretch, with a margin.
4. Evidence. Send one real message late at night, then check in the morning that a person-visible reply exists. A log line is not a reply.

The fourth check is the one we still owe ourselves. A test that runs while someone is watching proves little about the hours when no one is.

This is the same habit as writing down who owns what and what happens when something stops. We cover that side in what to document for low-touch AI operations, and the assistant incident also appears briefly in our write-up on a chat-based executive assistant agent.

Where does this fit in running a fleet?

Overnight reliability is an operations job, not a model job. Each agent needs an owner, a freshness check, a visible failure path and somewhere to run when its first host is down. That is what a fractional AI officer does for a business that has agents but not the time to watch them: AgenTomte’s fractional AI officer service reviews your setup against checks like the four above and fixes what it finds.

Our own side of this is on the public record. The agent fleet proof page shows what we run and how it has held up, as of its latest date.

A tomte, our word for one production agent with one defined job, is meant to do its work overnight and leave you to find it done. That only works if the night is accounted for.

If your agents go quiet after dark, Start async. Tell us what runs, where, and when it last stopped. We reply within one business day, and there are no meetings.