The Workflow That Wouldn't Stop Spending: Putting a Budget on Every n8n Run
Description and use
Implementing pre‑run budgets in n8n stops runaway spending, provides clear audit trails, and enables safe resumption without re‑billing.
Problem
Unbounded n8n workflows can silently consume money through repeated model calls, unbounded pagination, and retries that trigger billed downstream actions.
Outcome
Implementing per‑run budgets in n8n stops runaway spending, provides clear audit trails, and enables safe resumption without re‑billing.
Workflow
- 1. Define budget parameters (max iterations, max rows, max LLM calls/tokens, per‑node timeout).
- 2. At run start, check budget against current state; if exceeded, abort and record spend and stopping point.
- 3. During execution, enforce limits: cap iterations, cap rows admitted, batch LLM calls where possible, and apply retry budgets per error class.
- 4. If a limit is hit, stop the run and move it to review with detailed spend, stopping point, and remaining rows.
- 5. Review can resume from the stopping point without re‑billing processed rows.
- 6. If a workflow repeatedly hits its budget, pause its trigger and audit configuration.
- 7. Test budget on a small dataset with mock billed downstream and tiny budget before production launch.
- 8. Log budget changes and per‑run spend records for traceability.
Evidence
A runaway n8n loop does not announce itself with a performance problem. It announces itself with a bill.
I now put a budget on every run before it starts, not after the invoice arrives.
Stopping is only half the design. The landing matters just as much.
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.
- Record date: 2026-11-02T23:13:54.966Z