Skip to content

Monitoring & Analytics

A live FlowRunner™ flow runs on its own - monitoring is how you know it is doing what you built it for, and where to look the moment it isn't. Three of the tabs across the top of an opened flow answer the health questions:

  • Dashboard - what is going on with the flow, and is anything wrong?
  • Performance - which step is slow, or starting to fail?
  • Logs - what happened, step by step, on a run you need to trace?

The fourth question - what did one particular run do with its data? - has its own page: Inspecting a Single Run, reached by opening a run from the Instances tab. The rest of the row belongs to other work: View and Version Admin to reading and administering the version, SLA Goals to the targets covered with SLA goals. The Dashboard, Performance, and Instances tabs each carry the same From / To date window - with presets like Past 30 days - that sets the range their numbers cover, and REFRESH beside it re-reads them, so you can watch a number move. The views read from the flow's run history.1

The tab row of an opened flow - View, Dashboard, Performance, Instances, SLA Goals, Logs, Version Admin - with the From / To date window, its Past 30 days preset, and the REFRESH button beneath it.

Dashboard - the flow at a glance

Open the Dashboard to take in the whole flow at once and catch trouble before you go digging. The headline numbers answer "is anything wrong?":

  • Completion Rate and Error Rate - are runs succeeding? A rising Error Rate is your cue to open the Logs or the failing runs.
  • Active Instances - how many runs are in flight. A count that keeps climbing means runs are starting faster than they finish, and a backlog is building.
  • Total Runs - the volume over the range, so you can watch load rise or fall.
  • SLA Compliance - whether runs are hitting the time targets you set as SLA goals.2

Below the numbers is where you make sense of what the flow is doing. The example the shots follow is a flow that polls an order until it ships:

  • Run history charts when the flow actually ran, as a heatmap of daily activity with its own year picker, so it reaches further back than the date window above. A quiet stretch that should have been busy points at a schedule that stopped; a burst points at a caller firing far more often than it should. Click a day to list its runs - each with its time, what started it, and how it ended - so an odd-looking day is one click from the runs behind it.
  • Versions - when a flow has more than one version, the Versions list lets you tick which versions the Run history includes, to read a new version's behavior on its own or next to the old one.
  • What starts the runs - the chart beside the day's list splits the runs by source: Scheduled Runs, API, Trigger Event, or Other Execution. This is how you tell a steady scheduled job from an API flood, or notice a trigger firing when nothing should be triggering it.

The Dashboard tab: the monitoring tab row and date window above health cards (SLA Compliance, Completion Rate, Error Rate, Total Runs, Active Instances), the Run history heatmap with a day selected, that day's activations listed by time, source, and status, the Versions list beside the heatmap, and the source chart showing 100% API.

Two more panels sit below:

  • Block Transitions - which paths the runs actually took, as a percentage on the connections between blocks, drawn onto the flow diagram. A branch that never fires, or one that fires far more often than you expected, stands out against the diagram.
  • Problematic Instances - the shortlist worth your attention: the runs that errored or missed an SLA goal, each row opening the run when clicked. An empty list is the state you want - it means every run in range finished clean. When a run does land here, Inspecting a Single Run covers tracing it to the step that failed.

The Dashboard's lower panels: Block Transitions drawing the flow with a percentage badge on the connections between blocks, and the Problematic Instances table - empty here, because every run in range finished without errors or missed SLA goals.

Performance - where the time goes

When a flow feels slow, Performance tells you which step to blame. It times every block across the runs in range - Average, Min, and Max time spent in that step - beside its Error Rate and Compliance Status. Sort by average time to bring the bottleneck to the top, or by error rate to surface a step that is quietly failing. One reading note: a loop block like Repeat appears with its inner blocks nested beneath it, and the loop's own time covers all its passes - so when a loop tops the sort, open its nested rows to find the step actually costing the time. And a block whose max time towers over its average is one that stalls on some runs and not others - intermittent slowness that averages alone would hide.

The Performance table sorted by average time, descending: the Poll Until Shipped loop on top with its inner blocks nested beneath it, each block with its Average / Min / Max time in step, Error Rate, and Compliance Status.

Logs - the play-by-play

When you need the actual sequence of events, the Logs tab is the raw record: every run, and every block within it, timestamped as it starts and completes, tagged with how the run began. It is where you reconstruct a specific run or pin down the moment one went wrong.

The Logs stream: timestamped INFO lines for each run and each block - execution started, per-block started and completed, execution completed - with the search box, Filter and display toggles, and the Log Source picker above.

The controls above the stream narrow it to what you are tracing. The Log Source picker scopes the stream to a single run - and once one is picked, a Show logging for picker appears to narrow further to one block's lines. Type a term into the search box and tick Filter to keep only the lines whose message matches it, highlighted where they match. Three more controls matter for tracing:

  • From / To - scope the stream to a time window.
  • CLEAR LOG AREA - empty the pane, so you watch only what arrives next.
  • Basic timestamps - trade the full date on each line for a compact clock time.
  • Shorten IDs - show each run's Instance ID as its first and last characters (83E53...5EFB6) so the lines stay scannable. Untick it when you need to copy or compare the whole id. A run that was given a name shows the name instead, and the toggle leaves that alone. The choice is remembered by your browser.
  • Wrap messages - wrap a long line rather than letting it run off the edge, which is what keeps a WARN about a discarded value readable in full.

The Logs toolbar with Wrap messages, Shorten IDs and Basic timestamps ticked, above lines from two runs of a probe flow: each line carries a shortened Instance ID such as 83E53...5EFB6, and a WARN line from the Has Email? block wraps onto a second line

The stream narrowed: the Log Source picker holding one run, the Show logging for picker it revealed, and a search for "execution completed" with Filter ticked - only the matching lines remain, the matched text highlighted.

  • Inspecting a Single Run - opening one run to see what it did with its data
  • Running Flows - taking a flow live, and the run list these views draw on
  • SLA Goals - the time targets that SLA Compliance measures against
  • Flows and Instances - the flow-and-run model behind every number here
  • Billing - what the runs behind these numbers cost, and how far back the history reaches

  1. How far back the history reaches - and with it the Dashboard, Performance, and Instances views - 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. ↩

  2. SLA tracking carries real data on the Business and Enterprise plans, where SLA goals live. ↩