WorkflowRadar

Feature

AI root-cause analysis on Monday-morning failures.

The 'why is this failing' triage that used to eat your first hour. WorkflowRadar reads the recent failure history, the failing node, the node-level data flow, and the dependency context — then writes a short root-cause + remediation summary.

The triage that takes too long

Monday morning. The client Slack channel has three error notifications from over the weekend. Each one says some variant of "Workflow failed: HTTP node returned 500". Useless.

You open the n8n executions view, scroll to the failing run, expand the failed node, read the error message, check whether the node has changed lately, check the dependent workflows that might be affected, check whether the same workflow has been failing intermittently or just this once. Forty minutes per incident, three incidents, two more clients with their own backlogs. The morning's gone.

What AI diagnosis does

When you open a failing workflow in WorkflowRadar, the detail drawer has an AI diagnosis card at the top with 3–4 sentences: what's most likely wrong, why we think so, and the first remediation step. Below it: links to the recent failures it looked at and the upstream dependencies that might be the real source.

The model gets four things as input:

  • The last 5 failed executions: sanitized error message, error class (auth / timeout / rate-limit / validation / unknown), the failed node name, and execution duration.
  • The workflow shape: node types and parameter paths (never values), so the model can reason about what the workflow is trying to do.
  • The dependency context: parent workflows that call this one, and child workflows it calls — including whether any of those are also currently failing.
  • Node-level data flow: per-node in → out item counts plus the field names present in the output. Schema only — never the values themselves. This is what lets the model spot the "node X received 247 items and emitted 0 with no error" case that silent failure detection flags.

Fallback when the LLM is unavailable

Anthropic outage, rate limit, your API quota exhausted — we don't leave you with an empty card. A rule-based diagnostician runs as fallback: it pattern-matches the error class and the failing node type and produces a shorter, less nuanced summary. Coverage isn't as deep, but every failing workflow always has some diagnosis attached.

How secrets stay out

Before any error message reaches the LLM, it passes through our sanitizer. Stripe keys, JWTs, AWS access keys, GitHub tokens, bearer tokens, long hex strings, emails, UUIDs, and URL paths are all replaced with placeholders. Parameter values from your workflow nodes are never sent — only the node type and the parameter path. Read the security page for the full list.

Refresh on new failures

If a workflow fails again after we've already generated a diagnosis, the cached one gets marked stale and the next sync generates a fresh one. The diagnosis you read in the dashboard is always based on the most recent failure data.

Available on

AI diagnosis is part of the AI add-on. Free for the first 60 days of any paid tier — see pricing for details.