Skip to content

Inspecting a Single Run

The monitoring views describe a FlowRunner™ flow in aggregate; this page is about one run: what did this run do with this data? Opening a run answers that block by block - what each one received, what it produced, and where things went wrong - whether you are chasing a failure or just confirming a run handled its data the way you meant.

Opening a run

The Instances tab lists the flow's runs, each with its start and finish time, duration, error flag, and status, with filters above the list to narrow it.1 Open one and the flow is redrawn as that run took it: every block it executed carries a tick, and two panels carry the detail:

  • Instance Summary - the run's facts: how long it took, whether it errored, which SLA goals it missed, and the Initial Data it started from.
  • Select any block and Element Execution Details shows the Input it received and the Output it produced. That is how you follow a value from the data that arrived, watch each block reshape it, and pin the step where a wrong result first appears.

The Input records names as they were when the run happened - the name of the flow a Call Flow block runs, for example - so renaming something later does not change an old run. When an AI Agent or AI Router reads its API key from an expression, the Input shows only the key's first and last four characters.

The example the shots follow is a flow that polls an order until it ships.

An opened run: the flow with each executed block ticked, the hovered loop block showing its expand icon, a block selected with its configuration on the right, and the Instance Summary and that block's Input and Output below.

Finding the run you want

A row of coloured circles sits above the list, one per state, in this order: Running, Pending, Completed, Terminated. Each shows only a number, and hovering names it - "Terminated - 11 instances". Read them to answer "is anything stuck or dying right now?" without going through the table.

Clicking a circle filters the list to that state, and clicking it again clears the filter. The Status dropdown above sets the same filter, and the two always agree - filter by one and the other follows.

The counts follow the rest of the filter context - the date window, the search, and the two checkboxes behind the ... control, Only With SLA Violations and Only With Errors. The status filter itself does not narrow them, because the circles are the status overview.

To watch runs arrive while a flow is working, turn on Live beside the refresh icon. The list and the circles re-read at once and then every 5 seconds, so a new run appears without you reaching for refresh. The refresh icon still works while Live is on. Live starts off, and your browser remembers your choice for every flow you open in it; another browser starts with it off again.

The Instances tab of Cart Summary: a filter row with From and To dates, a Past 30 days selector, the refresh icon, the Live switch turned on, a Search box, a Status dropdown set to ALL, a "..." control and a download icon. Below it four count circles reading 0, 0, 4 and 0, and under those the run table with columns Instance Name, Start Time, Finish Time, Total Time, Has Error, Status, Compliance and Missed Goal - four COMPLETED runs - and, as the last entry, the line "1 instance is older than 7 days and not shown. Upgrade to Professional to view 30 days of history."

Runs older than your plan shows

The list only reaches back as far as the workspace billing plan's execution log visibility1. Runs beyond that are kept, not deleted. When a version has runs older than that window, the last page of the list ends with a line that counts them and names the cheapest plan that shows more, linked to the workspace's Billing page:

The bottom of the Instances list: the last run row, then the line "1 instance is older than 7 days and not shown. Upgrade to Professional to view 30 days of history." with Upgrade to Professional as a link.

The count covers everything older than the window, so changing the date filter does not change it. It never appears on Business or Enterprise, which show the whole history. Opening one of those runs directly - from an email, a bookmark, a link a colleague sent - shows This instance is outside your plan's history in place of the analytics, with when it started, the window the plan shows, an upgrade button naming the next plan up, and a way back to the list. A run that no longer exists shows Instance not found instead.

Taking the list away as CSV

The download icon beside the filters - its tooltip reads Export instances to CSV - writes a CSV of everything matching the current filters, not just the page you are looking at. Set the filters you want first, then export: what the list is showing, including every page it would take you through, is what the file holds.

One row per run, with a column for the instance name, the execution id, the flow name and version, the status, the start and finish times, the total time in milliseconds, the error flag and handled-error detail, and the SLA compliance and missed goals. The execution id is kept as its own column even when a run has a friendly name, so an exported row still lines up with the API and with a support conversation.

