n8n workflow monitoring: file check

For n8n workflow monitoring, a successful execution is not enough to confirm delivery. Our file checker rejected a missing result and a leftover result from a previous run. It accepted an empty result when that file belonged to the expected run.

The distinction is practical: did the workflow start, did it fail, and did it leave the result its consumer needs? Our downloadable example answers the last question for one explicit JSON-file contract. It does not run n8n or send alerts.

An n8n workflow monitoring template already checks empty runs

The community workflow listed on n8n inspects execution data and item counts. Its settings include min_items = 0 for workflows that may legitimately return nothing. You do not need a new “empty output” rule simply because a successful run looks suspicious.

A file consumer has a narrower question. An execution can contain items while the expected file is missing or left over from an earlier run. Our example checks the file itself and its declared run ID. It is an additional result check, not a replacement for the community workflow.

A heartbeat is evidence of activity. It does not, by itself, tell a downstream reader whether its file exists. We have not tested the service illustrated in that post.

A run ID catches a file left behind yesterday

Download the Python file checker. It uses only Python’s standard library, performs no network requests and installs nothing. Its contract is deliberately small: the file must be a JSON object with the expected run_id and an items list. The list may be empty.

Save this as result.json and run the check from the machine that can read it:

{"run_id": "current", "items": []}

python3 RB02-check-output.py result.json --run-id current

This example returns {"ok": true, "reason": "valid_empty"} with exit code 0. A file containing "run_id": "previous" returns wrong_run with exit code 2. Existing bytes are no longer enough to pass.

We executed all seven cases as separate command-line calls. This is a reproducible local file check, not measured n8n error coverage, Slack delivery or a test of every item’s contents.

Use a new run ID for every real execution. The word current is a fixed demonstration value, not a safe reusable production identifier: reusing it could let yesterday’s file pass.

Keep the result check separate from the error workflow

n8n error workflows respond to execution failures. A schedule monitor such as Healthchecks can reveal a missing start. Neither automatically supplies the business contract for your result file.

In an August n8n Community discussion, contributor runtimegap reported a video upload that succeeded while tags from a job file did not reach YouTube correctly. That is their account, not a test we repeated. Our JSON check would not establish that tags arrived either. Read the result back at the destination when that outcome matters.

We favour an explicit result check, but it must match the output. This JSON example cannot validate an MP4 or prove that a URL inside an item downloads correctly. For n8n video automation, the final media needs its own format and delivery checks. The n8n import checklist covers other setup risks.

For automation that hands files to another step, connect the check to the result that consumer actually needs. The daily video-workflow guide concerns the wider pipeline; a green intermediate step should not stand in for its final output.

Test one expected JSON result with the correct and the previous run ID before connecting the check to a scheduler. This standalone command does not alert anyone. At the next real run, verify the result at the consumer’s location; only then decide how a failed check should reach the person responsible.