Hey everyone — I’m Babar, I built OpsVeritas after realizing n8n has no native alerting for silent failures.
What it does:
-
Polls your self-hosted or cloud n8n every 3 minutes
-
Detects failed and stale workflows instantly
-
Alerts via Slack, email, or Teams before your clients notice
-
Shows uptime %, MTTR, run history, and audit log in one dashboard
-
Works alongside Make, Zapier, GitHub Actions, and AWS Step Functions too
If you’re running n8n for clients, one broken workflow can cost you a relationship. OpsVeritas is the monitoring layer n8n doesn’t have built-in.
Free 1-year beta: app.opsveritas.com
Happy to answer questions or take feedback from this community!
1 « J'aime »
The stale workflow detection is the part that fills a real gap - n8n’s built-in error handling catches hard failures, but a workflow that runs successfully but processes 0 records (or stops triggering) is invisible without external monitoring. Does OpsVeritas distinguish between a workflow that ran and returned 0 results vs. one that just stopped executing entirely?
This is exactly what Pulse handles — it actually
distinguishes between both cases:
-
Workflow ran but returned 0 results → detected
via historical baseline comparison (silent failure)
-
Workflow stopped executing entirely → detected
via schedule drift monitoring (missed execution alert)
Both trigger different types of WhatsApp alerts with
AI-powered explanations of what likely went wrong.
Happy to share more if you’re curious.
That distinction is exactly the right split - combining baseline comparison with schedule drift monitoring catches both failure modes cleanly. The AI-powered explanation layer on top of the WhatsApp alert is a nice touch, especially for teams where the person receiving the alert isn’t the one who built the workflow.
That split is the important one: hard failure, stale workflow, and “successful” run with the wrong business outcome are three different failure modes.
The next layer I would add is what happens after the alert fires. In production, especially for client workflows, I would want each alert to carry:
- Workflow and client affected.
- Failure class: hard error, no-run/stale, zero-result, or bad-output validation.
- Dedupe key so one cascade does not create 40 separate incidents.
- Owner and severity.
- Last known good run and expected next run.
- Resolution note once fixed.
That turns monitoring from “we got a WhatsApp/Slack alert” into an operating record. The alert catches the failure; the issue/resolution trail is what lets you prove later what happened and what changed.
Congrats on shipping, Babar — this failure class deserves way more attention than it gets, and the every-3-minutes polling + stale-workflow detection covers the two loudest versions of it.
Question from someone who builds client-facing report workflows: how do you handle the third class — runs that finish green but produce empty/wrong output? Example: a source API soft-fails (200, zero rows), the workflow “succeeds,” and an empty report goes to a client. Execution-status polling can’t see that one, since n8n itself reports success. I currently handle it by having each workflow log row counts to a sheet and validating output shape with a separate watcher — clunky, but it catches the cases that hurt most with clients.
Rory’s point above about alerts carrying failure class + last-known-good is spot on. Is per-run output validation (expected counts/ranges per workflow) on your roadmap, or do you see that as fundamentally the workflow author’s job rather than the monitoring layer’s?
The failure taxonomy Rory outlined in post 5 is the right starting point: hard error, no-run, zero-result, and bad-output validation each need a different detection path. There is a fifth state worth adding: correct output structure, non-zero count, but declining volume over time.
A workflow that processed 80 records last week and processes 12 this week has not failed by any standard check. It runs. It returns data. The error trigger does not fire. The schedule drift monitor reports on time. The zero-result alert does not trigger. But something upstream is changing: a data source is degrading, an API is rate-limiting, or a pipeline feeding this workflow has started dropping events.
Volume baseline detection closes this gap. After the main processing nodes, a Code node logs the output item count to a monitoring tab in Sheets: one row per execution with workflow_id, timestamp, and item_count. On each run, query the last 14 rows to calculate a rolling average. If the current count falls below 60% of that average for two consecutive runs, trigger an alert.
The two-run filter avoids false positives from legitimate one-off low-volume days. The 60% threshold is a starting point; a workflow with highly variable volume may need a wider window or a different method.
This is the early warning before the cliff. A zero-result alert fires when the workflow is already failing. A volume baseline alert fires while it is still passing, leaving time to investigate and correct the upstream cause before impact.
It also fits the alert enrichment Rory described. “volume_anomaly” as a distinct failure class from “zero_result” routes differently: zero result needs immediate remediation; volume anomaly needs investigation first, since the cause is usually external data quality, not the workflow itself.