Held deliveries

Switching a deployment off does not discard its work. Each delivery that arrives is recorded as a held execution: a real run, with its payload and its trigger event, that has not been queued and will not start on its own.

This is the difference between a deployment being off and a trigger being off:

HELD is not "pending"#

A held execution has no job, no worker and no timer. It will not change state, retry, or time out. Nothing is coming until a person acts — which is why the status is HELD rather than something that sounds like it is in flight.

Practically that means a held run:

• does not consume concurrency or count against a rate limit;
• does not collapse a later delivery's deduplication — a real delivery arriving afterwards is still its own run;
• can be cancelled, which is how you throw one away individually.

Turning the deployment back on does not replay#

Reactivating a deployment is a cheap, idempotent change. It tells you how many deliveries are held and then does nothing else.

Dispatching a backlog is a separate, deliberate decision, because a week of held deliveries is not something to start by accident. Two explicit actions act on it:

Release — queues every held delivery, oldest first. Each is queued as it is: same execution, same trigger event, same payload. It is not a replay and creates nothing new.

Discard — cancels every held delivery. The executions become CANCELLED rather than disappearing, and their events are untouched: the deliveries still happened, they just will not run. This works whether the deployment is on or off.

Runs already queued when you switch off#

A delivery that was already queued when the deployment went off is not run. When its turn comes, it is moved to HELD and its job is dropped, joining the same backlog.

So switching a deployment off converges: within one dispatch cycle, in-flight work has either finished or been held. Runs that had already started are not interrupted.

The backlog is bounded#

A deployment holds up to a fixed number of deliveries (1000 by default). Beyond that, the oldest held rows are dropped to make room for the newest.

What survives that eviction is the event: the delivery trail stays complete, and only the replayable intent is lost. So a deployment left off under heavy traffic still shows every delivery it received — it just cannot replay all of them.

The first eviction logs a warning. Once above the cap, every delivery evicts one, so the remaining evictions are silent rather than producing an alert per delivery.

Reading the backlog#

The deployment's page shows the held count and offers both actions. The executions list filters by status, so HELD shows exactly what is waiting, with the trigger event behind each one.

Next#

• The execution lifecycle — where HELD sits among the statuses.
• What raises a notification — a deployment that starts holding work says so, once, and keeps the count current.