Monitor runs and traces

When a run fails — or you just want to see what happened — this page shows you how to read its history, diagnose the failure step by step, and open the full execution trace. Every workflow run is recorded with its logs, output, and steps, and traced runs add a full execution trace showing everything Ronja did and where the time went.

Browse run history

Open the workflow — from its feature hub row, an exploration panel, or a link in chat.
Scan the Activity list: each row is one run, with a status dot, a one-line summary, who ran it, and its duration. Statuses: Running, Waiting, Continued, Success, Warnings, Failed. A run that is waiting on a person reads Awaiting approval instead of Waiting. Any chart or picture a finished run drew is shown under its row, alongside the download links for the run’s other files — you do not have to expand the row to see it.
Click a row to expand its inline log / output / details tabs.
Click Open full for the full run page — stat tiles (DURATION / TRIGGERED BY / RESULT / VERSION), tabs Output / Steps / Log, and the parameters used.

A run that succeeded can carry the amber Warnings from this run box too, so when a value in a run’s output is unexpectedly empty, open the run and check it — see Read a failed run for what its lines mean.

An automation’s run history uses the same list and adds two statuses of its own, neither of which a workflow’s own history ever shows. Skipped is a fire that ran nothing, usually because the workflow or Saved Agent it points at was already running, or because the automation was turned off, changed or deleted while Ronja waited to retry a workflow start — see A run that was Skipped. Sender refused appears only on an Email-triggered automation: mail arrived from a sender its allowlist does not name, so nothing ran and the sender’s domain is recorded. Neither is a failure. See When an email trigger turns a sender away.

Run history goes back 1 year. Older runs are cleared automatically, together with their logs — except that a workflow which pauses and continues is kept as a whole while its chain is still running, so a long-running pipeline never loses its earlier steps. See Limits and retention.

The AVG / SUCCESS / RUNS mini-stats cover recent runs, not lifetime history. A run that is still going — Running or Waiting — is left out of SUCCESS entirely rather than counted against it, and so is a Continued one (its successor is in the same list, and counting both would count one piece of work twice). On an automation a Skipped or Sender refused entry is left out too: nothing ran, so there is no outcome to count either way. That is why SUCCESS names the number of runs it was worked out over, which can be smaller than RUNS. A run that spent part of its life Waiting — on a timer, on a mid-run approval, or on an answer from a colleague — reports the whole time from when it started to when it finished, so a long wait shows as a long run and can lift AVG well above what the work itself took. That is expected, not a stuck job.

A run that is Waiting

Two kinds of run pause mid-way and pick up later on their own. Either sits at Waiting, with a steady blue dot rather than the pulsing one a Running run gets. (A third kind of pause waits for a person instead — see A run that is awaiting approval.)

A Durable workflow hands work to an agent, or waits until a given time, and stops there.
An agent — a saved Agent, or the agent an automation runs — decides it has nothing useful to do until something else finishes, and comes back to it. It might be waiting on a workflow it started, on another agent, or simply for a set amount of time.

In both cases nothing has gone wrong and nothing needs doing. The work already finished at that point is saved — files and tables written before pausing are on the run already — and Ronja restarts it by itself as soon as what it was waiting for happens. The steps that already ran are not repeated when it continues.

Where they differ is what you see when the wait ends. A paused workflow carries on in a new run entry, and the paused one is marked Continued — finished with, never a failure. Read the newer entry for the outcome; a workflow that pauses several times leaves a Continued entry for each pause, and the newest one is the live one. A paused agent simply carries on in the same run entry: it goes back to Running and then to its final status, so there is nothing extra to open.

The trace does not split like the run entries do. However many times a workflow pauses, the whole pipeline stays one execution trace — it sits at Waiting between pauses and shows one WORKFLOW RUN block per continuation, in order, on one time axis. So there is one row to find in the trace list and one timeline to read, whether the pipeline ran straight through or stopped nine times along the way.

Ronja gives up eventually rather than waiting forever. A workflow still waiting 14 days after it was due to continue is marked Failed with a message saying why — and so is one that has been pausing and continuing for more than about eleven months, however healthy each pause looked. An agent waits on a shorter leash — at most a day at a time, and no more than three days across a whole run — because a job that genuinely needs checking over days belongs in an automation on a schedule rather than in one long-running agent. See Limits and retention.

