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, … — `CRON` for a scheduled run, or `FORM` for a form submission.
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.
Node output	For a failed run, the value each node produced (bounded and secret-redacted) — so you can see the data that led to the break, not just where it broke.

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. For a failed run, each node also shows the value it produced — so you can trace the data forward and see exactly what the failing node was handed. Outputs are bounded (a large payload is truncated) and secret-redacted, and are kept only for failures to keep history lean.

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.

Failure alerts

Checking run history only helps if you think to look. So a flow that quietly starts failing at 3am — a scheduled sync, a webhook — can go unnoticed for days. Failure alerts close that gap: turn them on and FlowRunner emails you when a run fails.

In the Run history dialog, toggle “Email me when a flow run fails” and enter an address. From then on, any failed run — scheduled, endpoint, or form — triggers an alert. The email names the project, the failure count since the last alert, and the most recent error and node.

To avoid an alert storm from one persistently broken flow, alerts are coalesced behind a 15-minute throttle: at most one email per project per window, summarising everything that failed in it. Enabling alerts only counts failures from that moment on — it never dredges up historical ones.

NOTE

Alerts are delivered by the same scheduler tick that runs schedules and digests, so they need the tick wired up and email (RESEND_API_KEY) configured. Without the tick, failures are still recorded in history — you just won't be emailed about them. Alerts arrive within a minute or so of the failing run.

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.

Run history ​

What gets recorded ​

The run-history dialog ​

Scheduled runs appear too ​

Failure alerts ​

Retention ​

See also ​