Until a run finished, the Execution Log could tell you it had started and not much else. For a short report that's fine. For a mail merge that expands into hundreds of exports, "running" for twenty minutes leaves you with no way to tell a healthy run from a stuck one.

The Progress tab answers that while the run is still going: how many tasks are ready, how many are still working, and what the run is waiting on.

This is a reporting surface. It shows you what a run is doing — it doesn't change when your reports send, what they contain, or who receives them. Closing the page has no effect on the run.

Finding it

Open Execution Log, click a run, and choose the Progress tab, alongside Task Executions, Logs and Files.

The tab appears on runs that have a durable run record. Older runs from before this feature predate those records, so on those the tab isn't shown at all — rather than showing you an empty one. Their Task Executions, Logs and Files tabs are unchanged.

Counts, not a percentage

The headline is a sentence like:

8 of 13 tasks ready; 2 running; 3 not started.

Cancelled work is counted in its own clause at the end, for example 4 of 6 tasks ready; 1 unknown; 2 cancelled.

Only the states that actually apply are listed. If nothing failed, there's no "0 failed" — a zero invites you to hunt for a problem that isn't there. The same holds for every clause: a run with nothing cancelled simply doesn't mention cancellations.

There's deliberately no percentage and no progress bar. Both would be a prediction dressed up as a measurement. A task's recorded status can be missing, and a task can finish without ever being observed mid-flight, so neither the number finished nor the number expected is solid enough to divide one by the other. For the same reason there's no estimated finish time. Counts are what the run records actually support, so counts are what you get.

The states you'll see:

Shown as What it means
ready The task finished its work.
running The task is working now.
waiting for delivery Generation is done; the task is held until delivery is released. Still in flight — not finished.
not started The task hasn't begun, or its status wasn't recorded. Not a failure.
failed The task itself failed.
skipped The task didn't run and didn't fail — often exactly what you configured.
unknown A status we don't recognise. Not counted as a failure.
cancelled The task was cancelled. Not a failure, and not the same as a cancellation that was only requested.

Two of these are worth dwelling on, because they're easy to misread:

  • "waiting for delivery" is not "done." The work finished, the sending hasn't happened yet. A report sitting here still has something owed.
  • "not started" is not "failed." A task whose status was never recorded shows up honestly as not started. It is never folded into the failed count.

While a mail merge is still expanding

A mail merge doesn't know its own size until it has expanded its rows. Until then the total genuinely isn't known, so the line reads:

8 tasks ready (total still being calculated)

rather than inventing a denominator from the rows that happen to exist so far. Once expansion settles, the total appears.

A run that queued no tasks at all — nothing matched its filter, say — reads No tasks to run. That's a statement of fact, not a warning.

The state of each task

Each row in Task Executions now carries its own state, so you can see which task is doing what rather than reading it off the run's totals.

Most rows show the plain reading of the task's own status:

Shown as What it means
Queued The task hasn't started yet. It doesn't say what it's waiting for — naming a cause we haven't recorded would be a guess.
Running The task has been picked up and isn't finished. It may be working or still waiting to start; the row doesn't say which unless the run recorded why it's waiting (see below), and it doesn't claim which stage the work is in.
Completed The task finished its work.
Failed The task itself failed.
Cancelled The task was cancelled.
Not started No status was recorded, or one we don't recognise. Not a failure, and shown in words rather than left blank — a blank cell reads as "nothing is happening".

Two further states say more, and only when the run recorded an event saying so:

  • Waiting for its turn — the task is ready, but a limit it uses is full: another step that uses the same limit is still running. The limit can be shared. This doesn't tell you when the task will start, or which step it's waiting for.
  • Exporting — Tableau is working on the export. This is shown only for Tableau exports.

Exporting is the only stage currently recorded. Other kinds of work — preparing inputs, processing a file, saving an artifact, sending — aren't reported at stage level yet, so their rows show Running instead. That's deliberate rather than an omission: a row says only what the run actually recorded, and labelling a SQL step "Exporting" because it happens to be running would point you at Tableau for a problem that isn't there.

