The Workflow That Wouldn't Stop Spending: Putting a Budget on Every n8n Run

A developer running LLM workflows in n8n in production described enforcing a four-part budget on every run — max iterations, max rows admitted, max LLM calls or tokens, and a per-node timeout — so that runaway loops, unbounded pagination and multiplying retries stop and land in review instead of silently inflating the bill. Over-budget runs carry their spend, stopping point and remaining rows so they can resume without re-billing already-processed work, and workflows that repeatedly trip their caps have their triggers paused. The developer tests each budget against a mock billed downstream with a deliberately tiny cap to confirm the run stops, lands in review and resumes without double-charging.

This is part of my build-in-public series on running LLM workflows in n8n in production. Everything here is a failure I actually watched happen, not a hypothetical. A runaway n8n loop does not announce itself with a performance problem. It announces itself with a bill. A loop that calls a model on every iteration, a pagination that fetches the whole table, a retry that re-triggers a billed downstream action — each one is cheap per step and ruinous in aggregate, and none of them throw an error while they are doing it. Green executions, growing invoice. That is the shape of the bug: the workflow is working exactly as written, and what is written has no ceiling. I now put a budget on every run before it starts, not after the invoice arrives. A budget is four numbers, decided up front: max iterations, max rows admitted, max LLM calls or tokens per run, and a per-node timeout. If any of them is hit, the run stops and lands in review — with what it already spent and where it stopped attached. It never silently continues, and it never silently drops the work either. Both silences are the same failure: one burns money, the other burns data. First, per-iteration model calls. A loop that summarizes, classifies, or enriches each row with one LLM call per item turns a 500-row input into 500 billed calls. The fix is not "use a cheaper model" — it is a cap on calls per run plus batching: group rows into one call where the task allows it, and let the cap be the backstop when batching is impossible. Second, unbounded pagination. A "fetch all, then process" step with no row cap will happily pull ten thousand rows because the API kept handing over next pages. Cap rows admitted to the loop, and record the fetch outcome separately source, status, rows admitted so a capped run is distinguishable from a complete one. A run that stopped at its cap is not a run that processed everything. Third, retries that multiply cost. A failed step that retries, where each attempt re-triggers a billed downstream action — a send, a charge, an enrichment call — turns one failure into three bills. The retry budget belongs to the error class, not just the job: permanent errors spend zero retries, transient errors get a bounded few, and ambiguous errors accepted-then-dropped-response get no automatic retry at all. They go to review, because retrying them is how you pay twice for one effect. Stopping is only half the design. The landing matters just as much. An over-budget run lands in review carrying three things: what it spent model calls, tokens, downstream calls , where it stopped iteration count, last key processed , and what remains rows not yet attempted, with their keys . Without the stopping point, review cannot resume — it can only restart, which re-spends everything the run already spent. Without the spend record, nobody can answer the only question the invoice asks: which run, which node. The same rule applies to the workflow itself: if one workflow trips its budget several times in a short window, pause its trigger. A budget that keeps tripping is not a run problem, it is a config problem — a cap set wrong, an input that grew, a downstream price that changed. Auto-resuming into the same condition just converts paused rows into spent money on a schedule. A budget nobody has tripped is decoration. Before a workflow goes live, I run it against a small dataset with a mock billed downstream and a deliberately tiny budget, and assert three things: the run actually stops at the cap, it actually lands in review with spend and stopping point attached, and resuming from the stopping point does not re-bill the rows already processed. If any of those three fails, the budget is not a guard — it is a comment with better syntax. The numbers themselves stay adjustable and auditable: caps live in one config, changes to them are logged, and the per-run spend record is what makes an anomalous bill traceable to one execution and one node instead of a month of shrugging. The rule I keep coming back to: a workflow without a budget is a blank check signed by whoever deploys it. Put the ceiling in before the first real run, not after the first real invoice. Free workflows from this series MIT : https://github.com/zhp910318/n8n-ai-automation-lab https://github.com/zhp910318/n8n-ai-automation-lab The production templates in my store: https://payhip.com/haopengailab https://payhip.com/haopengailab