Runs and Logs
Dispatch automation runs, inspect status and cost, follow live output, and diagnose blocked or failed work.
Every automation dispatch creates a run record with its trigger, repository, issue or pull request target, runtime, model, sandbox, resource usage, timestamps, status, and any recorded error.
View run history
Open Settings > Automations, select an installed automation, and use Recent runs in the editor. Select a row to open the full runs view and its detail sheet.
The full view supports:
- Search across run titles and trigger names.
- Filters for status, trigger, and runtime.
- Sorting by newest, oldest, duration, or credits.
- Status summaries for all, active, succeeded, and failed or blocked runs.
- A detail sheet with runtime, model, duration, credits, container seconds, timestamps, trigger, run ID, sandbox ID, errors, and steps.
Run rows are also shown on related issue and pull request surfaces when a target snapshot is available.
Run states
| State | Meaning |
|---|---|
queued | The dispatch was accepted and is waiting for orchestration or workspace capacity. |
running | A sandbox is executing the selected runtime and model. |
succeeded | The agent process completed successfully. |
failed | The agent, sandbox, timeout, or orchestration path ended with an error. |
blocked | The run could not proceed because a precondition or policy prevented execution. |
cancelled | Cancellation was recorded before normal completion. |
The detail sheet shows errorCode and errorMessage when available. Treat those fields as the primary diagnosis rather than inferring a cause from status alone.
Dispatch a manual run
Open an existing automation and select Run. The automation must be enabled, and any selected repository must remain inside the saved repository scope.
The dialog derives the context it needs from the automation's triggers:
| Trigger type | Manual context |
|---|---|
| Pull request or review requested | Repository and pull request |
| Issue | Repository and issue |
| Comment or bot mention | Repository, issue or pull request target, and a comment body |
| CI | Repository and pull request when applicable |
| Repository pushed | Repository and Git ref, such as refs/heads/main |
| Manual, repository-created, or schedule-only | Repository context when one is available; no subject is required |
If an automation has several compatible trigger types, choose the subject kind in the dialog. Schedule-only automations with one eligible repository dispatch directly with that repository; broader scopes ask you to choose one.
The dispatch response includes a run ID immediately, but the durable run row is inserted asynchronously. The dashboard shows a Dispatching placeholder until the row appears.
Manual dispatch is dashboard-only
Trylle CLI 1.1.4 has no command to manually run an automation. The CLI can list existing runs after they are recorded.
Inspect runs from the CLI
Find an automation ID, then list its recent runs:
try automation list --account OWNER
try automation runs AUTOMATION_ID
try automation runs AUTOMATION_ID --limit 20The CLI currently provides a run list, not a dedicated single-run view. It also cannot stream or retrieve automation logs.
Read live and completed logs
For an active run, the dashboard streams stdout and stderr through a server-sent event connection. Output may be empty while the sandbox starts, and the live buffer can be truncated when a run produces a large amount of output.
After a run reaches a terminal state, the dashboard switches to retained log artifacts. The Steps panel parses agent messages, reasoning events, tool calls, results, and ordinary process output. Rendering is bounded so very large logs do not lock the page; use the error fields and final output together when the visible step list is incomplete.
Logs can contain repository contents, command output, issue or pull request text, and data printed by tools. Do not instruct an automation to echo credentials. Secret handling and masking should be treated as defense in depth, not permission to print a token.
Diagnose a blocked or failed run
Check these in order:
- Error code and message: open the run detail sheet before changing the definition.
- Automation state: a disabled automation rejects manual dispatch and no longer matches new automatic events.
- Bot installation: confirm the selected bot is still installed on the immutable automation workspace and is Ready.
- Repository scope: confirm the event repository belongs to the workspace and remains in the automation scope.
- Permissions: confirm the bot has every required scope and the automation did not narrow one away.
- AI balance: insufficient funds or an insolvent account can prevent a hosted model run from proceeding.
- Runtime limit: a new custom automation defaults to 15 minutes; timeouts are recorded as failed runs.
- Agent output: inspect the final tool result, stderr, and exit-related error code for command or model failures.
Failed work can still consume AI credit when the model already processed tokens. See AI usage for the metering model.
Disable future runs
To prevent new event, schedule, and manual dispatches while you investigate:
try automation disable AUTOMATION_IDRe-enable it after correcting the definition or account state:
try automation enable AUTOMATION_IDDisabling does not cancel an already queued or running record.
Cancellation boundary
The run model includes a cancelled terminal state, but the current dashboard and Trylle CLI 1.1.4 do not expose a run cancellation control. A cancelled record can still appear when cancellation is initiated by platform lifecycle or orchestration handling.
The CLI also cannot create, edit, delete, or manually run an automation, and it cannot retrieve automation logs. Use the dashboard for the run and log workflows it currently exposes.