Time Analysis shows how long your thunk's work takes, and helps you find what to change when it takes too long.
This article has two parts. Concepts explains where the time in a run goes and which parts of it are yours to change. Details explains how to tell why a run took the time it did, and how to read the Time tab in Monitor.
Concepts
Where a run's time goes
Each time an AI agent works on a step it makes a run, and a run's time is spent in a few kinds of work:
Model turns — the AI model reading the instructions and the work item's data and deciding what to do next. A turn's time grows with how much it is given to read and how much it writes.
Tool calls — searches, reads, writes, emails and calls to outside systems. A tool call takes as long as the system behind it, and longer when it returns a lot of data.
Nested runs — a custom AI tool is an agent with its own instructions and its own runs. Time spent inside it is governed by that tool's instructions, not the step's.
Waiting on a person — an approval, a reply, or a message a tool sent that is waiting for an answer. This is the work waiting, not the automation being slow.
The platform's own time — waiting in the queue for the platform to pick a run up, setting the step up before the agent starts, saving the results when it finishes, and the platform's overhead between the agent's actions.
A step can also run more than once for one work item: a retry after a failure, a resume after a long-running tool comes back, or a new run after a person replies. Anything a step pays once per run, it pays again each time it runs.
What you can change, and what you cannot
Most of the time in a slow run comes from how the step is written: how many tool calls the instructions lead to, how much each model turn is asked to do, and which tools the step can reach. That is yours to change. Two kinds of time are not:
The platform's own time. Queuing, setting up and wrapping up recur once per run and once per resume. Nothing in your workflow needs to change to reduce them.
Steps running in order. Steps run one after another because each depends on the last. That is how the workflow is meant to work, not something to fix.
Working time and wall clock
Wall clock is the time from start to finish — what your customer experiences. Working time leaves out the waiting: on a person, on a schedule, or for a turn behind other work items. Read working time to make the workflow faster; read wall clock to promise a turnaround.
Details
Why a run takes the time it does
The figures say where the time went. The shape of those figures says why. These are the common shapes, and what each one usually means:
Many calls to the same tool usually means the instructions drive the tool one item at a time. Look for the wording that caused it ("for each supplier…", "check every…"). If nothing in the instructions explains the repetition, the agent chose it. If an enabled tool could do the same work in fewer calls — a batch or list version, or a search that takes several terms at once — the instructions should lead to that one.
A call that repeats an earlier call with the same inputs asked for something the run already had. That is not the outside system being slow: either the instructions sent the agent back for it, or the agent lost track of the earlier result.
One long tool call means the outside system was slow, or the call returned a lot of data. The size of what came back tells you which.
Many short model turns means the agent is taking small steps — usually a sign that the step is being asked to do several things at once.
One long model turn means a large prompt or a hard question. It is not a fault.
Time inside a nested run is spent by that custom AI tool, so its instructions are the next place to look.
A retried call cost the run twice: once for the failure, once for the retry. What the failure cost is worth knowing, not just that it happened.
A step that ran several times usually failed, paused or was restarted. The number of runs is itself the finding — find what drove the repeats. Time between runs, when nothing was running or queued, is the step backing off before a retry or waiting for a trigger; it is not the automation being slow.
Waiting on a person belongs to the work, not to performance. Leave it out when deciding what to speed up.
The platform's own time — queued, setting up, wrapping up, platform overhead — is reported plainly and is not yours to fix. Queuing, setting up and wrapping up are paid once per run and once per resume, so a step that pauses and resumes many times pays them many times. That explains the figure; nothing in your workflow needs to change to reduce it.
When one thing accounts for most of a run, that is the whole story, and it is the one to act on; a part worth a few percent of the run is not worth changing first. If you edited a step's instructions after the run, remember that the run followed the old ones.
Why so long?, beside a run's total and beside a step's time in the workflow plan, explains a run in these terms. See Analysis of AI behavior for how to read it.
Where to find the Time tab
Time Analysis shows how long your thunk's work takes across many work items: what a typical work item takes to get through the workflow, how bad the slow ones get, and which specific work items those were. Use it to find the step that accounts for the time, to set expectations you can promise on, and to tell a workflow that is uniformly slow from one that is usually quick with a few items that stall.
Open your thunk, go to Monitor, and select the Time tab. Monitor is available to thunk admins.
Choosing what you are looking at
Three controls sit at the top, and everything below them follows your choice.
Scope decides whose time you are seeing. The list follows your workflow, and each option shows its median — how long a typical work item takes in that scope, under the Measure you've picked (or — when it has no work items yet):
Whole workflow — the time a work item takes from end to end, across your workflow steps. This is the default.
A single step — one step of your workflow, so you can see what that step alone adds. Steps are listed in the order the workflow runs them and numbered to match — Step 1, Step 2 and so on — so you can find one by where it sits rather than by reading every name.
Setup & automation — work that is not part of your workflow, such as planning it or building a tool. It has run time but no per-item figures, for the reason below, and it is not counted in the whole-workflow figures.
Only the steps of your workflow are numbered. Setup work is grouped into that single Setup & automation entry rather than listed step by step, and the handful of steps behind planning, automation and tool building are listed after the numbered ones, without a number.
Window sets how far back to look: the last 7, 30 or 90 days.
Measure decides whether the figures count the waiting.
Working time — the time your workflow was actually doing something. This is the default. It leaves out the time an item spent waiting its turn behind other work items, held for a scheduled step, or waiting for a person to reply. The moments Thunk spends picking up each run and preparing the step before the AI starts do count, because that is time spent on the item.
Wall clock — the whole end-to-end time, waiting included. This is what a customer experiences from the moment their item arrives to the moment it is finished.
Read working time to improve the workflow; read wall clock to promise a turnaround. A workflow that emails someone and waits for an answer is mostly waiting, and the two figures can be hours apart — which is a fact about the work, not a problem to fix. Working time tells you what the AI and its tools cost you; wall clock tells you what your customer waits.
How long one work item takes
The figures under the controls are the ones to act on: how much time a single work item takes in the scope you picked, measured the way you chose above.
Median — half of your work items are under this. The typical item.
90th pct — 9 in 10 work items are under this.
99th pct — 99 in 100 work items are under this. The items past it are listed below.
Heaviest (or Slowest under wall clock) — the single work item with the most.
Work items — how many work items these figures are based on.
Under Working time, a line beneath the figures says how much waiting was left out — and, if some of your runs are older than this measurement, how many runs it covers. Those older runs still count their waiting as work, so the figures are an upper bound until they age out of the window.
Pick a single step in Scope and the same figures describe what that step takes per work item.
Reading them together
The median is what to quote; the gap to the 90th and 99th is the risk. If the three are close, your workflow is predictable and the median is a fair promise. If the 99th percentile is many times the median, most items are fine and a few take far longer — which is a different problem, and one you fix by looking at those specific items rather than at the workflow as a whole. The list at the bottom names them.
Switching between the two measures is itself a reading. If the median barely moves, your workflow is busy from end to end and the way to speed it up is to make the work cheaper. If it collapses, most of the elapsed time was waiting — for a schedule, for a queue, or for a person — and no amount of tuning the AI will change it. What will is changing what you wait for.
Where the time went
Below the figures, a line divides the working time into three parts: waiting on the AI model, waiting on tools, and everything else a run does. This is the first thing to read when a step is slower than you expect — a step that spends its time in tools has a different problem from one that spends it in the model. See Analysis of AI behavior, which explains that distinction and how to act on it.
If some of your runs are older than this measurement, the line says how many runs it covers, so you know how much of the window it speaks for.
There is no average among these figures, on purpose. A few slow items drag an average far above anything typical, so it would describe none of your work items; the median and the percentiles say what is typical and how bad the slow ones get.
Work items over time
Below the figures, a chart plots every work item in the scope you picked as a dot: across, when the item started; up, how much time it took under your Measure. Three lines run through the dots — each day's median, 90th and 99th percentile — and the items past the 99th percentile are drawn larger, matching the p99 marks in the list at the bottom. Hover a dot to see that item's figure and when it started.
Read it for drift, which the figures above cannot show. A cloud that climbs across the window means the same work is taking longer than it used to; a single column of tall dots means something went wrong at one moment rather than with one kind of work; a flat band means the workflow is steady.
Colour dots by adds a second reading to every dot:
Cache hit rate (the default) — how much of the item's prompt the AI model served from its cache. Dark dots paid full price for their whole prompt. If the tall dots are the dark ones, your prompt is falling out of the cache between runs, which is something you can change.
LLM model — which model the item ran on, so you can see whether the slow items are the ones on a particular model. An item that used more than one model — because an AI tool it called used another — is named by both.
Items recorded before Thunk tracked these are shown grey rather than guessed at.
Plot changes what places each dot up the chart. It is offered when Measure is Working time:
Working time (the default) — how much time the item took.
Per 100 output tokens — the item's working time divided by how much the AI wrote for it, counting the AI tools it called. A work item that wrote twice as much usually takes about twice as long, so on the time plot it looks slow when it was only long. Per 100 output tokens, those items line up with the rest, and an item that was slow for how much it wrote stands out.
Read the two plots together. A tall dot that drops back into the band per token was long, not slow — it wrote more. A dot that stays tall was slow. Colour the dots by LLM model to see whether the slow ones share a model. Tool time is still counted in this figure, so an item that spent its time waiting on tools reads slow per token too; the line under Where the time went tells you which it was.
This plot draws no dot larger as an outlier, because the p99 marks are about time. Items whose runs did not all record how much the AI wrote, or that wrote nothing, are left off, and the chart says how many.
On a very busy thunk, the chart shows an evenly spread sample of the work items rather than every one, and says so beneath it. The shape and the lines still describe the whole window; the list at the bottom still names the heaviest items.
The daily chart
Each column is one calendar day for the scope you picked, in your own time zone — so a column here means the same day as one in the Errors and Cost tabs. It follows your Measure: working time by default, run time under wall clock. Hover a column to see that day's figure. Read it for trend: whether the same work is taking more time than it used to.
The chart totals a day; the figures above describe one item. The chart adds up across steps and across items, so the whole workflow's column is the sum of its steps'. The figures above are per work item and do not add up — items are processed alongside each other, so adding their times together would describe no real stretch of time.
Show changes what each column is:
Total per day (the default) — the day's total, as described above.
Median work item per day — the typical work item that day: the median, under your Measure, of the work items that started that day. It is the same figure as the median line through the dots above, drawn as columns. A day on which no work item started has no column. Use it to tell more work from slower work: if the total climbs while the median stays flat, you are simply doing more.
Runs per day — how many agent runs the day had.
Median work item per day is only offered when the scope has work items — Setup & automation does not.
The heaviest work items
At the bottom is the list this tab exists for: the work items with the most time in the scope, most first — ranked by whichever Measure you picked. Each entry shows both figures, how many runs the item made, and when it started. Click the name to open the item — or, when you are looking at a single step, to open that step on that item.
When you are looking at a single step, each entry also carries Why so long?, which breaks that item's time down run by run without leaving the tab. See Analysis of AI behavior for how to read what it reports.
Items far enough past the rest to count as outliers are marked p99. That verdict follows your Measure too, and the two often disagree — an item that waited a week for one reply is by far your slowest by wall clock and a perfectly ordinary piece of work. When nothing is marked, the list says so: your heaviest items are in line with the rest, which is a good result and not a missing measurement.
Two things an entry tells you at a glance:
A large gap between working time and wall clock means the item spent most of its time waiting rather than being worked on — queued behind other work, waiting on a scheduled step, or waiting for a person to respond.
More than one run means the step retried or paused and resumed. That is often the whole explanation for a slow item, and it is worth opening.
Things worth knowing about the figures
A run still in progress is not counted. It has no duration until it finishes, so it is left out of every figure here rather than counted as instant — otherwise a run that has been stuck for days would look like the fastest thing in your thunk. The tab says how many runs are still going and how long the oldest has been running, which is usually the more useful signal anyway.
Setup & automation has no per-item figures. That work is not done on behalf of any one work item, so there is nothing to divide it by. Select it and you still get its run time — but that time is not included in any whole-workflow figure, because it is not time your workflow spends on a work item.
The window cuts at its edges. A work item that was already being worked on when the window began is measured only on the runs inside the window, so a long-running item can look faster than it was.
A thin sample makes the tail percentiles unreliable. With only a handful of work items, the 90th and 99th percentiles are really just "the heaviest one or two", and the tab says so when that is the case. The median is still meaningful.
Working time is a best estimate, and it only ever leans one way. Thunk subtracts the waiting it can identify — an item held in a queue, waiting on a schedule, or waiting on a reply to a message your workflow sent. Time spent waiting on an outside system that is genuinely working, such as a long API call or a document being generated, counts as work, because it is. Anything Thunk cannot classify counts as work too, so the figure may include a little waiting but never invents a saving. Runs from before this measurement existed count all their waiting as work; the tab says how many of your runs that affects.
Wall clock is still the number to promise on. A work item that sat waiting for a person for a day took a day, whatever the workflow was doing, and that is what your customer experiences. Switch Measure to Wall clock whenever the question is "how long will this take", rather than "how do I make this faster".
Alongside the other Monitor tabs
Time Analysis answers how long; Token Costs answers how much, over the same window and with the same scope picker, so the two can be read side by side. When a step is both slow and expensive, open its heaviest work items and use Why so long? and Analysis of AI behavior to see what those runs actually did — that is usually where the explanation is.