Webhook Pipeline
Understand the core EdgeCron flow from trigger to delivery, retry, and dead letter.
EdgeCron is not just a cron expression. It is an observable, retryable, recoverable webhook delivery pipeline.
Endpoint
01
Trigger
02
Task Run
03
Delivery Attempt
04
Retry Job
05
Dead Letter
06
Core objects
Endpoint
Where to send
The target webhook destination. It owns the callback URL, method, headers, timeout, optional signing secret, retry policy binding, and event subscriptions.
Schedule Trigger
When to send
A cron or one-shot time rule. It creates Task Runs when time arrives; it does not perform the HTTP request itself.
Event Trigger
Why to send
A named business event such as invoice.paid. Endpoint filters decide which destinations receive the event, then fanout creates Task Runs.
Task Run
One execution instance
Runtime work created by a schedule, event fanout, or direct API call. Use it to track status or cancel pending execution.
Delivery Attempt
One HTTP call
A single outbound request to an Endpoint. It records status code, latency, response summary, error message, attempt number, and trace IDs.
Retry Job
Scheduled recovery
A queued retry created from a retryable failed Delivery Attempt. Retry policy controls max attempts and backoff.
How one request flows
Endpoint
Configure where EdgeCron sends callbacks: URL, method, headers, timeout, signing secret, retry policy, and event filters.
Trigger
A schedule, event publish, or direct API call decides why and when execution should start.
Task Run
EdgeCron creates one concrete execution instance bound to an endpoint and payload.
Delivery Attempt
Workers perform HTTP calls and record status, latency, response body, and request IDs.
Retry Job
Retryable failures are scheduled by policy with fixed, linear, or exponential backoff.
Dead Letter
Failures that exhaust attempts are kept for manual review, replay, or compensation.
The two common trigger paths
Schedule trigger
You create a Schedule with a cron expression or one-shot time. When time arrives, the scheduler creates Task Runs and workers create Delivery Attempts.
Event trigger
Your app publishes an Event such as invoice.paid. EdgeCron matches endpoint event filters, fans out, and creates one Task Run per matched endpoint.
Direct task
You can also create a Task Run directly for immediate delivery, delayed one-off delivery, or compensation workflows.
Outbound fan-out
Event fan-out is outbound delivery fan-out. When you publish an Event, EdgeCron checks each active Endpoint in the App and applies that Endpoint's filter_events rules. Each matching Endpoint receives its own Task Run and Delivery Attempt history.
One published Event can therefore create many Task Runs, but billing still follows the trigger model: the Event publish counts as one billable trigger, while fan-out Delivery Attempts are included.
This is different from a Hookdeck-style inbound gateway. EdgeCron does not yet receive third-party webhooks through hosted Source URLs and route them through Source -> Connection -> Destination rules.
Schedule endpoint binding
Schedules can target explicit endpoint_ids. When a Schedule has endpoint bindings, it creates Task Runs only for those Endpoints. When the binding list is empty, EdgeCron keeps the backward-compatible behavior and sends the Schedule trigger to all active Endpoints in the App.
Use explicit bindings when a Schedule should drive only a specific workflow, such as daily-report -> reporting-api, instead of broadcasting to every active Endpoint.
Retry classification
Workers classify delivery results before creating Retry Jobs:
2xxresponses succeed.5xx, network errors, and timeouts are retryable.4xxresponses are terminal by default.429is retryable when the response includes a validRetry-Afterheader. EdgeCron accepts both seconds and HTTP-date formats, then clamps the delay to the Retry Policy'smax_delay_sec.
Runtime states in plain language
pending / running
The Task Run is waiting or executing. This does not yet mean the target Endpoint has accepted the webhook.
success
The target Endpoint returned 2xx, so the Delivery Attempt is successful and the Task Run can finish.
failed / retry_scheduled
Timeouts, network errors, and retryable responses are recorded and can schedule Retry Jobs according to policy.
dead_letter
Maximum attempts were exhausted. The failed work is preserved for investigation, manual replay, or business compensation.
Common confusions
- Endpoint is not Event: Endpoint is the destination; Event is the business input.
- Schedule does not send HTTP directly: it creates Task Runs, and workers perform delivery.
- Task Run is not a reusable template: it is one runtime execution instance.
- Delivery Attempt is not Task Run: a single Task Run can produce multiple attempts.