Runs and observability

A run is one execution of one workflow. It is pinned to the exact workflow version that produced it, so a run you open next month shows you what the workflow did then, not what the workflow says now.

Runs are recorded the same way whether an agent worked through the job step by step or the codified version ran it on autopilot. Going autonomous changes how the work happens. It does not change whether the work is written down.

Finding a run

The Runs screen lists every run across every workflow, newest first. You can narrow it to one workflow, and to one of: Running, Waiting on you, Completed, Failed, or Queued. Click a row and it expands onto what the run produced, with a link through to the run itself.

Each row carries the workflow it belongs to, its mode (agentic for a run an agent worked through, operational for one the codified workflow executed), its status, and when it started. A finished run names what triggered it, unless it was a test fire, which carries a test chip instead. A run that is still going shows a green pulse with the name of the tool it is inside right now.

The Queued view is per workflow and shows the other half of the picture: work that is lined up but has not started, work parked because a spend limit was reached, and triggers that failed before any run existed. A trigger that dies at the door has no run page, so this is where you find it.

What a run records

Open a run and the header states the facts that explain its behaviour:

• Status. Running, Waiting on you, Resuming, Completed, Failed, Rejected, or Cancelled after you stopped it.
• The model it ran on, with the thinking effort it used. This is what the run was stamped with when it was dispatched, not what the workflow says today. A run that sat on an approval overnight resumes as the same agent that suspended, even if you changed the workflow's model in between.
• What it cost, estimated from the tokens the run actually recorded at published OpenAI prices. On your own key that amount is part of your OpenAI bill rather than an extra charge from us. If the model has no published price, you see the token count instead of a dollar figure. We never show a number we guessed.
• A test badge if this was a test fire rather than a real one.

Below that sits the run itself: its result, its complete timeline, the transcript the model saw, and any files or recordings it left behind. For a codified run there is also a read-only canvas of the steps it executed. The timeline opens with the trigger that started the run, so what set it off is the first thing you read.

What "replay" means here

You can re-open any run at any time and read every recorded fact about it in order. The record is append-only and immutable, and nothing later rewrites it. For a run that drove a browser, you can also watch the video of the session in the page.

What does not exist is a button that re-executes a past run. There is no "run this again" and no step-by-step scrubber. If you want the same work done again you fire the workflow again, and that is a new run with its own record. The closest thing to re-running a specific case is pinning that run's payload from the workflow's payload library and firing a test with it.

What is not visible

We would rather tell you the gaps than let you find them:

• A run has no single duration. Timings are per tool call and per codified step attempt, measured where the work happened. There is no total on the run.
• Hosted tools report no duration. Web search, file search, the code interpreter and image generation fire no timing hooks, so their rows show what they did and no elapsed time. A synthesized number would be one you trusted and we invented.
• Stopping a run bounds what it records, not what it already sent. See Stopping a run.