You will see Waiting on a workflow only if it uses durable execution and its author wrote it to wait for something; on an agent run, only when the agent decided waiting was the right thing to do.

A run that is awaiting approval

A Durable workflow can also stop part-way through and ask a person to decide before it goes any further — usually right before the step that does something consequential. The run stays Waiting, but its status reads Awaiting approval, and in the Steps tab the step it stopped on reads awaiting approval. Everything before that step is finished and saved; nothing after it has run.

This is how a workflow asks for sign-off: at one particular step, and only when it gets there — so the run works the same however it was started, from the workflow’s page, an app, or an automation. (A handful of older workflows instead carry a legacy Pre-run approval gate that stops every run before it starts; see Approval before a run.) The approver’s side of this is Approve a workflow run.

Decide on the run page

Open the run and a card sits above the run activity:

Read the headline — it is the question the workflow is asking — under the eyebrow Awaiting approval.
Check the context rows below it: the details the workflow put in front of you to decide on.
Note the deadline, shown as Expires in 6 days.
Add a note in Comment if it helps — “Add an optional note for whoever started this run…”. It’s optional.
Click Approve or Reject. A toast confirms it — Run approved or Run rejected — and the card keeps the decision, stated in full: You approved this on 21 Aug 2026 at 16:29 (or the decider’s name instead of “You”), the question underneath, then the comment. The context rows fold away behind a Details link once the decision is made — they are there for whoever has to decide, not for the record afterwards.

Who can decide

Named approvers — the people this decision was addressed to — see both buttons.
Admins can always decide, named or not.
Anyone else who can open the run can stop it but not let it through: the line reads Awaiting approval from {names} — you can stop this run, but not approve it. Where you can’t act at all it simply reads Awaiting approval from {names}.

A named approver who has no access to the workflow itself still gets the card, with a note saying so: You don’t have access to the rest of this run — only the approval above. You can decide the question you were asked without being given the rest of the run — and you see only the questions addressed to you, not any others the same run raised for other people.

What each choice does

Choice	What happens
Approve	The run carries on from where it stopped. The steps that already finished aren’t repeated
Reject	The run fails, with `ApprovalRejected` — unless the workflow was written to handle a rejection and carry on differently
Nobody decides in time	The request expires and the run fails. The deadline is 7 days by default and 14 days at most — see Limits and retention

A run that is awaiting approval does not continue on a newer version of the workflow. If the workflow is republished while the run waits, that run fails with a message saying so and has to be started again. Land workflow edits when nothing is waiting on a decision — or expect to re-run.

Nobody is left guessing about it. Whoever publishes is told which waiting runs the new version just stopped. On such a run’s page Approve is no longer offered, and a line above the buttons says why — naming the version the run started on and the one the workflow is now at; Reject stays, because closing the run out is still worth doing. And if someone had already approved it before the new version landed, a notification appears in their bell — under Notifications at the bottom of the sidebar — saying their decision could not be carried out. That notification always arrives; the matching email does not, because Workflow approval could not be honored starts switched off and an Admin turns it on under Notification routing. See Approve a run.

How approvers hear about it

Approvers get an email — or a Slack message, if the workflow’s approval settings route there — with the question and a single Review and decide link to the run page. You sign in and decide there; nothing is decided from the message itself.

Admins also see it in the Inbox on the Shared features page, as a RUN APPROVAL row: “{workflow} run is waiting for a decision”, with how long is left and how many approvers were asked. Clicking it opens the run page — the Inbox lists it, but the decision happens on the run.

If the workflow asked nobody — it named no approvers at that step, and none are set on the workflow itself to fall back on — the run fails right there with an error saying so. Ask whoever built it to name who should be asked.

A run that was Skipped

Skipped is a status you see in an automation’s run history, and only there. It means the automation fired and nothing ran. Usually that is because the workflow or Saved Agent it points at is set to Skip if a run is in progress, one of that resource’s runs was still going, and this fire was refused. The run already going was never touched; it is the late one that was turned away. It is also recorded when the automation was turned off, changed or deleted while Ronja waited to retry a workflow it couldn’t start — those summaries begin “Not retried:” — and, on a Table automation, when a catch-up re-run Ronja had queued found every table it watched deleted before it could run.