The export runs on the server, so a large result does not block you - you can keep working or leave the screen. When the file is ready, a notification says so, and the link to the file is sent to the address on your account.

The same filter row with the pointer on the download icon at its right end, the icon highlighted and a tooltip above it reading "Export instances to CSV". The four count circles - 0, 0, 0, 11 - sit below.

Stepping through a loop's passes

A Repeat or List Iterator runs the same inner steps many times, and a bug usually lives in one pass. Hover the loop block and click the expand icon that appears on it. The loop's inner blocks are drawn with their own markers: a tick on each block the pass executed, a not-executed marker on any branch it skipped. The Iteration # field then walks the run pass by pass - jump to the one iteration of forty where a value went wrong and inspect every block on that pass. RETURN, at the top left, steps back out to the whole flow.

Inside a loop: the RETURN control and the loop block's name at the top, the inner blocks ticked - with a Break on an untaken branch carrying the not-executed marker - the Iteration # field to step through passes, and the selected block's Input and Output for the chosen pass.

Checking a block's retry attempts

Retry attempts show you whether a Retry Policy is doing its job. Retries need a call that fails, so this section follows a second flow - one whose HTTP Request calls an endpoint that answers 503. When the block's policy fired during a run, its Element Execution Details grows a second tab, Retry attempts, with one entry per failed attempt that triggered another try; the final attempt's outcome, success or failure, stays on the Data tab, so a policy that exhausted three attempts shows two entries here. Each entry carries:

  • the attempt number, and when it ran,
  • what it failed on, and the response the service actually sent,
  • how long the run waited before the next try.

A couple of 503s followed by a success is a transient fault the policy absorbed; every attempt failing the same way means the retries are being spent on an error that will never pass.

The Element Execution Details panel on a retried HTTP Request: the Retry attempts tab counting the retried attempts, and the first attempt's entry - its number, the 503 status, the timestamp, the response body the service sent, and the wait before the next attempt.

Finding the step that failed

A failed run arrives flagged everywhere you might look for it. In the Instances list, its row is marked TERMINATED with its Has Error column filled - and the Only With Errors filter above the list finds such runs fast.

The Instances list with an errored run: the row marked TERMINATED, its Has Error column filled, above it the status filter and the Only With Errors checkbox.

The same run lands in the Dashboard's Problematic Instances shortlist, where clicking the row opens it:

The Problematic Instances panel with the errored run listed: the row marked TERMINATED with its Has Error column filled.

Open it and the trail continues: the Instance Summary reads Has Errors: Yes, and on the redrawn flow the block that broke carries a warning marker where the others carry ticks. Select it and its Output holds what the failure returned - for the retried call above, the 503 status the service kept answering with. From a run marked in the list, you are two clicks from the exact step that failed and what it answered.

The errored run opened: the failing HTTP Request block carrying a warning marker on the canvas, the Instance Summary showing Has Errors Yes and TERMINATED, and the block's Element Execution Details - the Input it sent and the Output marked failed with the 503 the service returned.

When a step fails because data is missing. A field that points at data the run does not have, such as a property of an order that never arrived, stops its block with error 28130. The Output names every reference in that field that could not be filled and why: a value that is not set, a value on the path that is null, a list with no item at that index, or a block that has not run. The fields the block could fill keep their values under Input. Here a shipping label's body points at order → shipping → address → city, but the order has no shipping, and at a zip under an address that is null:

Element Execution Details of a failed HTTP Request: under Input the URL and, for Body, the list of references it could not fill; under Output the error code 28130 and the message "Parameters evaluation failed: Body: Could not get values for the following references:" with one line per reference - 'Default - order → shipping' is not set, and 'Default - order → customer → address' is null.

  1. How far back the list reaches is the workspace billing plan's execution log visibility: 24 hours on Free and Starter, 7 days on Growth, 30 on Professional, 90 on Business. Older runs are kept, not deleted; moving up a plan brings them back into view. Billing covers the plans. ↩↩