Skip to main content
Execution begins only after validation and permission review. The runner receives a concrete revision, resolves its trigger and input bindings, and records one node-execution result for every completed, failed, skipped, or cancelled step.

​
From click to evidence

  1. sndbox saves or selects the exact workflow revision.
  2. Validation checks the graph, configuration, bindings, connections, and permissions.
  3. The scheduler or operator creates an execution with a trigger payload.
  4. A compatible runner claims the work and resolves each node’s inputs immediately before it runs.
  5. Node status, redacted input, output, logs, duration, branch, retry count, and artifacts are checkpointed.
  6. Terminal status records whether the run succeeded, failed, was cancelled, was skipped, or needs recovery review.
A queued execution has not started its first node. A running execution can already have produced external effects, so cancellation and retry decisions must use the timeline rather than only the final status.

​
Choose a target

Desktop local runner

Run personal workflows, local schedules, files, commands, and managed browser sessions on this computer.

Self-hosted runner

Pair a Linux x86-64 or ARM64 runner inside infrastructure you control.

Runner pools

Route workspace work by environment, compatibility, capacity, tags, region, and strategy.

Durable scheduling

Persist occurrences and retry queue delivery without silently duplicating a scheduled event.

​
Revision and permission identity

The executable definition is not just a workflow ID. Local history records the workflow version; remote commands carry the approved revision identity and content hash. Runners apply the signed authorization context and their own path, network, environment, and capability restrictions before claiming work. Editing the canvas after a run does not rewrite its history. Compare the execution’s saved revision with the current draft when configuration appears inconsistent. Material changes can also invalidate revision-bound approval, even if the workflow keeps the same name and ID.

​
Inspect, then recover

Use the execution timeline to understand what completed and whether a side effect may have occurred. Recovery distinguishes safe retry, reusable idempotency, uncertain outcome, and manual review instead of claiming every run is exactly once.

​
Read the timeline

Use Logs and evidence for the recorded surface and Retries and recovery before repeating uncertain work.