Run
Runs
A run is one execution of a loop. It is the place to understand what happened, follow active work, inspect the result, and decide what to do when something fails.
The loop is the reusable plan. The run is a durable record of one attempt with one set of inputs. That distinction lets you improve future work without rewriting the history of work already in progress or complete.
Read a run as a story
A useful run answers five questions:
| Question | Where to look |
|---|---|
| Why did this start? | The trigger and input |
| What is happening now? | The current step and timeline |
| What decisions or side effects happened? | Step events and saved output |
| What did the work produce? | Run output and artifacts |
| Why did it stop? | The final event and stop reason |
This makes the run page the main operator view for repeatable work. You do not need to understand the runtime machinery before you can diagnose most problems.
Runs and sessions remember different things
A run preserves process state. An agent session preserves conversation context.
An agent step can use a session inside a run, but the two records have different jobs. Open the run to see whether the process advanced. Open the session to see what the agent and user said, which tools the agent used, and what context it carried forward.
The timeline shows responsibility
Each step appears on the timeline as it starts, waits, retries, completes, or fails. The timeline is most useful when steps have clear names and responsibilities.
A waiting run is often healthy. It may be waiting for a timer, provider event, worker, or interaction. Open the active step to see who or what owns the next move.
The exact event vocabulary is available in the event catalog when an application needs to consume the same timeline.
Input, output, and artifacts
Input explains the subject of the run: the account to enrich, pull request to review, or topic to summarize. Step results show how information moved through the process.
The run output is the loop's declared result. Use it for small structured values that another system or operator needs. Use artifacts for files and other durable deliverables.
Naming runs after their subject makes lists easier to scan. “Review pull request #418” is more useful than repeating the loop name or status.
Active, waiting, and finished work
Runs spend most of their life in one of three conceptual states:
- Active: Mobius or a worker is doing the next step.
- Waiting: the run is queued or suspended until capacity, time, an event, or a response is available.
- Finished: the run completed, failed, or was cancelled.
The exact status tells you what Mobius is doing. The stop reason tells you why finished work ended. Start with the plain-language explanation on the run page; use event and API details only when integrating or diagnosing a deeper issue.
Recover or start again
Resume a failed run when the loop is still correct and an external problem has been fixed, such as reconnecting an integration or restoring a worker. Mobius keeps completed step results and continues from the first unfinished part.
Start a new run when you changed the loop, changed the input, or want the whole process to execute again. This avoids mixing a new plan with an old attempt.
Completed side effects are not rolled back. Before resuming work that changes another system, confirm that the action can safely run again. See recover a failed run for the full decision path.
Cancel obsolete or unsafe work
Cancel a run when its result is no longer useful or continuing would be unsafe. Record a reason so the timeline explains the operator decision.
Cancellation stops future work and closes open waits. It does not undo a Slack message, GitHub change, or other external side effect that already happened.
Inspect runs in the app
Open Runtime > Runs or choose a recent run from a loop page. Start with the timeline, then inspect input, output, and artifacts as needed.
When a run fails, read the failing step and final stop reason before editing the loop. Many failures come from a disconnected integration, unavailable worker, expired limit, or unanswered interaction rather than from the process definition itself.
Use the CLI command reference for terminal operation and the interactive API reference for creation, event pagination, cancellation, and recovery.
Next
- Define repeatable work with loops.
- Choose meaningful boundaries with steps.
- Interpret waiting work with interactions and workers.
- Recover interrupted work with recover a failed run.