Every time a trigger fires, Rills creates a run and executes your workflow’s nodes in order. This page covers what a run’s status means, how versioning keeps edits from disrupting running work, and how to inspect and test runs.
#Run lifecycle
A workflow itself is either Active (running normally) or Paused (you’ve manually stopped it). Each individual run moves through these statuses:
| Status | Meaning |
|---|---|
| Pending | The run is created and about to start. |
| Running | Steps are executing. |
| Success | The run finished successfully. |
| Failed | A step failed after its retries were exhausted. |
| Paused | Execution is suspended because the workspace ran out of credits or its subscription lapsed. |
A Paused run preserves its exact position. When the underlying issue clears (credits replenish or billing is fixed), the run resumes from where it left off. No data is lost and no completed steps re-run.
Approval waits don’t get their own run status: while a run is waiting on a Human Review step, the run stays Running and the step is what’s holding.
#Versioning
Each saved version of a workflow is immutable and kept in the workflow’s history. Publishing sets which version is live, and that’s the version new runs execute.
Once a run starts, it stays pinned to the version it began on. Editing and republishing a workflow never disrupts runs already in flight; they finish on the definition they started with. You can always trace which version produced any given run.
To go back to an earlier definition, roll back to a prior version from the workflow’s version history. Rollback makes that version live again for new runs; runs already pinned to another version are unaffected.
#Inspecting runs
Open the Activity tab on a workflow to see every past run with its status, duration, and which trigger started it. You can filter by status or by version.
Click into a run to see it step by step:
- The input and output of each node.
- Errors, with the message for any step that failed.
- Retry attempts for retryable steps.
Failed runs highlight exactly which step failed, so you can jump straight to the problem. To fix a failed run, correct the workflow (or the upstream data) and trigger a fresh run; there’s no partial replay of a half-finished run.
#Test runs
While you’re building, run the workflow from the builder to test it. A test run:
- Uses your current draft, including unsaved changes, not the published version.
- Skips billing, test runs don’t consume credits.
- Skips external side effects, so you can exercise the logic without sending real email, hitting live APIs, or writing to real systems.
- Optionally takes sample trigger data, so you can feed a realistic payload to a webhook, schedule, or inbound-email workflow without waiting for a real event.
Real runs, started by a live trigger, always use the published version and do consume credits and perform real actions.
#Retention
How long run history is kept depends on your plan. See Billing & Credits for your plan’s retention window.
#See also
- Triggers : the six ways a run can start
- Workflows : the node reference and retry policy
- Modes & Confidence : how approval steps pause a run
- Billing & Credits : credits, spending caps, and retention