Run, watch, recover

An integration is not finished when it runs once. This group is the part that matters at 03:00: what a run leaves behind, how a failing step behaves, what happens to a firing that never became a run, and how to find out who changed what.

The pages

• Runs — the run list and a run's detail, the per-step timeline with each step's real input and output, and the actions available on a run in flight or a run that failed.
• Failure handling — retry with its attempts, backoff and strategy; onError and the reserved error port; timeoutSeconds; and the deliberate Stop and Error.
• Missed runs — a trigger fired but no run was created. Where those land, how to replay one, and when to discard it.
• Revisions and audit — reading a workflow's history, restoring an earlier revision and what a restore does not carry, and what the audit log records.

Design for the failure before you ship

Three habits separate an integration you can operate from one you cannot:

1. Route failures rather than failing runs, so a broken import becomes "the file moved to the failed folder and the run finished" instead of a red run nobody notices. See Failure handling.
2. Make writes idempotent, because both schedules and events are at-least-once and a retried caller can start the same work twice.
3. Make failures visible on your side. A fire-and-forget webhook caller never sees a workflow failure, and nobody watches a run list all day. Wire an error branch that notifies somebody.