Skip to main content
When you run a Journey through the Cloud Runner, execution is durable — meaning a run that’s interrupted doesn’t simply disappear. The runner tracks progress, preserves state, and can recover from worker failures without losing the work already done. This page explains the mental model so you know what to expect from cloud runs and why they behave differently from local runs.

​
When to use it

You don’t opt into durable execution separately — it’s the standard behavior of every Cloud Runner run. The concepts here are useful background for:
  • Understanding why cloud runs are suitable for long-running or multi-step journeys.
  • Explaining to teammates why a cloud run that “got interrupted” isn’t necessarily lost.
  • Knowing what to look at when a cloud run shows as in-progress longer than expected.

​
Key concepts

Runs are tracked from dispatch. The moment a cloud run is dispatched, it’s registered as an in-progress run with a unique ID. This record persists regardless of what happens to the worker executing it. Workers execute artifacts. A worker picks up the compiled build artifact and executes it. The artifact is self-contained — it holds the full execution plan, so the worker doesn’t need to call back to Reqflo to know what to do next. Progress is checkpointed. As each step completes, its result is written to the run record. If a worker is interrupted after step 2 of a 5-step journey, the results from steps 1 and 2 are already persisted. Interrupted runs can recover. If a worker fails mid-run, the run record reflects which steps succeeded and where execution stopped. Depending on configuration and the nature of the failure, the run can be retried from the point of interruption or from the beginning. Results are immutable once complete. Once a run finishes — pass or fail — its result record is immutable. Request/response payloads, assertion outcomes, derived values, and logs are stored as evidence and won’t change.

​
How it differs from local runs

Local runs execute on your machine in a single process. If the process is killed, the run is gone — there’s no recovery, no stored result, no evidence. Local runs are great for fast iteration; they’re not designed for reliability at scale. Cloud runs trade a bit of latency for durability. The overhead of dispatching to a worker, checkpointing progress, and storing results is worth it when you need confidence that:
  • The run completed even if something went wrong with a worker.
  • The results are stored and auditable, not just printed to a terminal.
  • Large parallel data-driven runs can scale across many workers simultaneously.

​
Examples

Checking a cloud run by ID If a run takes longer than expected, you can query its status: 
reqflo run checkout-flow --env staging --case "Happy path" --cloud
# Returns a run ID; use it to inspect status
Viewing run history in the editor Cloud run results are visible in the Reqflo UI alongside the journey — each run appears with its artifact, inputs, and full per-step results.