Runs and traces
What is recorded for every execution, what is redacted, and how to read it.
A run is one execution of a routine. Its trace is the reason you can trust a routine you are not watching.
What a run records
| Field | Meaning |
|---|---|
state | Where the run is in its lifecycle. |
trigger | manual, api, or schedule. |
model | The model identifier used for this execution. |
output | Final text result, truncated at 100,000 characters. |
error | Category, message, and whether the category is retryable. |
usage | Input, output, and total tokens, plus cost when reported. |
steps | The ordered trace, described below. |
startedAt, completedAt, createdAt | Timestamps for queueing, start, and finish. |
The trace
Steps are ordered by sequence and come in four kinds:
| Kind | Carries |
|---|---|
model | Model identifier, duration, and token usage for that turn. |
tool_call | The tool name and the arguments the model sent. |
tool_result | What the MCP server returned. |
error | The error category and a redacted message. |
Tool names in the trace are prefixed with the connection slug —
github__list_commits rather than list_commits — so a trace is unambiguous
when two servers expose the same tool name.
Reading a trace well
Read the tool_call steps before the final output. The output tells you what
the model concluded; the tool calls tell you what it actually looked at. A
persuasive result produced with no tool calls is a generated opinion, and for
audit and reporting routines that is the failure mode to watch for.
Redaction
Step inputs and outputs pass through redaction before they are persisted, so common secret shapes do not end up in the record. Error messages are redacted on the same path.
Redaction is a safety net, not a licence: do not put secrets in instructions or variables. Credentials belong in connection headers, where they are encrypted at rest and resolved server-side at call time — the model never sees them.
Usage and cost
Token usage is recorded per step and aggregated on the run. Cost is recorded
when the gateway reports it, and is null when it does not. Usage is the
practical way to size limits: a routine that consistently spends most of its
step budget will fail the week its input grows.
Retention and history
Runs are not deleted when a routine is paused or archived. History outlives the routine's schedule on purpose — the record of what ran, with what tools, and what it produced, is the audit trail.
Where runs come from
- Manual — Run now in the dashboard. Only a successful manual run satisfies the activation requirement.
- API —
POST /v1/routines/:routineId/runwith a key holdingruns:write. - Schedule — the operations tick claims routines whose next occurrence has passed, once activated.
All three execute identically. Nothing about a scheduled run is more or less permissive than a manual one.