Operate

A run is the saved record of one loop execution. The loop is the reusable plan; the run records what happened when that plan started.

Each run belongs to one loop and captures a specific loop version when the run is created. Editing the loop later does not rewrite the run. A Trigger loop step creates a separate child run rather than making one run span two loops.

The run page is where you answer operational questions:

• What started this work?
• Which step is active or waiting?
• Which steps completed, retried, skipped, or failed?
• What result and artifacts did Mobius save?
• Why did the run stop?

The page records what Mobius and its actions report. For an important external change, also verify the result in the outside system. A successful API response does not prove, for example, that a person read a message.

Inspect a harmless run

You need permission to run a loop in the selected project. Use a loop without external side effects, such as the one-second Sleep loop from Steps.

1. Open Build > Loops and select the test loop.
2. Select Run.
3. On the new run page, wait for the status to become Completed.
4. Open Timeline and confirm the Sleep step is completed.
5. Open Event. A plain manual run normally shows an empty object.
6. Open Meta and confirm the source is the manual run from the app.

Now return to the loop. Select the arrow beside Run, choose Run with event, and enter:

{
  "ticket": {
    "number": "T-104"
  }
}

The second run has a different run ID. Its Event tab should contain the ticket object exactly as saved for that run. This confirms the difference between the data that started a run and the timeline of work that followed.

Read the run page

The header shows the run's title, status, loop, version, timing, limits, and stop details that apply. The tabs divide the record by purpose:

If a loop declares an output mapping, Output shows that rendered object. Otherwise Mobius uses the accumulated step results, keyed by step ID. Failed or cancelled runs may have completed step results on the timeline but do not have a successful final output.

Use a short structured output for facts another system needs. Use an artifact for a report, export, or other file.

Status and stop reason are different

A run has one of six statuses:

The status tells you the lifecycle state. The stop reason explains why a final run reached that state. Every final run records one stop reason. Examples include step_failed, check_failed, cancelled, replaced, budget_exceeded, and wall_clock_exceeded.

A configured limit doing its job still leaves the work incomplete and gives the run a failed status. Read the limit banner for the value used and the available recovery action.

Queued is not suspended

Both statuses involve waiting, but they have different consequences:

• A queued run has not begun step execution. The loop version is already fixed, but the run's wall-clock deadline begins only when it is promoted to running.
• A suspended run has already started. Completed steps remain saved, and the wall-clock deadline continues while the current step waits.

The run header and active timeline item explain the current wait. If a suspended run remains open longer than expected, compare its wait or expiry time with the loop's time limit instead of assuming it is healthy or stuck.

Runs and agent sessions

A run and an agent session answer different questions.

An Agent step can create or reuse a session according to its history settings. One run may therefore refer to more than one session, and a reused session may also contain turns from another run. Open the run to diagnose workflow progress. Open the linked session when you need the agent transcript and tool details. A session does not expose private model reasoning.

Give runs useful titles

By default, a run uses the loop name. In the loop editor, Run title template and Run description template can insert values from event, meta, and config.

For example:

Review ticket #${{ event.ticket.number }}

Use only the identifying detail operators need. Titles appear in shared run lists, so avoid secrets or unnecessary customer data. Automation should use the stable run ID rather than treating the display title as unique.

Recover a failed run

Do not resume every failure automatically. A failed step may have changed an outside system before its response was lost.

1. Read the failure banner, stop reason, and failing timeline step.
2. Check whether that step already sent or changed anything outside Mobius.
3. Fix the specific dependency, such as reconnecting the integration or bringing the required worker online.
4. Use the recovery action shown by the run page.
5. Verify both the final run status and any external side effect.

The available action depends on the failure:

• Resume run continues the same run on its original loop version. Completed step checkpoints keep their saved results. The first unfinished step starts again from the top.
• Raise limit & resume asks for a higher budget, agent-turn limit, or extra wall-clock time, then continues the same run.
• Run again creates a new run from the first step. From a failed run page, it copies the prior event and configuration but uses the loop's current saved version.
• Review loop or Edit limits lets you change the plan before starting a new run.

The resume confirmation shows the restart step, loop version, remaining headroom, and next attempt number. Stop if the named step is not safe to repeat. Mobius preserves completed checkpoints, but it cannot know whether a failed external request partially succeeded.

After resuming, confirm that the attempt number increased, earlier completed steps remained completed, the expected step restarted, and the run ultimately reached Completed. Then check the outside system for duplicate or missing effects.

Use Run again when you changed the loop or want every step to execute again. To change the event data too, return to the loop and use Run with event instead of the failed run's Run again action.

See Recover a failed run for the complete cause-to-action guide.

Cancel an active run

Select Cancel in the run header when continuing would be unsafe or no longer useful. The app records that it was cancelled from the run console. The API also lets a caller supply a reason.

Wait for the status to become Cancelled and confirm the cancellation event on the timeline. Cancellation stops Mobius from starting remaining steps and closes its pending waits. It does not undo completed work, and an external request that was already accepted may still finish. Verify consequential systems separately.

A cancelled run cannot be resumed. Start a new run if the work becomes useful again.

API and CLI

Use the CLI command reference for starting, listing, inspecting, cancelling, and recovering runs from a terminal. Use the interactive API reference for the exact request bodies, permissions, status codes, event pagination, and replayable event stream.

Next

• Define the reusable plan with loops.
• Choose observable boundaries with steps.
• Define automatic starts with triggers.
• Diagnose private execution in workers and connect a worker.
• Diagnose and repair a failure with Recover a failed run.