Event sources & trigger history

The Trigger History tab on a workflow's Executions view shows every time a webhook or schedule trigger fired, including events that never became an execution (filtered out, dropped because of a queue limit, or queued and waiting). Any recorded event can be replayed.

Trigger history feed

Each row shows the event's status:

• started - the event created an execution and it ran (or is running).
• filtered - the event matched trigger filters that prevented a run from starting. No execution was created.
• queued - the event is waiting for a concurrent run to finish (only when a queue policy is active).
• dropped - the event was silently discarded because the queue was full and the overflow policy was "drop".

Click Replay on any row to re-fire that event's recorded payload as a real execution, or Test to run it against the draft graph without affecting the live version.

Queue policies

By default, a webhook or schedule trigger starts a new execution for every incoming event, in parallel, with no limit. A queue policy lets you change that:

Open a workflow's Trigger History tab and click Queue policy next to the trigger node you want to configure:

• Parallel mode (default) - all incoming events fire concurrently. Optionally set a max concurrency to cap how many simultaneous runs the trigger can have at once; excess events queue and run as slots open.
• Ordered mode - only one execution runs at a time; the next event waits for the current one to finish. Equivalent to max concurrency = 1.
• Backlog depth limit - set a cap on how many events can wait in the queue. Once the cap is hit, further events either queue anyway (ignore the cap), get rejected (429 to the HTTP caller), or are silently dropped.

Removing a queue policy restores the default parallel, uncapped behavior immediately.

When to use queue policies

• Rate-sensitive downstream APIs - cap a Stripe webhook trigger at max 3 concurrent runs so you don't overwhelm a downstream database write.
• Ordered processing - guarantee a Sheets row-added trigger processes rows in arrival order.
• Noisy webhooks - set a drop policy with a small backlog depth on a high-volume webhook you only partially care about, so bursts don't queue up thousands of runs.

Related

• Triggers - the webhook, schedule, and polling triggers that this feature observes.
• Trigger filters - per-trigger AND/OR conditions evaluated before a run spawns; filtered events appear in the history feed.
• Executions - the per-node timeline for runs that do start.