Run estimates and expected completion#

Reportworq tells you not just that a job is running, but roughly how much longer it has to go, and afterwards whether a finished run met the expectation it was held to at the time.

This shows up in three places:

• A live estimate on the running job's row in Activity, a small chip next to the elapsed time reading something like ~20m left.
• A running-jobs preview, from the activity pulse icon in the top navigation bar, so you can check on activity from any screen.
• An Est. completion lane on a finished run's diagnostics Timeline, showing how long that run was expected to take, drawn on the same clock as everything else it did.

All three are read-only, at-a-glance aids. None of them changes how a job runs or when it finishes. They only report.

The live estimate on a running job#

While a job is running, its Running row on the Activity screen shows an estimate chip beside the Elapsed column. It reads one of three ways, depending on where the run is relative to how long that job usually takes:

Hover the chip for a fuller explanation, such as "About 20 minutes remaining (usually ~47m, median of 8 similar runs)."

over is informational, not an error. A run can legitimately take longer than usual, because a larger dataset or a slower datasource day will push it out. Treat it as an early heads-up worth a look.

How the estimate is calculated#

The estimate is the typical (median) duration of the job's own recent comparable runs.

Reportworq uses the median rather than the average deliberately, so that a single unusual run, a one-off datasource timeout or a burst that was ten times its normal size, cannot distort the estimate for every run after it.

A past run only counts toward the estimate when it is genuinely comparable to the one in progress:

• it is the same job, in the same workspace;
• it succeeded, because a failed or canceled run stopped early for reasons unrelated to performance; and
• it has the same shape. A job run on its own is compared only against other solo runs, never against times when it ran as part of a larger scheduled batch, whose elapsed time covers every report in the batch.

Because the estimate is drawn only from the running job's own workspace, a similarly named job in a different workspace never affects it, and you only ever see estimates built from runs you are permitted to see.

When no estimate appears#

If a job does not yet have enough comparable history, no chip is shown and the row simply displays its elapsed time. A job typically needs at least three comparable successful runs before an estimate appears.

This is deliberate. Reportworq shows nothing rather than a guess it cannot stand behind, so a chip that is shown is one you can rely on.

That also answers the common question of why one running job shows an estimate and another does not: the one without a chip is either new, or its recent runs do not match the current run's shape, for example it usually runs inside a batch but is running on its own this time.

The running-jobs preview#

The activity pulse icon (the wave pulse) in the top navigation bar previews what is running right now. Hover it, or tab to it if you navigate by keyboard, and a small popover lists every currently running job with its name, elapsed time, current status, and its run estimate where one is available.

When nothing is running, the popover reads "No jobs running right now." Clicking the pulse still opens the full Activity screen, as before.

Three things worth knowing:

• The preview lists only jobs you are permitted to see. It respects your workspace and folder access, so it never reveals a job you could not otherwise open.
• It opens on both mouse hover and keyboard focus, so it is reachable without a mouse. It contains no buttons, it is purely informational.
• On the Activity screen itself the popover is intentionally not shown, because you are already looking at the live list. Everywhere else in the app, it is available.

For full detail, per-run actions, and history, open the Activity screen.

Expected completion on a finished run#

Open a run's diagnostics and choose the Timeline view. Its bottom lane, Est. completion, shows what that run was expected to take:

• an expected band running from the start of the run to the point it was expected to finish, labeled with the duration, for example Expected 10.5s;
• when the run went longer than expected, a hatched overrun strip covering the stretch from the expected finish to where the run actually ended, labeled with the amount, for example 487ms over;
• when the run beat its estimate, the band runs to the right-hand edge of the timeline and fades out. The expected finish is off the end of the chart because the run stopped before reaching it, and the band's label says so: Expected 10.8s · 426ms early.

Hover the band for the full explanation, including how many past runs it was formed from.

The fading band does not mean data is missing. The fade means the expected finish is beyond the right-hand edge of the chart. The timeline's axis is always the length of the actual run, and is never stretched to fit an estimate, because that would squash the run's real activity into a corner of the plot.

Because the lane shares the timeline's one clock with the execution, workbook, event and memory/CPU lanes, you can see not just that a run went long but what it was doing when it passed the point it should have finished.

A finished run is judged by its own era#

This is the important difference from the live chip. A finished run is compared against the runs that came before it, never against runs that happened afterwards. A run from March is judged by what Reportworq expected of it in March.

That matters because the alternative is subtly misleading. Comparing an old run against today's history would hold it to an expectation that did not exist yet, and the resulting number would look entirely plausible. As a job gets faster or slower over the months, older runs keep the expectations of their own era rather than being re-judged against today's.

It is the same rule the Elapsed vs baseline column on the run list uses, and the two are computed from the same place, so they cannot disagree. If the run list shows no comparison for a run, the timeline lane shows no band either, and both give the same reason.

When no band appears#

The lane always appears, but it shows no band, and says why in plain words, when the run cannot honestly be compared:

Who sees this#

The expected-completion lane lives inside a run's performance diagnostics, which are gated the same way as the run list's comparative columns. A reader sees their own run's elapsed time, not the installation's performance diagnostics. This is deliberate.

Related#

• Activity and run history for the screen the live estimate appears on.
• Run performance for the per-run breakdown the Timeline sits beside.
• Find when a report got slower for comparing runs over time.