Monitor runs

The run monitor is the operational record for agent and workflow execution.

Read the status

Open Runs and filter by status. Beyond the finished states — Completed, Failed, and Cancelled — a run's badge tells work that is moving from work that has stopped and is waiting:

• Pending and Running — execution is under way. Running means work is in progress; it does not guarantee useful output yet.
• Queued — the workspace was already running as many runs as it can. The run waits its turn and starts on its own when a slot frees; you don't need to do anything. If its agent is paused, the person who started it leaves the workspace, the schedule or webhook that started it is turned off, or the thread it answers closes while it waits, it fails instead of starting. If that thread was only paused, the request it was answering waits and is taken up again when the thread resumes.
• Awaiting Your Reply, Awaiting Approval, and Awaiting Tools Approval — the run stopped and needs a person: to answer a question, approve a tool call, or approve the tools an unattended run will use. It waits until someone responds; see answer a waiting run.
• Paused — Limit — the run reached a daily limit, a budget, or the daily free allowance. Resume it once there's room again; daily limits and the allowance reset at midnight UTC. The same badge shows while a run waits for sandbox capacity, or for the AI model's provider, which is limiting how often the agent can send it requests. Those waits clear on their own: the run continues where it stopped, without you, once capacity frees or the provider's limit resets at the time the run shows. If the provider keeps limiting the same step, the run fails instead of waiting longer.
• Paused — Recovery Needed — the run couldn't safely save its progress and stopped. Resume it to try again.
• Paused and Paused for Replan — execution is suspended and can be picked back up.

The status filter lists the same states; a queued run is listed under Pending.

Failed runs, and runs that are paused or waiting for a person, are counted in the badge on Runs in the sidebar, so you do not have to watch the filter to notice them. Paused and waiting runs count for as long as they wait, except a run waiting for sandbox capacity or a model provider's limit, which continues on its own. A failed run counts for 7 days after it finishes, then drops off the badge but stays listed under Runs. A failed step inside a workflow counts once, as its workflow run. A paused or waiting run uses no resources while it waits.

Attribute runs to projects and cost centers

In a shared workspace, Runs also filters by Project, Ticket, and Cost center. These are free-text tags recorded on the run when it starts. There is no list to pick from, so a workspace only gets a useful breakdown if people spell them the same way — agree on the values before you rely on the filters.

Where a tag is set depends on how the run started:

• Agent and workflow runs — fill in Project, Ticket, and Cost center on the run launcher before starting the run.
• Schedules and inbound webhooks — set the tags on the trigger itself, when you create or edit it. Every fire copies them onto the run it starts, so a recurring job is tagged once rather than once per occurrence.
• API calls — send project_tag, ticket_tag, and cost_center_tag in the request body of Run an agent or Run a workflow.

Runs started from a chat carry no tags. Child runs inherit their parent's, so tagging the top of a fan-out tags everything beneath it.

Tags are fixed once a run starts — there is no way to re-tag finished work, so a misspelling stays in the record. They also affect nothing operational: no budget, limit, or approval reads them. Admins and owners can download the breakdown from Analytics under Spend attribution, which groups spend by the same three tags.

Read the verification result

Execution status and verification status answer separate questions:

• Completed · Checks passed — execution finished and every required result check passed.
• Completed · Not checked — execution finished, but no configured result check confirmed the output.
• Failed, with Checks failed under Result checks — execution reached a result, but at least one required check rejected it.

Output-schema checks run only when execution has produced an otherwise successful terminal answer. A mismatch fails the run and records verification_failed. Pauses, cancellations, provider outages, tool failures, and other operational failures stop before output verification, so they remain not_evaluated rather than becoming schema failures.

Runs configured with Require the run to create a file have a separate required File created check. In the API, the setting is require_artifact=true and the check is named artifact_requirement. Creating at least one downloadable file passes it; finishing without a file fails the run and records verification_failed. When a run also has an output schema, both checks must pass. Creating a file when it is not required, or providing files from earlier runs, does not add this check.

Open a run's Result checks section to see which checks ran, whether each check was required or advisory, and when it ran. An output-schema check confirms that the final answer matches the configured schema.

Failed schema checks show property paths and constraint names without exposing the rejected values. A passing schema check proves structure only. It does not establish factual accuracy, sound reasoning, or task quality.

The File created check lists the files that satisfied the requirement when the run finished. Deleting a file later does not change that historical result.

An agent's completion contract can also include a rubric: written criteria a separate model checks the run's answer against. An unmet criterion counts as a required check that failed: the agent is told which criteria it missed and tries again, and a run whose answer still misses one fails with verification.completion_failed. A met rubric shows as an advisory check, since a model's judgment never makes a run Checks passed by itself. If the answer couldn't be graded, the rubric shows as not evaluated and claims nothing. Grading is charged to the run.