For a refused fire, the row’s summary names the run that was in the way, so you can open that one and see what it is doing. There is nothing to fix: the entry is a record that the setting did its job. Every refused fire leaves one entry, whichever trigger kind fired it.

A Table automation re-runs itself. A Table automation refused because its target was already running runs once more shortly after that run finishes, however many changes arrived meanwhile — so there is nothing for you to re-run either, and the catch-up appears in the history as an ordinary run of its own. The summary of the Skipped entry says a re-run is queued. The exception is an automation that changes a table it watches: if its last three runs that actually ran were all such re-runs, the entry says it was not re-queued instead, which is the automation being stopped from chasing its own writes. A catch-up that is itself refused — its target had started another run by the time it came round — is not queued again either, and its entry says so; the next change to a watched table fires fresh. For every other trigger a refused fire is simply turned away — the schedule comes round again, and an inbound email or webhook that was refused is not replayed.

One other way to get a Skipped entry is to turn off, change or delete an automation while Ronja is waiting to retry a workflow it couldn’t start (see Read a failed run). The summary then begins “Not retried:” and says which of the three you did. That entry names no run to open: the start that failed is in the workflow’s own run list.

The last way is the tail end of a catch-up: a Table automation’s queued re-run reaches the front of the queue and every table it was watching has been deleted in the meantime, so there is nothing left to catch up on. That takes a particular sequence, because Ronja refuses to delete a table while an automation watches it — the automation has to have been pointed at other tables first, and the ones it used to watch deleted after that. That entry names no blocking run either, and there is nothing to do about it — the automation itself is the thing to revisit, since it now watches nothing.

Whichever of the three it is, a Skipped entry sits in the same muted grey as a rate-limited run rather than the red of a failure, it is left out of the SUCCESS mini-stat, and it never counts towards a run of failures — so an automation that skips half its fires is not reported as failing.

There is nothing to read inside a Skipped entry either — no logs, no steps, no output, because no work was done. For a refused fire, the entry and the run it names are the whole record; open that run to see what is actually happening. The other two kinds name no run at all — the summary itself is the whole record.

A workflow or a Saved Agent leaves no such entry. When one of those is set to Skip if a run is in progress and a start is refused, no run is recorded at all — nothing ran, so there is nothing to put in the history. The caller is told there and then which run is in the way: a person sees the refusal on the page they started it from, and an app or a script gets an error back. An automation’s run history is the only place a refusal is written down.

If you wanted both to go, the thing to change is the workflow’s or the Saved Agent’s setting, not the automation — the automation has none of its own. Ask Ronja — “let the nightly sync overlap again” — since both pages show the value read-only. See Concurrency for a workflow, Concurrency for a Saved Agent, and Concurrency for how the two reach an automation.

Read a failed run

Expand the failed row — its summary line is the error itself, and the details tab shows the parameters used.
Open the Log tab: a terminal view with error lines highlighted, plus Copy and Download.
Open the Steps tab: the failing step carries a red failed pill — expand it for the full Error block and that step’s own log.
Read the amber Warnings from this run box, above the run activity, when there is one: notes the run itself raised. Nothing there failed the run — it kept going. Some lines say what the run could not do, which a re-run would do differently. Others say what the run had to change to deliver its result: a number that was not a real number — a missing value, or the result of a division by zero — is delivered as null, an empty value that is not the same as zero, and the line says how many numbers were not finite. If the difference matters, ask Ronja, or whoever built the workflow, to handle missing values or divisions by zero before the workflow returns its result.
Look for an amber not journaled chip beside a step in the Steps tab. That step ran, but its result was not recorded, so a re-run does that work again instead of reusing it. Hover the chip for the reason.
Check the header if the run succeeded but shows a yellow degraded badge: a best-effort step failed without sinking the run, and the Steps tab tells you which one.
Click the re-run icon (top right) to replay the run with the same parameters.

If Ronja can’t start the workflow an automation runs, Ronja tries once more about a minute later, whatever the trigger. The automation’s run stays running while it waits, its summary says it was retried, its duration includes that minute, and a failure is reported only if that second try fails too. The workflow’s own run list still shows that first start as failed, even when the second try succeeded.

