Monitor runs and traces

Who can do this

Anyone who can open a workflow can see its runs and traces — minimum role User Read-Only. The organization-wide trace list requires Admin.

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

1. Open the workflow — from its feature hub row, an exploration panel, or a link in chat.
2. 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.
3. Click a row to expand its inline log / output / details tabs.
4. Click Open full for the full run page — stat tiles (DURATION / TRIGGERED BY / RESULT / VERSION), tabs Output / Steps / Log, and the parameters used.

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). That is why SUCCESS names the number of runs it was worked out over, which can be smaller than RUNS.

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 carries the Durable badge 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:

1. Read the headline — it is the question the workflow is asking — under the eyebrow Awaiting approval.
2. Check the context rows below it: the details the workflow put in front of you to decide on.
3. Note the deadline, shown as Expires in 6 days.
4. Add a note in Comment if it helps — “Add an optional note for whoever started this run…”. It’s optional.
5. Click Approve or Reject. A toast confirms it — Run approved or Run rejected — and the card keeps the decision, with who made it and when.

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

Publishing a new version cancels a waiting run

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.

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.

In a chat

If you started the run from a conversation, its result says the run is waiting for a human decision and will not carry on by itself — unlike the self-resuming waits above, nothing happens until someone decides. Open the run page (or the email) and decide there.

Read a failed run

1. Expand the failed row — its summary line is the error itself, and the details tab shows the parameters used.
2. Open the Log tab: a terminal view with error lines highlighted, plus Copy and Download.
3. 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.
4. 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.
5. Click the re-run icon (top right) to replay the run with the same parameters.

A workflow marked Durable (a badge beside its name, in the workflows list, on its page, and on each of its runs) 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.

That memory covers what the workflow sent, not just what it computed. An email, a notification, an upload or a call out to another system that already went through the first time is not repeated when you re-run — so a job that got halfway through notifying a hundred customers finishes the other fifty rather than mailing the first fifty twice. Rows and files the workflow produces are always written afresh, so a re-run still leaves you with a complete set of outputs.

When the same thing keeps failing

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 sidebar, 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. 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

1. Click View trace in the run page header (shown when the run was traced).
2. Read the health card — “Completed — no issues”, “Completed with {N} issue(s)”, or “Failed” — and the four tiles: TOOK, STEPS, RAN IN PARALLEL, FINISHED.
3. 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.
4. 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.
5. Expand a failed span’s Error & logs disclosure for the full error text.

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”.

Note

Traces are retained for about a year, measured from when the run started — and for a workflow that pauses, from the first run of the chain. Runs from before tracing existed simply have no View trace link.

In an exploration

1. Click the pinned Runs entry on the session’s rail — it lists every workflow and Saved Agent run this conversation spawned.
2. 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 Monitor activity and usage.