Webhooks and Scheduled Jobs: Event-Driven Automation That Recovers

A webhook tells your system that something happened. A scheduled job asks whether work is due. Use the event path for a call ending or a form arriving; use a schedule for a daily reconciliation, reminder sweep or report.

Acknowledge quickly, process safely

Webhook senders may retry when your endpoint times out or returns an error. Verify the sender’s signature, store the event ID and return a success response after durable receipt. Process the business action separately so a slow CRM or database does not hold the webhook connection open. Stripe’s webhook documentation describes retries and duplicate delivery for its events; apply the same defensive pattern to any provider, while checking that provider’s exact retry policy.

Make each handler idempotent: processing the same event twice should not create two bookings or two follow-up messages. Put a unique constraint on the event identifier or use a durable inbox table. If a downstream step fails, retain the event, record the error and retry with backoff rather than dropping it.

Schedule jobs with clear ownership

A cron entry is a trigger, not a reliability plan. Give each scheduled job a documented timezone, timeout, concurrency rule and alert condition. Make the task safe to rerun after a partial failure. For large batches, checkpoint progress so one bad record does not force a full replay.

Watch for missed work

Track received, completed, retried and dead-letter counts. Reconcile the source system against your processed-event table on a schedule. That catches a webhook outage that no individual error alert exposed.

Keep a short runbook with the owner, replay method and recovery steps. Event delivery can be at least once, and scheduled jobs can overlap; design the application around those facts instead of assuming each trigger runs exactly once.

Continue with the LeadOro AI Phone Agent Stack series for the related walkthrough.