An execution's page is the whole record of a run. Six things are stored, and knowing which answers which question saves most of the guessing.
One row per method your flow declared, in the order they ran. Each carries:
RUNNING, SUCCEEDED, FAILED or WAITING_RERUN;This is why a flow of five small steps debugs far more easily than one method that does everything: the recorded boundary between steps is also the boundary of what you can inspect.
A step's result is also readable from later steps in the same run, with
this.getResult("stepName").
Every line written with this.log(level, message, meta), attributed to the step that wrote it,
with the structured meta alongside.
console.log and friends are captured too, but without step attribution — they land in the
run's output rather than against a step. When you are trying to work out which step misbehaved,
that difference is the whole point of using this.log.
What the run produced: the last step's return value, or the value passed to exit() or
cancel(), which override it.
When a run fails, the failing step holds the error. A failure with no step context — a boot failure, a worker crash, a timeout — is recorded on the execution itself instead, which is how you tell "step three threw" from "this never got as far as step one".
Every run points at the event that started it: the webhook delivery, the schedule firing, or the published event, with its payload and metadata.
Because one event can start several runs, this is also how you get from "this delivery arrived" to "and here is everything it ran".
Anything the flow published with this.emit() is listed on the run, so a cascade can be followed
forwards — this run, the events it produced, and the runs those started.
A replay re-runs a finished execution against the same recorded event, in the same deployment, inheriting its version and limits. It is a new execution, linked to the original as its parent.
You can scope it: start at a step, stop at a step, or name a subset. Re-testing the step that failed without paying for the three before it is the normal use.
You can also override the retry count for that one replay, without touching the deployment.
Three replays are refused, each for a reason worth knowing:
| Refused | Why |
|---|---|
| A test run | It ran draft source; replaying it would run the published version with draft results cloned in |
| A held delivery | The original still runs when the backlog is released — replaying would double it |
| A run with no deployment | There is nothing to re-enter |
If the deployment is switched off when you replay, the replay is held like any other delivery.
The executions list filters by status, deployment, flow and time. Two filters do more work than they look like they do:
HELD shows exactly what is waiting on a switched-off deployment.From the CLI:
konnecthub runs # recent executions
konnecthub inspect <run> # a summary-first post-mortem of one