Execution Runtime Estimates
Engine automatically builds a statistical model of how long your automations typically take to run, and uses it to show you live runtime estimates while executions are in progress.
This helps you to:
- Know roughly how long a running execution will take to finish.
- Spot executions that are taking longer than usual.
- Understand how reliable a flow or connector is, before you run it.
Where estimates appear
Execution live monitor
In the Execution Live Monitor, the Info column shows a compact progress bar for every in-flight execution (any status other than ENDED_SUCCESS, ENDED_ERROR, or ENDED_CANCELLED). Below the bar you can see the estimated total duration and, when available, an overrun indicator.
Single execution screen
When you open an individual execution, the estimate is shown directly below the status badges — alongside the "running since" timer for AT_ENGINE executions. The bar grows in real time and turns orange when the execution has run past its estimate.
Dependency visualization
Each node in the Dependency Visualization that represents an in-flight execution displays a thin progress bar at the bottom of the node, giving you a glanceable overview of the whole execution tree.
Flow details panel
On the single-flow screen, open the details panel (the ⓘ icon in the page header) to see the historical runtime statistics for that flow: typical duration, success rate, and whether recent runs have been faster or slower than average.
How the estimate is calculated
Engine records the duration of every successfully completed execution. For each flow or connector, it maintains a rolling window of up to 200 recent successful durations. From this sample it derives the p75 — the time by which 75 % of past runs have finished. This is shown as the estimate.
Only ENDED_SUCCESS executions contribute to the duration sample. ENDED_ERROR and ENDED_CANCELLED executions are counted for the success rate but do not affect the duration estimate.
The p75 is a deliberately conservative choice: it is more useful as a planning figure than the median, because it accounts for normal variation without being skewed by outliers.
Grouping: what counts as "the same type of execution"?
Runtime estimates are meaningful only when compared against past runs of the same kind of work. Engine uses a two-tier grouping strategy:
Tier 1 — key + parent context: A flow or connector execution is grouped with past runs of the same flow/connector that were called from the same parent flow. This captures context: for example, an SSH connector called from a build flow is typically doing something different from the same connector called from a maintenance flow, and the two groups get separate estimates.
Tier 0 — key only: All executions of the same flow or connector regardless of where they were called from. This is the fallback when Tier 1 has fewer than 5 samples.
Engine walks the full parent chain, so executions whose immediate parent is a wrapper still correctly inherit the context of the enclosing flow.
For dynamic scripts (SCRIPT type with no flow ID) no stable identifier exists, so no estimate is shown. For ad-hoc connections (no named connector), the connector type (e.g. SSH) is used as the key.
Minimum sample size
Estimates are only shown once a grouping has at least 5 completed executions. Below that threshold there is not enough data to give a meaningful number. Newly created flows will not show an estimate until they have run five times successfully.
Progress bar behaviour
The progress bar fills from left to right as the execution runs:
| Elapsed time | Bar appearance |
|---|---|
| Less than the estimate (p75) | Blue, growing |
| Equal to the estimate | Blue, full |
| Exceeding the estimate | Orange, full — overrun shown as "+X min" |
The bar never shows 100% while an execution is still running — it caps at the estimate value and turns orange once the execution passes it. This makes it easy to see at a glance that something is taking longer than usual.
Success rate
Alongside the runtime estimate, Engine shows the success rate of the matching group — the fraction of past runs that ended in ENDED_SUCCESS. This appears once there are at least 5 terminal executions (success or error; cancelled executions are excluded).
The colour of the percentage reflects how reliable the flow or connector has been:
| Success rate | Colour |
|---|---|
| ≥ 90 % | Green |
| 70 – 89 % | Orange |
| < 70 % | Red |
A low success rate is an early signal that something may be wrong with a flow or that it depends on an unreliable external system.
Trend indicator
When a grouping has at least 40 samples, Engine computes a trend ratio by comparing the median duration of the most recent 20 runs against the median of the oldest 20 in the sample window. If recent runs are consistently slower (ratio > 1.2×) or faster (ratio < 0.8×), a ▲ or ▼ indicator appears next to the estimate:
| Symbol | Meaning |
|---|---|
| ▲ slower recently | Recent runs take 20 % longer than the historical baseline |
| ▼ faster recently | Recent runs finish 20 % faster than the historical baseline |
A ▲ indicator on a flow that has always been stable in the past is worth investigating — it may indicate a growing dataset, a slow external dependency, or a logic change that added unintended work.
Data persistence
Runtime statistics are stored independently of execution records. Execution records are subject to automatic expiry (by default 2 weeks live + 2 weeks in trash), but the runtime statistics table is never purged. This means estimates improve over time and remain accurate even for flows that run infrequently.