Runs

A run is one execution of a loop. Each time something triggers run() — UI, API, or any other trigger path — the platform creates a new run, captures everything that happens inside it, and keeps it queryable forever.

This page covers what’s recorded per run, the run lifecycle, and how to read the two views in the UI.

What’s captured per run

Field	Description
`id`	A stable identifier for the run. Use this when calling the API to find the run later.
`status`	One of `pending`, `running`, `succeeded`, `failed`. See the table below.
`triggerType`	`user` (UI run), `api_token` (API trigger), or `system` (platform-initiated).
`input`	The trigger’s payload — exactly what was on `event.body` when `run()` was called.
`output`	The value `run()` returned, or the error message if the run failed.
`createdAt`	When the run was queued.
`startedAt`	When `run()` was actually invoked. Differs from `createdAt` if the run sat briefly in the queue.
`completedAt`	When the run finished — successfully or otherwise. `null` while the run is still in flight.

Statuses

Status	Meaning
`pending`	Queued. The platform has accepted the trigger but hasn’t started `run()` yet.
`running`	`run()` is executing — or it’s suspended in a `step.waitForScan` and waiting for an external event.
`succeeded`	`run()` returned without throwing. Whatever it returned is on `output`.
`failed`	An error propagated out of `run()`. The error message is on `output`.

A run is in running as long as the workflow itself hasn’t terminated — including time spent suspended in a wait. While suspended the loop isn’t consuming compute, but the run isn’t done either.

Read the runs list

Each loop has a Runs tab listing every run it’s ever produced, newest first. Each row shows the status, trigger info, and how long the run took. Pick one to drill into the detail page.

The list is the right place to scan for failure spikes, slow runs, or runs that started but haven’t completed.

Read a run’s detail

The detail page is reachable from any row in the runs list. It shows:

The run’s status badge, started-ago timestamp, duration, and CPU time.
A timeline of every step that ran inside it, with each step’s name, status, duration, and recorded metadata. See Steps.
A Restart action that re-triggers the loop with the same input.

Logs emitted during the run are also captured against its runId and are visible on the loop’s Logs tab. See Event logs.

Examples

Find a run by its runId

The API response to a trigger includes the runId:


curl -X POST https://api.ollie.health/loop/$ORG_ID/$LOOP_ID \
  -H "Authorization: Bearer $LOOPS_API_TOKEN" \
  -d '{ "patientId": "abc" }'
 
# → { "runId": "run_…", "workflowInstanceId": "…" }

Use that runId to find the run in the UI — it’s the trailing path segment on the run detail URL.

Restart a failed run

From the run detail page, click Restart. The platform creates a new run with the same input as the original; the original stays in place (it doesn’t get overwritten). Restarted runs use the loop’s currently active version, not the version the original ran against.

For the rules about how versions and runs relate, see Runtime and organizations.