A finished row keeps its outcome. Once a task is Completed, Failed or Cancelled, that stands — it never reverts to showing a stage it passed through earlier.

When a row can't be matched to its evidence

Stage evidence is recorded against a specific task and attempt. On a row where the attempt isn't known, there's nothing to match the evidence to, so the row falls back to the plain status reading — Running rather than Exporting. The same happens when a row's block type isn't recorded: Exporting needs to know the task is a Tableau export. The row is still correct; it's simply saying less. The same is true on historical runs, which predate this recording entirely.

What the run is waiting on

When a run is held up, Progress lists what's holding it, with a task count — for example Tasks waiting — 2 tasks; elapsed time unavailable. Why an individual task is waiting shows on its own row (see The state of each task).

Blockers are only listed when that information was recorded. An empty list means we have nothing to report, not that everything is healthy. If the count or the elapsed time isn't available, Progress says so in that spot instead of printing a zero.

When something fails

If the run recorded a failure, Progress shows it as a short reason, with the attempt number when one was recorded — for example The Tableau export failed (attempt 2).

The reason is drawn from a fixed set of known causes, never from raw upstream error text, so it won't leak query text, recipient addresses or filter values. If the recorded reason isn't one we recognise, you'll see The run failed — reason unavailable rather than a guess at the cause. For the full error detail, open Task Executions or Logs.

Progress reports what was recorded. It won't tell you a database or an upstream system is slow — that's a diagnosis, and it isn't one the run records can support.

"Unavailable" is an answer, not an error

You'll see the word unavailable in places where a number could have gone: Counts unavailable, task count unavailable, elapsed time unavailable, Last update unavailable.

This is deliberate, and it isn't a bug or a loading state. It means that particular fact wasn't recorded for this run. Showing 0 instead would be a claim — "nothing is blocked", "no time has passed" — and a wrong one. A missing fact is shown as missing.

So Counts unavailable means we couldn't produce the counts, not that nothing has happened.

Staying current, and losing the connection

Progress updates while the run is active and shows when it last refreshed (Updated 12s ago). Updates slow down while the tab is in the background and pick back up when you return.

If updates stop arriving, a banner appears:

  • Not updating — retrying. Refreshing is being retried.
  • Not updating — showing the last known state. Report execution does not depend on this page. The page can't reach the server, so what you're looking at is the last state we received.

Neither banner means your report failed. They describe this page's connection, not the run. Reports execute on our servers: closing the tab, losing your network or putting your laptop to sleep doesn't pause, cancel or break a running report. Equally, while disconnected we can't tell you what the run is doing now — it may since have finished, failed or been cancelled.

Once a run reaches its final state the tab stops refreshing and the "last updated" line stops counting up. That's not a lost connection; there's simply nothing further to report. The final counts stay on screen.

What Progress doesn't tell you

  • Whether recipients received anything. Ready tasks are not confirmed deliveries. Per-destination delivery state is not available on this tab, and Progress reports it as unavailable rather than inferring it from the run's status — a run finishing successfully doesn't establish that any given destination was accepted. To see whether a run actually sent, use Delivery Status.
  • What stage a non-Tableau task is in. Only Tableau exports report a stage (Exporting). Every other kind of work shows as Running while it's active, or Waiting for its turn when a limit it uses is full — see The state of each task.
  • Which iteration of a mail merge is still running. A run that expands into many iterations is summarised as one set of counts. Those counts cover every iteration's tasks — it's the per-iteration breakdown that isn't shown.
  • How far along Tableau is with a single export. A pending export shows as in progress; Tableau doesn't expose its internal rendering progress or a queue position, so we don't invent one.
  • A finish time. See Counts, not a percentage.

There's no retry control on this tab. Re-running is done from the run itself — see Execution Log.