Analytics keeps the two signals separate (Home doesn't show these rates):

• Completion rate is completed runs divided by completed plus failed runs. Cancelled runs are excluded.
• Results passing checks is runs whose required checks passed divided by completed runs. Completed runs with no applicable checks reduce this rate.

Its By agent breakdown and the agent filter cover only agents you can view: an agent you can't view isn't listed and reports nothing. An agent's figures also leave out other members' private runs, their chats and their runs of their own private agents, even for admins. The same goes for the run count, cost and last run beside each agent on Agents, and for the order of Recently Run on Agents and Workflows. The workspace's totals still count every run, so they can be more than the agents listed add up to.

See how often runs need a person

The Autonomy tab of Analytics shows how often top-level runs finish without a person stepping in, how often they need one or have to make a new plan, and what first made them need one. Filter it by agent, or by Started from: Chat, Schedule, Webhook or Google Trigger, or Other.

The Autonomy tab of Analytics counts only runs you can see: runs of agents and workflows you can view. Other people's private runs, their chats and their runs of their own private agents, are never counted, even for admins.

Follow an agent's steps

When an agent works on something with several steps, it keeps a list of them as it goes: what it has done, the step it is on, and what is left. In a chat the list sits under the agent's latest reply and changes as the agent works. On a run's page it is under Steps. A quick answer usually has no list.

The agent writes the list itself, so a step marked done is the agent's own account of its progress, not a result check; see read the verification result. A run that pauses and resumes picks up from the same list.

In the API, Get run progress returns the list in order as semantic_progress.steps, each step with a status of completed, in_progress, or pending.

Inspect the execution tree

Open a run to see its events and nested calls. The call tree shows which agent or workflow invoked each child, how long it took, and where resources were consumed. Choose a run's number to open that run, or its name to open the agent or workflow it ran.

For workflow runs, the run page lists each step with what it received and returned, the parts of a parallel step, every pass through a loop, and retries. Choose Rerun From Here on a step to repeat a failed or cancelled run from that point.

Under Files created, preview a supported file to inspect it without first downloading it. Choose Add to Knowledge when a trustworthy run file should become reusable source material. Choose who can access the copy and where it belongs. The Knowledge copy remains available independently of the run file and links back to this run.

Images made with Generate an Image appear here too. See generate and edit images for downloading them, making further edits, and reusing them in another run.

Diagnose failures

Start with the first meaningful error, not the final cascade. Check:

• whether the selected model and tools were available;
• whether input matched the expected shape;
• whether the final JSON matched every required output-schema constraint;
• whether required knowledge or credentials existed;
• whether policy, budget, or execution limits blocked the action;
• whether a downstream service failed temporarily.

Answer a waiting run

Home lists the runs waiting for a person under Needs attention: runs whose tools need approving, tool approvals, questions, and runs paused at a limit. A run waiting for sandbox capacity or for a model provider's limit to reset isn't listed and sends no email, since it continues on its own. The list includes waits at any depth, such as a workflow step or a run another agent started, and lists each wait once, on the run that is waiting. In a shared workspace, the ones you can answer are grouped under Waiting on you. Open the run to answer it; for a run started from a chat, you can also answer in the chat. A chat shows only its newest question: when a later turn in the same chat asks one, an earlier question still waiting is withdrawn and its run is cancelled, along with any background runs that turn started, as Cancel would. Tool approvals are never withdrawn this way.

For owners and admins, Needs attention also lists budgets near their limit and automations that keep failing: failed webhook deliveries, webhooks and HTTP tools turned off after repeated failures, and failing schedules and inbound webhooks. Each one links to the page where you fix it. A failed webhook delivery counts for 7 days after it fails; its row opens the Failed deliveries section of Outbound Webhooks, where you can retry it.

Who can answer depends on what the run is waiting for:

• Questions — only the person the run asks: whoever started it, or the member its workflow step names. If that person has left the workspace or become a viewer, a workspace owner or admin can answer instead, or cancel the run.
• Tool approvals — the person the run asks, or a workspace owner or admin.
• A run's tools (Approve tools for this run) — the person who started the run, or a workspace owner or admin.

A private run is the exception. A run is private to its owner when it started in their chat or from their private automation, or when it uses their own accounts and credentials: their runs of their own private agent, from Run, their own schedule or webhook, a thread they opened or an application acting for them. Only the owner can see it, its results and files, and only the owner can answer it, change its approvals or take control of its sandbox. Approving an email or a calendar change is always left to the owner of that Google account, in their own signed-in browser. See use apps.

When a run you started has been waiting for about ten minutes, Guest Machines also emails you. That includes the runs inside it, such as its workflow steps and runs another agent started. One email covers every run newly waiting for you and links to each one, without any of the run's content. Turn these emails off under Profile → Notification preferences → Agent activity → Email.

A run Paused for Replan waits for you too: a guard stopped it (it repeated itself, started too much work, or went outside its plan), or someone else denied its tools. It isn't among the waits above and sends no email, but the person who started it gets a notification until it's resumed, its tools are changed, or it's cancelled. Denying a run's tools yourself sends you none.

A generic Resume cannot supply a missing answer or approval. If the response is recorded but the run cannot restart, follow the recovery message and refresh the run. Do not submit the same decision again.

Control active work

Which controls a run offers depends on why it stopped. Open the run to act on it.

• Cancel — available while a run is active or paused. Use it for work that is no longer useful or is consuming resources unexpectedly. Cancellation can finish asynchronously, so the visible state may take a moment to settle.
• Resume — available on Paused, Paused for Replan, Paused — Recovery Needed, and Paused — Limit runs. Resuming continues without repeating completed work. Fix whatever caused the pause first: a resumed run that hits the same limit pauses again.
• Approve Tools, Deny Tools, or Change Tools — offered on Awaiting Tools Approval runs (Change Tools also on Paused for Replan; denying tools leaves the run Paused for Replan).

Use Audit Log when you need to identify the person or automation account responsible for an action. An entry about an agent, workflow, MCP server or run you can't view is listed without its name or details, for example as "An agent you can't view". Workspace owners and admins still see the names of deleted ones. So is an entry about a thread you can't see in Inbox ("A thread you can't see"), even for admins, and about a Knowledge file you can't view, such as another member's private copy ("A private file"). An API key sees no thread names at all.

Take control of a run's sandbox

A run whose agent has a cloud sandbox shows it under Sandbox. Anyone who can see the run can watch its desktop; only the person in control can use it.

Take Control hands you the sandbox's desktop and a terminal, for a sign-in or anything else only you should enter. You can take control while the run works, from the end of its current step, or while it waits for a person; while it waits for an answer, only the person it asked can. A sandbox that sleeps while the run waits wakes up for you, unless the agent's sandbox setup changed since it started: the run replaces that sandbox at its next step, so it isn't handed over.

Hand Back returns the sandbox to the agent, which is told that someone had control and looks again before it acts. Answering the run's question hands it back too. Control also ends after ten minutes without activity, after an hour, when the workspace's spend limits can't cover more time, or within a minute of you losing access to the run. It also ends when you sign out of the browser you took control from, or sign out everywhere. Your time in control counts as the run's sandbox time.

In a chat, a question from an agent with a desktop offers Open Desktop, which opens the run.

See a run's history

The History section of a run's page lists every time the run changed status, oldest first: when it started, paused (and why), waited for a person, resumed, and ended. It also lists everything people did to it by hand, with who did it, for example "Ali Mahouk (workspace admin) cancelled it". Runs started before history was kept show only their current status. See Full Audit Log opens Audit Log filtered to the run.

Under the run's status, the page also says who last acted on it, for example "Cancelled by Ali Mahouk (workspace admin)". In the run list that note appears when someone other than the person who started the run acted, and a chat whose run a workspace admin or an API key stopped says who stopped it.

Other members' private runs

A run in someone's private chat, or one that uses their own accounts and credentials, is theirs: only they can open it. A link to it shows Run not found or private to anyone else. Workspace owners and admins still see it listed under Runs, marked Private, with its status, when it started, and whose it is, so they can Cancel or Delete it from the list when it is stuck or using resources it shouldn't. Nothing the run contains is shown. These runs count in the list's run total and status tiles, but not in its cost or Need attention tile.

Clear runs

On Runs, open Clear Runs and choose a status group. Clear Paused Runs includes runs awaiting input, approval, or a decision on their tools. Clear All Runs includes every finished and paused run and requires you to type the confirmation phrase shown in the dialog.

Clearing applies across the current workspace to matching runs that existed when clearing began. The list's page, agent, and tag filters do not narrow it. Members can clear only runs they started, and other members' private runs are never cleared. Running and pending runs are excluded, and a run tree can be skipped if a child is still active or a file is still in use.

Confirming permanently deletes eligible runs together with their nested child runs and files. Copy any output you want to keep into Knowledge first; that independent copy survives removal of the original. Deletion cannot be undone.

The dialog reports progress as batches finish. Stop After Batch finishes the current batch and prevents another from starting. Leaving the page also stops after the current batch; neither action restores runs already deleted.

Skipped runs remain listed. If clearing fails, some deletions may already have completed. Retry from the dialog to continue clearing the remaining runs, and address any reported blocker before starting another sweep for skipped runs.