Missed runs

A trigger firing and a run are two different things. A firing that could not become a run is not lost and it is not a failed run — it lands under Integration Studio → Missed runs, with the payload the trigger captured at the moment it fired.

Why a firing does not become a run

The common case is the build. A run is rejected while the workflow's build status is anything other than ready, and that applies to every path in: a schedule firing, an inbound webhook call, an event. A save queues a build, so the window right after a deploy or an edit is exactly when a scheduled firing can land in it. See Execution modes.

The practical consequence: if you are editing a workflow that fires on a schedule, look at Missed runs afterwards. A nightly job saved at 01:59 is the classic way to lose a night.

What is kept

Each entry holds the payload the trigger produced — the request body, query and headers for a webhook; the envelope for an event; the firing context for a schedule. That is what makes a replay meaningful: it is the same input the run would have had, not a reconstruction.

Replay or discard

Two actions:

• Replay creates a run from the captured payload, against the workflow as it stands now. Once the build is ready, this is how you catch up a missed nightly job without waiting for the next firing or faking a payload by hand.
• Discard removes the entry. Use it when replaying would do damage or would be pointless — a webhook that the sending system has already retried successfully, an event whose effect a later event has superseded, a firing from a workflow you have since redesigned.

Replaying against the current workflow is the detail to think about before you press it. If you fixed the workflow because the old version was wrong, replaying is what you want. If you changed what the workflow does, a replayed payload may now be handled differently than it would have been at the time.

Design so a replay is safe

The same property that makes retries safe makes replays safe: an idempotent write. Key the write on something stable in the payload — a supplier product id, an order number, a file name — and a replay is a no-op where the work already happened.

Where that is genuinely impossible, discard rather than replay, and do the catch-up deliberately.

What this is not

Missed runs is not a queue you can hold work in. A firing sits there until somebody acts on it, and nothing drains it automatically — a schedule that has been missing its build for a week leaves seven entries and no data. Check it as part of watching an integration, not only when something is reported.

It is also not where failed runs go. A run that started and then failed is a run, with a timeline and a reason — see Runs and Failure handling.

Where to go next

• Execution modes — the build gate that produces most missed runs.
• Runs — the record a replay creates.
• Revisions and audit — what changed, and when, so you can tell which save caused the gap.