RunVouchGet a free key

Field notes · 2026-09-14 · RunVouch

n8n AI workflows: catch the failures your Error Workflow never sees

n8n's Error Workflow only fires when a node errors. Catch missed schedules, green runs that did nothing, and AI cost per run with two HTTP nodes.

I have learned not to trust the n8n executions list, even though it is the most reassuring screen I know. For two years I ran agents and a crypto trading bot unattended, and a fair share of the glue around them lived in n8n. Red executions always reached me, because I had an Error Workflow. The bad weeks were the ones where the list was green, or empty, and nothing told me which.

RunVouch is a dead man's switch, cost cap and outcome check for unattended AI agents and workflows. Every run reports a start and an end, and you get an alert when a run is missed, stalls, fails, finishes without evidence or costs more than you allowed.

What the n8n Error Workflow catches, and what it never sees

The Error Workflow is a good tool, but it only does one narrow job. The Error Trigger docs say it plainly: "The Error Trigger only runs when an automatic workflow errors." A node has to throw and the execution has to fail. The other way in is a Stop And Error node, which the n8n guide on handling errors gracefully describes as the way to force an execution to fail under conditions you choose.

Anything that does not fail an execution slips past it. Every node has an On Error setting that can continue instead of stopping (node settings). A community post, "The n8n failures your error workflow will never catch", spells out what that means: "Any node with onError: continueRegularOutput will complete and mark the execution green." That post comes from someone selling a monitoring dashboard, and so does this article. Check the mechanism against the docs, not the pitch.

Why an n8n workflow fails silently: three cases with no failed execution

1. The Schedule Trigger stops firing. If there is no execution, nothing can fail. In an n8n Cloud thread from February 2026, no scheduled executions showed up in the log at all, while manual runs worked. Turning the workflow off and on again fixed it. In a self-hosted thread from July 2026, on Kubernetes in queue mode, schedules stopped after several days while the workflow still showed as active. The scheduler failed before any execution was created, and the only trace was in the container logs. An Error Workflow cannot run for an execution that does not exist.

2. The run is green and did nothing. The thread "The silent failure: when your n8n workflow succeeds but does nothing" lists the usual patterns: a "no items" branch that just ends, an HTTP request that gets a 200 while the API behind it failed, a Set node that drops the field you needed, a batch loop that exits early. Mine was an hourly enrichment workflow whose upstream list had quietly gone empty. Every execution succeeded. The sheet stopped growing.

3. The run worked and cost too much. High cost is not an error. An AI node inside Loop Over Items sends its instructions again on every iteration. In one community measurement on a 400-row classification job, batching 10 rows per call cut input tokens from 90,400 to 11,920. The unbatched version is not broken. It is green, and it uses about 7.6 times the input tokens on every run.

Two HTTP Request nodes: a start and an end for every n8n run

The fix for all three is the same. Stop asking the workflow to report its own failure, and have something outside n8n expect each run. First, register the workflow once, with the same cadence as its Schedule Trigger:

rv agent lead-enricher --cadence 1h --cap-run-cost 0.50 --cap-day-cost 5 --evidence

Then add two HTTP Request nodes, both using a header credential that sets X-API-Key:

# node "RunVouch Start", right after the Schedule Trigger
POST https://api.runvouch.com/v1/runs/start
{"agent": "lead-enricher", "source": "n8n"}
# answers {"run_id": "..."}, or {"paused": true, ...} after a crossed cap

# node "RunVouch End", at the end of the branch that means done
POST https://api.runvouch.com/v1/runs/end
{
  "run_id": "{{ $('RunVouch Start').item.json.run_id }}",
  "status": "ok",
  "cost": {{ $json.cost_usd }},
  "tokens": {{ $json.total_tokens }},
  "evidence": {"rows_written": {{ $json.rows_written > 0 }}}
}

Each case above now has a detector:

If you would rather not keep an API key in n8n, every agent also has a ping URL. Call https://api.runvouch.com/ping/<token>/start at the top, https://api.runvouch.com/ping/<token> at the end, and /fail on an error branch. The token can only report runs for that one agent. There is also a community node, n8n-nodes-runvouch, if you prefer a node to raw HTTP. Either way, set the RunVouch nodes to On Error: Continue. If RunVouch is unreachable, you lose monitoring for one run, and the run itself still goes ahead. It is the one place where I want Continue switched on.

n8n AI cost per workflow run: getting the number into End Run

This is the part n8n does not make easy. A feature request from August 2026 explains why. The Chat Model sub-node records tokenUsageEstimate with promptTokens, completionTokens and totalTokens. But the sub-node is attached through an ai_languageModel connection, and expressions can only reach nodes on main connections. You can see the numbers in the execution view, but your next node cannot read them.

That request also describes the workaround. Call the n8n API for the current execution with includeData=true and read the Chat Model node from runData. This needs an API credential, and execution progress saving has to be switched on. The Token Estim8r workflow from the community does the same from a separate workflow. Then a Code node multiplies the tokens by your model's price, and End Run receives cost and tokens.

Once each run reports its cost, the caps take care of the rest. If a run goes over --cap-run-cost, or a day goes over --cap-day-cost, you get BUDGET_RUN or BUDGET_DAY in Telegram, Slack or a webhook, and the agent is paused. RunVouch never stops an execution that is already running. Instead, the next Start answers {"paused": true} rather than a run id, so an IF node after Start ends the workflow. The loop that cost too much at 09:00 does not run again at 10:00 until you have looked at it. n8n calls the token field an estimate for a reason, so treat a cap as a tripwire, not as accounting.

Keep the Error Workflow, stop trusting its silence

I did not remove a single Error Workflow. It is still the fastest way to find out which node broke and why. What changed is how I read its silence. No message only means no node threw. It does not mean the schedule fired, the rows arrived or the bill stayed small. You only learn those from something outside n8n that expects the run.

RunVouch is free for up to 20 agents. Solo costs $9 and Team costs $29. It is MIT licensed if you want to self-host, and the hosted version runs in the EU. Details at runvouch.com.

FAQ

Does the n8n Error Workflow run when I execute a workflow manually?

No. The Error Trigger docs say you cannot test error workflows by running workflows manually. It only runs when an automatic execution fails.

How do I get alerted when an n8n Schedule Trigger stops firing?

You need a check outside n8n. Report a start at the top of every run, with an HTTP Request node or the ping URL, and register the expected cadence. If no start arrives within the cadence plus grace, MISSED fires, whatever the cause.

Can RunVouch stop an n8n workflow that is burning tokens?

Not while it is running, and that is on purpose. A crossed cost cap sends an alert and pauses the agent. The next Start returns paused, and your IF node skips the run. Killing a workflow halfway through its writes would be a failure of its own.

Related field notes

Try it: free for 20 agents · Docs: Claude Code · cron