When a thunk has been running for a while and you want to know how it is doing — or you have been asked to "clean it up" — there are several places to look: the work items, the Errors, Cost and Time tabs in Monitor, and the design review. This article tells you which to look at first, and why. Monitor is available to thunk admins — see The Monitor pane: what each tab is for — and running a design review needs the Owner or Admin role on the thunk.
This article has two parts. Concepts explains how to decide what matters most. Details walks through each check in order: where to look, what to look for, and which article to read next.
Concepts
Check what does the most harm first
Problems in a running thunk differ in how much harm they do while nobody notices them. Check them in that order:
Stuck work — work items that have stopped and will not move on their own. Nothing alerts you, and the work is lost until someone acts.
Errors — runs that failed. They are recorded where you can see them, but each one is work that did not finish as designed.
Wrong results — work items that finished but did the wrong thing. Nothing fails, so these are found only by looking at the results.
Design problems — the causes behind the first three, which a design review can point to.
Time — how long the work takes.
Cost — what the work spends on AI.
Time and cost are worth improving, but only once the thunk is doing the right thing: making a thunk that gives wrong results faster or cheaper does not help anyone. Keep notes as you go — a finding in one check often explains another, and the design review in particular tends to explain what you saw in the first three.
Security sits outside this order. A thunk can work perfectly and still hold a password in plain sight or let an incoming email trigger an action nobody approved. Check it on every health check; an exposed secret goes to the top of your list.
Not every failure is an error
An error is a run that the platform could not complete: a tool failed, a model refused, a connection was missing. Errors are recorded and listed on the Errors tab.
Many workflows also have business outcomes that are failures for your process but not errors for the platform: a request handed off to a person, a lookup that found nothing, an output left empty. The step finished normally, so nothing appears on the Errors tab. These are found in the work items' own data, which is why checking results is a separate step from checking errors.
Look at recent work, and at a sample of it
A thunk's history can hold far more work items than you can read. Look at a recent window — the last few days — so that what you find reflects the thunk as it is now, not as it was before its last change. Count how the outcomes fall across that window, then open a few work items of each kind, especially the unusual ones.
A recent window is not the whole picture, though. Rare failures may not happen in a given week, and work that got stuck months ago is not in last week's list at all. So also take a few samples from earlier periods — for example a couple of weeks back, a month or two back, and around the thunk's last change — and compare the counts. A failure that shows up in only one sample is still a finding. When you look for stuck work, look back as far as the work items go, not just over the recent window.
Count every problem, rather than describing the one example you opened: "4 of the 2,000 work items we sampled" says how much a problem matters, and one example does not. Say which samples a count comes from, so nobody reads a sample as the thunk's whole history.
Details
1. Stuck work
Start here, because stuck work does not fix itself.
Is the whole thunk paused? A paused thunk does no work at all. Check Deploy → Pause / Restart. See Pause and restart a thunk.
Which work items are waiting? In the Work Items list, filter the AI Task column to Waiting. The filter also includes Waiting for tool. A work item that is Waiting needs a person — an answer, a decision, or Finish step; one that is Waiting for tool is waiting on a tool, most often a reply on a conversation. Waiting is often the design working as intended; it is a problem when nobody is expected to act, or when the work items have been waiting for days. See What Working, Waiting, and Waiting for tool mean.
Why did a step stop? Open a waiting step and read how its agent ended the run. An agent that pauses for a person when its instructions meant it to finish is an instruction problem, and every work item that takes the same path will stop in the same place. See How an AI agent ends a run.
Work items that never finish. Filter the list on Status to the steps before the end of the workflow, and look for work items that were created long ago. Find out why they stopped before you close them. If stalled work should be closed automatically, set Auto-finish inactive work items after (hours) — it moves them to Final, it does not do the remaining work; see Data retention.
2. Errors
Open Monitor → Errors. The error-rate chart at the top shows how many runs errored each day; the list below it holds the most recent errors, newest first, each with its category, message and remediation note. See Analysis of AI behavior for everything on the tab.
Read the trend before the list. A single error is often a passing failure in an outside system. A rising error rate, or a rate that jumped on the day the thunk changed, is a problem.
Group the errors before reading them one by one. The same error repeated across many work items is one problem with one fix.
Read the category first. It tells you whether the fix is yours (the instructions or tools), an administrator's (a connection or credential), the platform's, or whoever supplied the input. See Troubleshooting Errors.
Open the failed run. Expand it from the error, and use What went wrong? for an explanation of that run. The error you see is often not where the failure started — see Reading a failed run. Find the cause of each group of errors, not just the list: one representative work item per group is usually enough.
Look for tool failures that are not errors. When a tool fails and the step recovers — tries another way, or records that the work needs a person — the run finishes normally and nothing reaches the Errors tab. For each custom tool that reads from or writes to an outside system, open its Call history and look at the calls that failed. See Analysis of AI behavior.
3. Wrong results
Check what the work items actually produced.
Count the outcomes. Filter the Work Items list on the properties that record how each work item ended — a status, a result, a "needs a person" flag — and compare the counts. A share of hand-offs or empty results that is higher than you expect is the finding, even when no single work item looks wrong. To keep a view you will come back to, save it as a report.
Look for values that should not be there. The text "null" or "-" in a field, a list where one value was expected, or an output that disagrees with the property it came from usually means the instructions do not say clearly what to write.
Look for properties nothing fills in. A property that is always empty is either not needed or not mentioned in any step's instructions.
Look for the same request handled twice. Several work items for the same outside record — the same ticket, email or request number — mean the work was done more than once. Count them, and check what the repeated action did the second time: sent a second email, or got an "already done" answer back from the other system.
Look for actions that should not have been taken. A work item where the thunk deleted, sent or updated something although its input argued against it is the most serious kind of wrong result, because the damage is outside the thunk. List each one for the thunk's owner to review; some may need fixing in the other system.
Open a few of each outcome. Read the steps of a typical success, a typical failure, and anything unusual. When an agent did the wrong thing, find the step and the turn where it went wrong. See AI reliability troubleshooting and Analysis of AI behavior.
4. Design review
Run a design review. It checks the thunk's properties, steps and tools for problems that commonly lead to the failures above — a property no step uses, a property whose description does not match its type, a step given inputs its instructions never refer to, a tool whose arguments are not constrained. Read its findings alongside what you found in checks 1–3: a finding about a step you already saw going wrong is the one to fix first. See Workflow Review.
Then read the design yourself for the problems that only show when you know what the thunk is for:
Names that do not match. Instructions that call a property by a different name than the one it has, or refer to a step that does not exist.
Promises the plan does not keep. The thunk's description mentions a step, an email or a lookup that no step does.
A way out of every failure. Every call to an outside system needs a path to a final status when it fails or is refused — usually "failed, needs a person" — rather than leaving the work item stuck. The last step should always be able to finish.
Success only from a real result. A step should record that an action succeeded only from what the action returned, never from a ticket's title, its tags or the request text.
One step per decision. When two steps' instructions both decide the same thing — whether a record exists, whether two names match — they will sooner or later disagree. See How to Write Effective AI Instructions.
Values the agent copies. Wherever the agent copies an id, an amount or a name from one tool's result into another tool or a property, it can change it on the way. Find these places, and look hardest at the ones that drive an action you cannot undo. See AI reliability troubleshooting.
Tools and connections. A connection or tool library the design needs that is not turned on, or a step — often the first — with every tool turned on.
When you fix what you found, turn a few of the work items that went wrong into automated tests, so the fix stays fixed when the thunk changes again.
5. Time
Open Monitor → Time. Find the step that accounts for most of the time, then the work items that were slowest. Separate time you can change (how the step's instructions lead the agent to work) from time you cannot (waiting on a person, the platform's own time). See Time Analysis.
6. Cost
Open Monitor → Cost. Find the step that spends the most per work item and why: a large tool result read on every turn, many turns, or a larger model than the step needs. See Token Costs.
7. Security
Secrets in the design. A password, API key or token typed into a custom tool's address, headers or code, instead of kept in a connection. Treat any you find as already exposed: move it into a connection, and have whoever manages that account replace the secret with a new one.
Only the tools each step needs. Check which steps can call tools that change things — send email, write files, update records in another system — and whether each step needs them. A step with every tool turned on can do far more than its instructions intend.
Outside content near powerful tools. Content from outside — an incoming email, a web page, an uploaded file, a chat message — can contain text written to steer the agent. A step that reads it and can also send, write or delete is the place to look. Its instructions should treat that content as data, and a step that takes an action should run only after a check: a property that classifies the request, and a condition on the step or a human approval. See Secure AI agents.
Who can reach the thunk. The tools it publishes to other thunks or AI agents and who may call them, and who holds the Owner and Admin roles. See Users and access controls.
Personal data. Personal or sensitive details copied into properties, notes or outgoing messages that do not need them, and how long work items are kept. See Data retention.
When the health check turns up problems you want to fix in a thunk that is doing live work, see Improve a live thunk safely.