Automations
Testing & Runs
Test your automation safely, watch every block run live, inspect each result, and retry from the exact step that failed
Testing an automation is like a dress rehearsal: same stage, same script, and you're in the audience watching every move — so opening night holds no surprises. Test Run in the canvas toolbar starts one, and what happens next depends on your trigger.
Starting a test
| Trigger | What Test Run does |
|---|---|
| Manual | Opens Run with input, filled in with the automation's demo data. Change any value for this run only — to keep a change, save it as the demo data in the trigger settings. |
| App trigger | Opens a chooser. With demo data saved, Use the demo data comes first: it shows the data, editable, and Run with this data starts right away. The second option is Wait for a real event (the run starts the moment the app sends one) — or, for apps Nirvai checks on a timer, Fetch the newest event (it pulls the latest one right away). Without demo data, that second option comes first. |
| Webhook | Waits for the next request sent to your webhook address, and runs with it. The demo data here fills the variable picker; it does not replace the real request in a test. |
| Schedule | Runs immediately, as the timer would — steps that read trigger data get the demo data |
Capturing a real event while you test an app trigger also saves it as the demo data, so your next test can replay it instantly.
The live view
The canvas becomes a stage: blocks light up one after another as they run, branches not taken are dimmed with the reason ("skipped: condition was true"), and loops animate while their passes run. You can stop a run in progress from the toolbar. Watch the run below play out, then click any block to inspect its result:
12 items in → 3 kept
Inspecting a step
Click any finished block to see exactly what it did — each type shows its own story:
| Block | You see |
|---|---|
| Filter | How many items came in, how many survived, and the survivors |
| Condition / Switch | The verdict and which path the run took |
| Tool | The tool, the fields it ran with, and any "value resolved to nothing" warning |
| Database | The action, the database, and the exact rows affected |
| Any block handling files | One note per file — e.g. "invoice.pdf: attached (96 KB)" or "photo.jpg: temporary public link created (expires in 7 days), converted to JPEG" (Files in Automations) |
| Code | The result and anything the code printed |
| For Each / Loop | Pass-by-pass results with a pager |
| Agent | The full conversation and its answer |
Every step also shows what it received as input, and every list can flip between a table and raw view. Free blocks carry a "No credits" chip.
Retry from a step
When a run fails, you don't start over. Retry from failed step (or "Retry from this step" on any block) starts a new run that reuses everything upstream — earlier agent steps are not re-run and not re-billed — and re-executes only from the failure onward. Fix the block's settings first, then retry.
This is the cheapest debugging loop there is: an expensive research step that succeeded stays paid-for once, while you fix and retry the cheap step that broke after it.
Activating and monitoring
Once a test looks right, flip the activation switch. From then on:
- Runs appear in the automation's run history, each opening the same live view and step inspection.
- Run statuses: completed, failed (with the failing step marked), stopped (you halted it), in progress.
- Events an app sent but a filter dropped don't create runs — that's by design and costs nothing.
Troubleshooting
| Problem | Fix |
|---|---|
| A step's output is empty | Open the step and look for the "resolved to nothing" warning — a {{variable}} didn't find its value. Check its path in Data Between Steps. |
| Blocks after a failure show "skipped" | That's the rule: when a step fails, everything depending on it is skipped and the run is marked failed. Fix the step, then Retry from failed step. |
| "Wait for a real event" never starts | Cause the event in the other app (create the deal, send the form). The window waits for a real delivery. |
| An old run shows less detail than new ones | Older runs were recorded before the richer per-block views existed — new runs show everything. |
What's next
Protect your working build with Versions & Safety.