Processor Timeline
Before an event is delivered, Webhookr runs it through an ordered processor pipeline. Every event records an immutable processor timeline — the ordered list of processors that ran, what each decided, and how long it took. The timeline is visible on the event-detail screen and answers the question "why wasn't this delivered?" without digging through logs.
The delivery gate
An event is delivered only when every enabled processor passes. The pipeline runs in order and halts on the first processor that does not pass; the rest are marked skipped. If any processor stops or fails the event, delivery is not attempted.
Run statuses
Each processor run in the timeline has one of these statuses:
| Status | Meaning |
|---|---|
| Passed | The processor allowed the event to continue. |
| Stopped | The processor intentionally halted the event (e.g. a filter that didn't match). Delivery is blocked. |
| Failed | The processor errored. Delivery is blocked. |
| Skipped | The processor did not run because an earlier processor halted the pipeline. |
| Disabled | The processor is configured off for this project/endpoint and did not run. |
Executed runs (Passed / Stopped / Failed) show a start time and duration; Skipped
and Disabled runs show —.
Reason codes
Every non-passing run carries a stable reason code you can match on. Engine-level codes:
| Code | On | Meaning |
|---|---|---|
PIPELINE_HALTED | Skipped | An earlier processor halted the pipeline before this one could run. |
PROCESSOR_ERROR | Failed | The processor threw an error; the message carries the (clamped) error text. |
Individual processors add their own codes (for example a filter emitting FILTER_NO_MATCH).
Reason codes are additive and stable — new codes are added rather than existing ones repurposed.
Force send a blocked event
A stopped or failed event would otherwise be a dead end — replay refuses a blocked event. Force send is the escape hatch: it delivers the event to all enabled destinations, bypassing the gate.
- The resulting deliveries are flagged Forced so the override is auditable.
- The timeline is never changed — the original block stays on the record.
- Force send is deliberately a one-off manual action, confirmed in a dialog.
- Some processors are non-overridable (security-critical checks such as signature verification). Force send is refused for an event blocked by one of them.
Use force send sparingly — a repeatedly-forced processor usually signals a misconfiguration to fix at the source, not to keep overriding.