The green run that did nothing

The failure

Every automation platform marks an execution successful when no step threw. That is the only definition it can have. It is also the reason the failure that costs the most in production is not the red run but the green one: a token expired and the API started returning an empty list; a field got renamed upstream and the filter now matches nothing; a tool inside an AI agent failed and the model filled the gap with a plausible guess. Every node is green. Zero records landed. The error workflow never fires, because from the platform's point of view nothing went wrong. On the n8n community forum this comes up weekly, and the honest answers in those threads are what these two pieces implement.

Piece one: a linter for the workflow JSON

n8n-workflow-lint is a zero-dependency command-line tool. Point it at an exported workflow and it reports where the workflow can fail without anyone finding out: no error workflow attached, HTTP nodes with no retry or timeout, errors swallowed by Continue On Fail with nothing downstream looking at them, an AI agent with tools whose output is trusted blindly, IF branches that drop items on the floor, secrets pasted into parameters, unauthenticated webhooks. Fifteen rules; every one cites the forum thread it exists because of.

We ran it over the 400 most-viewed public templates on n8n.io:

Templates are starting points, not production, so that is not a criticism of their authors. It is a measurement of how much hardening sits between "works in the editor" and "runs for a client for a year", and it is the gap a client is paying for when they hire someone to do this properly.

Piece two: the runtime half

Static analysis can say where a workflow can fail quietly; it cannot say that it is. The Production Hardening Kit is four importable workflows for that side, with no external monitoring service:

• Error Router. One shared error workflow for the instance. It fingerprints each failure by workflow, node and message and sends one Slack alert per fingerprint per thirty minutes with a running count, instead of sixty pings from a schedule hammering a dead API. Sixty pings is how a channel gets muted, and a muted channel is how the next real failure is missed.
• Assert Outcome. A sub-workflow called right after any write with the count of what was written and the range that is plausible. Outside the range, it fails the calling execution, so the router hears about it like any other failure. Run status becomes outcome status.
• Execution Auditor. Hourly, read-only, through the n8n API node. It flags streaks of consecutive errors nobody opened, windows in which nothing succeeded, and the "fast-green" shape: hundreds of successful runs that each took 25 milliseconds while the only runs that took real time all failed. Those green runs were falling through an IF before the expensive part. Nothing but the execution list can show that, and the execution list is a page you have to remember to go and worry at.
• A worked example. The fetch-and-append every tutorial shows, with all of the above applied.

What it says about how we work

The pattern in both pieces is the same one that runs through the reference builds: define what "done" means in terms the system cannot fake, check it at the point where the work happens, and make the failure loud and deduplicated. Automation that cannot tell you when it has stopped working is a liability with a green dashboard. If yours is a few dozen workflows nobody has audited since handoff, that audit is a one-week engagement and the two repositories above are its first two tools.