A run you start with Run now gets the second try too. A test run Ronja makes while setting the automation up with you does not, and neither does a run whose workflow had already started. If you turn the automation off, change the workflow or parameter values it runs, or delete it during that minute, the run is recorded as Skipped (editing only its schedule, name or trigger does not stop the second try); if your organization runs out of credits, or the workflow is deleted or its parameters no longer match the automation’s, the run fails without a second try.

A durable workflow remembers what each step produced: when you re-run one after a failure, the steps that already succeeded come back marked cached in the Steps tab — Ronja reused the recorded result instead of doing that work again, so the run picks up where it broke. Not every step can be remembered, and the ones that could not say so: a step marked not journaled is one whose result was too large, or of a kind that cannot be stored, or something that must not be written down at all — that step is simply done again on the re-run.

That memory covers what the workflow sent, not just what it computed — but it works differently there, and the difference decides what a re-run does to the people the job contacts. An email, a notification, an upload or a call out to another system is recognised by its own content: if the re-run would send exactly what already went out, it is not sent again. If the data behind it moved in the meantime — a figure recalculated, a row edited, a list re-ordered — what the re-run would send is no longer the same message, so it goes out. On a job that got halfway through notifying a hundred customers, the fifty already mailed are mailed a second time if what they would receive has changed since. When that matters, check what has changed since the failure before you re-run.

There is a second way a send can be written, and it behaves the opposite way round: whoever builds the workflow can give a send a fixed identity — one tied to the thing it is about, such as the invoice it concerns — rather than letting its own content identify it. A send pinned that way is never repeated on a re-run, even when the figures behind it have changed. So if you are re-running specifically to get corrected figures out to people, ask whoever built the workflow which way its sends are written; re-running is not on its own enough to guarantee the corrected message goes. Rows and files the workflow produces are always written afresh, so a re-run still leaves you with a complete set of outputs.

Investigate with Ronja hands the whole problem to a chat that opens with the failing thing already loaded and the diagnosis already under way. It appears in three places:

A failing automation — in the status strip of its detail page, opened from the Automations page. See Schedule an automation.
A failing workflow — under the status line on the workflow’s page, whenever its most recent run failed. Ronja arrives with the workflow’s Python, its recent runs, and the failing run’s error already in hand.
A table whose last build went wrong — under the Build failed (or Partial data / Out of sync) banner on the table’s page, or the “Showing data from … Updates have failed since …” banner of a table that has stopped updating. See Fix data issues.

In each case Ronja explains what she found and confirms with you before changing anything. The button appears only while there is something to investigate — a failure state, or a recorded build problem on a table — and only for Admins who also have Build mode: repairing a workflow or a table edits it, which is an admin action.

Open the execution trace

Click View trace in the run page header (shown when the run was traced).
Read the health card — “Completed — no issues”, “Completed with {N} issue(s)”, or “Failed” — and the four tiles: TOOK, STEPS, RAN IN PARALLEL, FINISHED.
Scan the waterfall: one row per span in the causal chain — an AUTOMATION trigger, the WORKFLOW RUN, its STEPs, any AI · AGENT work — all on one shared time axis. A bracket and a purple “parallel” chip mark steps that ran at the same time. A workflow that paused and continued shows one WORKFLOW RUN block per continuation; steps whose result was reused rather than re-run appear as cached.
On a very large trace, some rows are collapsed rather than shown — every WORKFLOW RUN block is always listed, and you click one to load its steps.
Expand a failed span’s Error & logs disclosure for the full error text.

Execution trace waterfall with the health card, summary tiles, and nested spans on a shared time axis The execution trace: “What Ronja did, step by step — and where the time went.”

When a run reacts to an emitted event, the trace shows how it connects to others. A Triggered by row links back to the trace that emitted the event this run reacted to, and a Triggered {N} automations row links forward to each trace an event from this run set off — click any chip to open that trace. A link to a trace you can’t open shows as a locked marker reading “A run you don’t have access to”.

In an exploration

Click the pinned Runs entry on the session’s rail — it lists every workflow and Saved Agent run this conversation spawned.
Click a row to open its trace in a docked panel. Run cards in chat also carry their own View trace button.

Organization-wide (admins)

Admins can open the Runs & Traces page in the sidebar’s Activity group for a newest-first list of every execution trace in the organization, with Load more paging — see Activity log.