n8n's AI agent never started. The scheduler still created about 600 error runs.

n8n 2.31.6, released July 24, 2026, added a per-thread circuit breaker for machine-started Instance AI follow-up runs. The fix followed two production error spikes, at 21:37 UTC on July 22 and 07:57 UTC on July 23. In each spike, a sandbox quota 403 ended the machine-started follow-up run during setup, before the agent started, while the post-run scheduler re-armed the pending verification obligation and created another run.

An agent cannot apply its own retry policy when it never begins executing. The failure belongs to the startup path and the scheduler that decides what happens next. The sequence behind this incident shows why ordinary task retries did not contain it, what n8n now limits, and how to test a machine-started follow-up together with scheduler re-entry after a failed start.

The agent never started, but the scheduler kept creating runs

Instance AI had pending work after the visible workflow-building run ended. A machine-started workflow_verification follow-up was supposed to satisfy that obligation, which remained recorded as ready_to_verify. The scheduler could start this internal follow-up without another user message.

According to the maintainer-authored fix PR, sandbox setup called a per-user proxy in front of Daytona and received 403 Have reached end of quota. The run ended during setup, before the agent could verify the workflow or change the obligation's state. The post-run scheduler tick still found ready_to_verify, with no record in that cycle that startup had just failed, so it started the same follow-up again.

Each replacement run reached the same dependency, returned the same error, and caused another scheduler tick. The thread produced about 600 identical error runs at 1 to 2.5 runs per second until the pod died. The first spike also caused self-inflicted 429 responses from the sandbox proxy's rate limiter.

A task retry limit cannot contain a scheduler that forgets the start failure

Model and tool failures occur after an agent starts, where task-level limits and error handlers can count attempts. Trajectory monitoring also begins after startup, when there is a sequence of agent behavior to evaluate. Sandbox creation was a prerequisite here, so none of the agent's task logic owned the error.

The scheduler therefore needed to decide whether it should create another run after setup failed. Its inputs included a persistent obligation but no memory of the failed start. The task retry limit was never reached because the task did not exist yet.

n8n now updates the per-thread failure count from a run's terminal status immediately before the post-run scheduler tick. This order matters. If the scheduler checked first and the count changed later, the next follow-up could still be admitted using stale failure state.

n8n skips another machine-started follow-up after three consecutive errors

The shipped circuit breaker stores a consecutive failure count for each thread. An errored machine-started internal follow-up increments the count. Once it reaches three, startInternalFollowUpRun skips another internal follow-up and writes a warning to the log.

User turns and approval resumes do not extend the streak, so explicit interaction remains available. A run that completes or suspends clears the streak because the thread has demonstrated that it can execute again. Cancelled runs are neutral.

The gate covers internal follow-up kinds including verification, synthesize, replan, checkpoint, and background-completed. Three consecutive machine-started failures stop all of these automatic starts for the thread until a healthy run resets the count.

The fix bounds the loop without resolving the quota error

n8n did not classify the quota 403 as terminal or restore sandbox availability. Operators still have to resolve the dependency or quota failure before verification can succeed. A review comment on the fix PR suggested exponential backoff, but the merged code does not add it: it allows three rapid failures and then stops further machine starts.

The failure streak lives in process memory. A restart clears it and can permit up to three more short failures for the same unresolved thread. A restart may recover the process while reopening the contained loop for another bounded burst.

The source-reported 429s were a secondary effect of rapid calls to the sandbox proxy. OpenAI's insufficient_quota response and monthly hard-spend restoration are a separate production-traffic problem. Likewise, no agent action began here, so a rollback path would have no business effect to repair.

Test the start boundary and scheduler re-entry together

Reproduce the incident boundary in a non-production environment. Leave a verification obligation pending and force sandbox setup to fail before the agent starts; the PR suggests exhausting sandbox quota or making runtime-skill writes fail. Observe the thread rather than one run: n8n 2.31.6 should create exactly three errored machine-started follow-ups and skip the next automatic start.

With the breaker open, send a user turn and resume an approval path. Confirm that explicit interaction remains possible and does not increase the machine-failure streak. Then let a run complete or suspend, verify that the streak clears, and confirm that a pending obligation can start an internal follow-up again. The durability of the approval pause itself belongs to the workflow's pause and safe-resume design; this test only checks that the explicit path remains reachable.

Repeat the failed-start case, reach the threshold, and restart the process. Document whether the deployment admits another three failures after restart. This exposes the practical difference between an in-memory circuit breaker and one whose state survives process lifetimes.

Check the evidence with the run count. Logs should identify the thread, the startup errors, and the warning emitted when n8n skips the next follow-up. Alerts should distinguish startup dependency failures from agent execution failures and detect repeated threshold events after restarts. Monitoring only failed agent tasks will miss this incident because the agent never owned the run.

The implementation decision is concrete: every machine-started follow-up path needs a pre-agent startup-failure test, and the scheduler must record that outcome before it re-enters the obligation. Set a bound on automatic starts, preserve explicit user and approval paths, define the healthy state that clears the bound, and decide whether the count must survive a restart.

BaristaLabs helps teams apply those decisions to process automation, including scheduler state, dependency failures, retries, and recovery around the workflow itself. If an automated process can create follow-up runs without a user present, bring one failure path for review before it runs unattended.

Sources

• n8n 2.31.6 release
• Original fix PR #34767
• Stable backport PR #34773
• Backport commit 031227a