[ get started ]

Try it first.Sign up later.

The core of Insight, a failed execution in and a calibrated diagnosis out, works without an account, from your terminal or the web. Signing in is only for connecting an instance so future failures are caught on their own.

From your terminal

no install, no account

$ npx insight-n8n demo

That diagnoses a bundled sample failure so you can see the whole thing work. Then point it at one of your own. Node.js 18.17 or newer is all it needs; it has no dependencies.

your own failure

$ npx insight-n8n diagnose execution.json$ npx insight-n8n diagnose --id 4821 --url https://n8n.example.com

Secrets are redacted on your machine before anything is printed or sent. Where the diagnosis itself runs depends on whether you have a Groq key (free, about a minute at console.groq.com):

Where the CLI runs a diagnosis
Engine	When	Who sees what
local	GROQ_API_KEY is set, or --local	Groq, with the redacted summary
hosted	no key, or --hosted	Insight's pipeline, with the redacted execution

The local engine re-implements the pipeline in under a thousand lines with no dependencies: redact, short-circuit transient failures, one model call with the execution framed as untrusted data. It doesn't retrieve from the knowledge base, which is switched off on the hosted side too for now.

Get the execution

Insight needs the execution with its run data: every node's input and output, not just the error. The CLI's --id fetches it for you. To save it as a file instead:

n8n public API

$ curl -H "X-N8N-API-KEY: $N8N_API_KEY" \$   "https://n8n.example.com/api/v1/executions/4821?includeData=true" > execution.json

The execution id is in the URL when you open a failed run in n8n's Executions list. Create an API key under Settings, n8n API. The CLI also reads the raw format n8n keeps in its execution_data table.

On the web

The diagnose page takes the same file as an upload, or an execution id with your instance's public HTTPS URL and an API key. The key is held in memory for that one request and not kept.

Monitor an instance

Sign in with GitHub or Google, then connect your instance with its base URL and an API key.
Insight lists every workflow on it and marks which ones are already monitored.
Click + Add workflow on the ones you want protected. Insight installs and activates its error-workflow template and points that workflow's Error Workflow setting at it.
The next failure is diagnosed on its own, logged on your dashboard and sent to Slack.

Rather not grant write access? Import the template yourself from the repository's workflows folder and paste in your ingest token. The result is the same, minus the automation.

Commands

insight-n8n commands
npx insight-n8n demo [sample]	Diagnose a bundled failure: shape-changed, auth-expired, jwt-dropped-binary, transient-timeout.
insight diagnose execution.json	Diagnose an execution from a file. Use - to read stdin.
insight diagnose --id 4821 --url …	Fetch the execution from your instance first. The key is asked for, hidden, if N8N_API_KEY isn't set.
insight inspect execution.json	Node trace, error, the failing node's input and what was redacted. No network at all.
insight redact execution.json	Print the redacted JSON that would be sent, to check it by eye.
--json	Machine-readable output, for scripts and CI.

Installed globally with npm install -g insight-n8n, the command is insight.

If it breaks

The execution was fetched without its run data. Add includeData=true to the API call, or use insight diagnose --id, which does it for you.
The hosted pipeline allows 5 diagnoses a minute per address, because it shares one Groq quota with everyone. Wait a minute, or set GROQ_API_KEY and run it on your own quota.
The website can't reach it, on purpose: it refuses internal addresses. The CLI runs on your machine, so insight diagnose --id 4821 --url http://localhost:5678 works.
The error matched a timeout, connection reset, rate limit or gateway error, so no model was asked. Re-run the workflow. If it keeps failing the same way, it isn't transient, and a diagnosis of the next failure will say more.
Then Insight couldn't see the cause directly in the data. Read the explanation as a lead. Silent problems like a wrongly nested setting often only show up one or two nodes later.
n8n only runs an Error Workflow that is itself active, and Insight has to reach your instance from the internet to fetch the execution. Check that “Insight - Error Workflow Template” is active and your instance has a public URL.

Running the website yourself

terminal

$ git clone https://github.com/jabluetooth/insight insight$ cd insight/frontend$ npm install$ cp .env.example .env.local$ npm run dev