Run a flow & debug failures

Running flows, reading the graph as it lights up, and tracing a failure down to the exact request and response.

Running

With an .aether file active, press ⌘⏎, hit F5, or click the brass ▶ Run button in the toolbar. The run uses your full variable stack — the selected environment, .env, flow variables, captures, and any local overrides (how those layer).

You can also run without opening a flow: right-click flows in the File Explorer and choose Run (Cmd/Ctrl-click to select several, Shift-click for a range), or press ▶ on any card in the Flow Map view.

The pre-run guard

If any node references a variable that has no value, the first press of Run doesn’t start a doomed run — it selects the first unresolved node, opens its Variables tab, and relabels the button Run anyway. Fill the value or press again to proceed.

Run from a node

Select a node and press ▶ From here (right edge of the node’s tab strip) to start the run at that node — everything before it is skipped entirely, so earlier captures and responses simply don’t exist for this run. Useful when you’re iterating on step five of a six-step flow and don’t want to log in every time. The same pre-run guard applies.

Stopping a run

While a flow is running, the ▶ Run button becomes ◼ Stop. Press it to cancel: any in-flight HTTP request is aborted, and the run ends as failed with the error cancelled by user — it lands in history like any other failed run.

Watching a run

  • Each node pulses while executing, then takes a green ring (passed) or red ring (failed).
  • Loop nodes carry a live iteration badge — 2/5 ticking up as the loop runs — which stays after the run so you can see how many iterations happened.
  • The Console (bottom panel, ⌘J) logs every step with timestamps; errors are red.
  • The status bar (bottom-right) shows Running…, then Completed or Failed.

When something fails

Work from the node outward:

  1. Click the red node. Its Result tab in the inspector is the ground truth:
    • Request — the exact method, URL, headers, and body that were sent, with every ${{ }} already resolved. Wrong URL? Missing header? It’s visible here, not hypothetical.
    • Result — the response status, headers, and body that came back. For a failed assertion, compare the body against your check.
  2. Check the variables it consumed. The node’s Variables tab shows each reference, its source, and its value (with a reveal toggle for masked .env values). A wrong captured value points you at the producing node — click the captured by badge to jump there.
  3. Check the run-wide picture. The bottom panel’s Variables tab is the full variable snapshot at the end of the run; Console has the sequence of events; History keeps every previous run for comparison (Execution history).
  4. For conditions — the Result tab states which branch was taken and why, so a flow that “skipped” a step usually explains itself in one click.

Try a quick fix without editing anything

Type a value into the override field in a node’s Variables tab and re-run. Overrides take highest precedence and live only on your machine — nothing changes in the file. If the fix deserves to stay, one click promotes it into the flow’s variables: block.

Fixing the flow itself

Edit the node in the inspector’s Node tab (or the Code tab), ⌘S, and run again. If the failure is your API having changed — moved paths, renamed methods, new required params — let self-healing compare the flow against your OpenAPI spec and propose the fixes.