n8n’s error workflow feature is genuinely good — I had one wired up for a client’s order-sync workflow. Problem was, I also had a couple of Zaps and a Make scenario doing similar glue work for other clients, and the error workflow only ever told me about n8n. It never occurred to me to check it more often because I assumed “no alert” meant “nothing’s wrong,” until a client emailed asking why orders had stopped syncing three days earlier.
Built Gnosis to fix that specifically: it polls n8n (and Zapier/Make) and puts every failure into one Slack stream, so I’m not relying on remembering to check three separate error workflows/dashboards. Free tier covers 5 automations: https://gnosis-automations.netlify.app
Curious how others here handle this when n8n isn’t the only platform in the stack — do you just keep multiple error workflows and check them manually, or is there a pattern I’m missing? Also happy to take feedback on rough edges, still early.
3 Likes
The “no alert = nothing wrong” trap is exactly why a centralized error stream matters - good call building this.
For the n8n-only pattern: I route all error workflows to a single shared “Error Collector” workflow (set it as the Error Workflow in each workflow’s settings). That collector normalizes the payload - pulling $execution.id, $workflow.name, the error message, and node name - then posts a single Slack message with all the context needed to drill in. No third-party polling needed. The limitation is it only catches n8n - which is exactly the gap your tool fills for mixed stacks.
One thing that would make Gnosis more useful: a severity filter or a way to suppress known flaky workflows that are already being handled, so the stream doesn’t become noise again.
1 Like
The Error Collector pattern is clean — appreciate you sharing it, might actually steal that normalization idea (execution.id + workflow.name) for how Gnosis formats its own alerts.
Severity filtering / muting known-flaky workflows is a great call and honestly the top piece of feedback I’ve gotten so far. Planning to add it. Quick question to help me scope it right: when you say “known flaky,” is that usually one specific node failing intermittently (like a rate-limited API call), or more like a whole workflow that’s flaky end-to-end? Trying to figure out if muting needs to work at the node level or just the workflow level for v1.
Update: shipped this. Automations can now be marked “known flaky,” which suppresses the Slack ping on failure while still tracking status/history and logging that it was suppressed (so it doesn’t just silently disappear). Workflow-level for v1, per the reasoning above — Gnosis only sees platform-reported run status per automation, not per-node, so that’s the granularity it can actually act on.
Thanks again for pushing on this, it was the clearest actionable feedback I’d gotten on the post.