Smart Order Capture
Core concepts

Runs and run history

Every execution of a workflow produces a run. Runs have a status, a trace, and a retention window. The dashboard surfaces them in real time.

What's in a run

  • id — UUID assigned by the device, idempotent across upload retries.
  • workflowId and workflowVersionId — what was running and which version.
  • deviceId — which paired phone produced it.
  • status — queued, running, success, failed, cancelled.
  • startedAt, endedAt — ISO-8601 timestamps in UTC.
  • trace — an ordered list of trace events; one per node executed.
  • errorMessage — populated when status is failed.

Trace events

Each trace event records which node ran, what kind it was (e.g. action.tapByText), the outcome (ok / skipped / failed), an optional message, and the wall-clock duration. The trace is what the dashboard renders when you click a run.

Note
Trace shape is the same one the in-builder simulator produces. CI golden-tests parity between the TypeScript and Kotlin interpreters so what you see in the builder preview matches what your phone actually does.

Where runs are stored

Runs are written to a local Room database on the device first, then uploaded to the cloud via runs.report. If the device is offline, runs queue locally and upload when network returns. The local queue is durable across reboots and app restarts.

Retention

Each user has a runRetentionDays setting (default 30). A background job prunes runs older than the configured window. Free plan caps the maximum retention; Pro and Team unlock longer windows.

Real-time updates

The dashboard subscribes to run.updated via Server-Sent Events. When a run finishes on your phone and uploads to the cloud, the activity feed updates within a second, no refresh needed.

Debugging a failed run

  1. Open the run from the dashboard or the Runs page.
  2. Read the trace. The last event with outcome: "failed" is your culprit.
  3. Common causes: a target text element didn't exist on screen (tap by text with no match), the targeted app wasn't installed, an HTTP call returned non-2xx, or the run exceeded the 10-minute hard cap.
Heads up
Denylist violations also produce a failed run with a clear error message. The Kotlin interpreter refuses to dispatch any UI action whose target package is on the denylist, even if the workflow somehow slipped past server validation.

Exporting runs

Pro and Team plans can export the last 90 days of runs as JSON from Settings → Data export. Free plan can export the last 30 days. Useful for offline analysis or for moving data into a spreadsheet.