Debugging

Error highlighting

During a run, the node that threw the error is highlighted directly on the canvas, with the error message shown right next to it. Everything upstream of it already ran successfully; everything downstream never started.

Inspecting inputs & outputs

Click any node from a completed run to see exactly what it received and what it produced. This is usually enough to tell whether the problem is a misconfigured node, unexpected upstream data, or a genuine failure from an external service.

• • Node configuration at the time it ran
• • Input data received
• • Output data produced (if it succeeded)
• • Runtime logs and the error message (if it failed)

Reading execution logs

Every node emits its own log lines as it runs, each with a severity level, a message and optional detail data. Logs are attached to the run itself, so you can come back to a past execution and read exactly what happened, step by step.

Sensitive data stays masked

Fields that look like credentials — passwords, tokens, secrets, API keys, authorization headers — are automatically replaced with ●●● wherever they would otherwise appear in logs. You get full visibility into what happened during a run without ever exposing secrets in plain text.

Example: a failing "Create Order" run

Same workflow as in Workflows, but this time the SQL node's connection variable is missing:

1. API Endpoint   ✓  received { "sku": "TSHIRT-M", "qty": 2 }
2. Validation     ✓  body matches schema
3. SQL            ✗  connection failed: DATABASE_URL is not set
4. Response       —  never ran

Run failed at step 3 — 2/4 nodes succeeded

The SQL node is highlighted directly on the canvas with the message above. Clicking it shows the input it received (the validated order) and the runtime error — enough to spot that the Environment Variable for the database connection was never set, without reading a single log line by hand.