Appearance
Run history
Every time a flow runs, FlowRunner records what happened — the method, how long it took, whether it succeeded, and a node-by-node trace. Run history is your flight recorder for debugging automations after the fact.
What gets recorded
A run is saved automatically at the end of every execution. Each record holds:
| Field | Meaning |
|---|---|
| When | The time the run finished. |
| Status | OK if the flow completed, Failed if a node failed and no End was reached. |
| Method | The HTTP method that triggered it — GET, POST, … — or CRON for a scheduled run. |
| Duration | Total wall-clock time in milliseconds. |
| Failed node | For a failure, the id of the node that failed, plus the error message. |
| Node trace | One line per node that ran: its name, component, the port it chose, its duration, and any error. |
Recording is best-effort by design — if saving a record ever fails, it's silently dropped rather than breaking or delaying the run it was trying to record. Your live endpoint always takes priority over its own logging.
The run-history dialog
Open Run history for a project to see its runs in a table, newest first. Each row shows the when, status, method, duration, node count, and a one-line detail:
- A successful run shows the path it took — the node names joined with arrows, e.g.
Start → If → Send email → End. - A failed run shows the error message and the node it failed at, e.g.
http: fetch failed @ node_a1b2c3.
Expand any row to reveal the full node trace: a green or red dot per node, its name and component id, the output port it chose, and its individual duration. That's usually enough to see precisely where a run diverged or broke.
INFO
📸 Screenshot — the Run history dialog with one failed row expanded to show its per-node trace.
A Refresh button re-loads the list so you can watch runs land as you test. History is available to anyone with viewer access to the project or higher.
Scheduled runs appear too
Runs that fire on a cron schedule are recorded in exactly the same history, tagged with the method CRON instead of an HTTP verb. So a flow that's both called over HTTP and run on a timer shows both kinds of run interleaved — handy for confirming a nightly job actually ran, and succeeded, without anyone watching.
TIP
If a scheduled flow is misbehaving, run history is the first place to look: a CRON row with a Failed status and an expanded trace tells you which node broke and why, even though no one was there to see the request.
Retention
Runs are kept for 30 days and then removed automatically. Retention is enforced by the database itself, so old records age out without any manual cleanup. If you need a permanent audit trail beyond that window, capture what you need from the trace (or from the per-request log line the server emits) before it expires.
NOTE
Thirty days is plenty for day-to-day debugging. For long-term analytics, export or forward the runs you care about to your own store rather than relying on history as the system of record.