Review a run's performance#

Every run measures itself: how long it took, how much memory and CPU it used, and which formula families and calculation services accounted for the time. Nothing has to be turned on, and no setting controls it. Four places read that measurement, and this page covers the first two:

• Run History compares each run against the same job's own recent runs, so a slowdown is visible in the list.
• The Performance tab on a run's diagnostics breaks one run down until the cost is attributable to a specific output, workbook, processing phase, or calculation engine.
• The Compare tab searches the job's whole history for the point where its typical run time changed, see Find when a job got slower.
• Settings ▸ Performance ranks every job against its own baseline and pivots the instance by release and by node, see Compare performance across jobs.

When to use it. When a pack that used to finish in three minutes now takes twenty, when you need to know which workbook in a large burst is the expensive one, or when you suspect a formula is being recalculated far more often than it needs to be. Also for capacity planning: peak memory and maximum CPU per run tell you what an execution host has to hold.

Before you start#

• Open the job's Run History: in the workspace browser, open the job row's ... menu and select Run history. See Track activity and run history.
• The three performance columns are visible to anyone who can see the run list. The Performance tab is not: a view-only User account sees a run's Details only, with no tabs. Authors and administrators reach it.
• Only runs executed on a build that records performance telemetry carry the data. Earlier runs say so rather than reporting zero.

Compare a run against its own history#

The run list carries three performance columns.

Five rules govern the comparison, and they explain why a delta is sometimes absent:

• The baseline is the median of up to 12 earlier comparable runs of the same job. The median is deliberate: one pathological run, a datasource timeout or a ten-times-larger burst, would drag an average far enough to hide every later regression.
• A job needs at least 3 earlier comparable runs before any comparison is offered. Below that, the column reports no comparison rather than measuring a run against a single predecessor.
• A difference within 15 percent counts as noise and is not flagged.
• A run is never part of its own baseline.
• Failed, canceled, and no-telemetry runs are held out of the baseline, and they get no delta of their own. A job that died after 30 milliseconds would otherwise be reported as the fastest run in the list.

Below the list, a note states how many runs recorded no telemetry and how many are held out of the baseline. A column full of dashes therefore reads as missing history rather than as a broken screen.

Two different elapsed figures. Where telemetry exists, the elapsed time is measured from execution start. Where it does not, the column falls back to the wall-clock duration on the run record, and the value's tooltip says which one you are looking at. The two are never mixed inside one trend.

Open the Performance tab for one run#

1. In Run History, select the run you want to inspect. It opens on its Details tab.
2. Select Performance. The tab is present on every run, alongside Details, Progress, Timeline and Compare.

A run with no telemetry shows a short explanation in place of the breakdown. Two cases produce it: the run finished before performance telemetry existed, or it was a release of held output, which deliberately does not overwrite the original run's measurements.

Read the breakdown#

The tab leads with one sentence naming the dominant cost, for example that the run took 4m 12s and one engine accounted for 63 percent of its workbook processing time. Workbooks run side by side, so their processing time added together can be longer than the run itself; when it is, the sentence says so, and the share is always of that combined processing time. Where no single engine dominates, it says the time was spread across several engines instead.

Six figures follow.

Walk from the run down to a phase#

Below the figures, the screen splits in two. On the left, one list ranks the current scope's contents by cost, largest first, with a bar showing the same proportions. Select a row to go one level deeper. Once you are inside an output, a Back to button and the path (Whole run, output, workbook) appear at the top of that list so you can come back up. The Engines table and the Advanced diagnostics section on the right follow whichever level you pick. The walk is always the same three levels:

1. Whole run, listing the outputs it generated.
2. One output, listing the workbooks inside it.
3. One workbook, listing its processing phases. Phases are the last level.

At workbook level, two tails are listed separately from the ranked phases: phases that ran but cost nothing measurable, and phases that never ran at all. Keeping them apart matters, because "this workbook has no charts" and "charts were free" are different facts about the same run.

Read the engine table#

The Engines table lists one row per formula family (for example the Planning Analytics or SQL retrieval functions, with all built-in Excel functions folded into a single row) and per calculation service, with Calls, Total, Avg, and Recalc passes.

Recalc passes is the column to read. It says once for an engine that ran a single time, or N of M for one that re-ran during recalculation. An engine reading 5 of 5 on a five-pass workbook ran on every pass, and Reportworq highlights that row when the pass count is high enough for it to be expensive. That pattern is worth acting on: a data retrieval repeated on every recalculation pass is usually a formula that can be restructured, not an unavoidable cost. Engines that ran at no measurable cost are counted in a note under the table rather than listed.

Above workbook level the pass counts are folded together from the workbooks in scope, and the table says so, so 5 of 5 there means "in the recalculation loop the whole way" rather than a run-wide total.

Open Advanced diagnostics#

Under the Engines table, Advanced diagnostics holds the run's log and its files. It starts collapsed: select it to open it. Logs lists the job log with its error count and entry count, and Attachments lists each file the run kept with its size. Every row ends with a download button. For reading the log of a failed run, see When a job fails.

Notes and limits#

• Runs that predate telemetry never gain it. The measurement is written when the run executes, so history from an earlier build stays empty. Look at the runs from the current build onward.
• A failed run still records its performance, deliberately, since a failure is often exactly the run whose breakdown you want.
• Releasing held output writes no new measurement. The release re-opens the original run's record, and overwriting it with a distribution-only measurement would destroy the history this feature exists to build.
• Performance data ages out with the run. It is stored with the run's other diagnostics and is removed when retention removes the run. Pin a run to keep it, for example a period-close run you expect to compare against. See Output retention.
• This is not alerting. There are no thresholds to set and no notifications. The baseline rule is fixed as described.
• A view-only User never reaches the Performance tab, because that role sees a run's Details only.

Going deeper. For what to change once you know where the time went, see Manage and improve performance. To find the point in this job's history where its run time changed, rather than judging one run, see Find when a job got slower. Administrators can ask the same question across every job at once, and pivot by product release or execution node, in Compare performance across jobs. To read a failing run's log, attachments, and HTTP trace instead, see When a job fails. To change how long runs and their diagnostics are kept, see Output retention.