Webhooks
Reliable webhook retries, with a runbook when they're exhausted
Stop losing failed webhooks. SteadyCron retries with exponential backoff, logs every attempt, and embeds your runbook in the alert when retries run out.
The problem
Stripe and GitHub retry their webhooks for you. Almost nothing else does. The moment you're the one calling a flaky internal service, a partner API, or a teammate's half-finished microservice, a single timeout means the call is gone — no retry, no record, no alert. You find out when someone notices the side effect never happened.
How SteadyCron solves it
- 1 Create an HTTP job with the method, headers, and body your webhook needs — including any signing headers or bearer tokens.
- 2 Set a timeout and a retry count with exponential backoff (and choose whether to retry on timeout or specific status codes), so a 502 or a slow cold start doesn't drop the call.
- 3 Every attempt is logged — status code, response body, duration — so 'did the webhook actually land?' has an answer, not a guess.
- 4 If retries run out, SteadyCron alerts you — and if you've set a runbook note on the job, the alert embeds it inline (Slack, Telegram, email), so the fix is right there instead of buried in a doc.
# SteadyCron retries this with backoff, then alerts (with your runbook) if it never lands:
POST https://internal.example.com/webhooks/order-shipped
Authorization: Bearer ${WEBHOOK_TOKEN}
Content-Type: application/json
Jobs
| weekly-digest-email | HTTP | 0 9 * * 1 | in 2 days | 3 days ago | ||
| nightly-db-backup | Heartbeat | 0 2 * * * | in 19 h | 5 h ago | ||
| stripe-reconciliation | HTTP | 0 */4 * * * | in 38 min | 3 h ago | ||
| cache-warmup | HTTP | */15 * * * * | in 11 min | now | ||
| search-index-sync | Heartbeat | */30 * * * * | in 6 min | 24 min ago |
| seed-test-data | HTTP | 0 4 * * * | in 14 h | 10 h ago | ||
| preview-env-cleanup | Heartbeat | 0 */6 * * * | in 2 h | 4 h ago | ||
| trial-expiry-sweep | HTTP | 0 6 * * * | — | yesterday |
Every job's status, schedule, and last run — at a glance.
What “retries as a service” actually means here
SteadyCron doesn’t run a generic message queue. It does one thing well: call an HTTP endpoint on a schedule or via trigger, retry it on failure with backoff, and keep an honest record of what happened. For one-shot outbound calls — forwarding a webhook to an internal service, re-driving a flaky integration, firing a notification that has to land — that’s exactly the job:
- Exponential backoff, not a flat retry loop — a transient 503 gets a growing delay instead of hammering the downstream service.
- Selective retries — retry on timeout, retry on specific status codes
(e.g.
502,503,429), or only on network errors. You decide what’s “retryable” for your endpoint. - A real audit trail — every attempt is a row in the execution log with status, duration, and a truncated response body, so retries show up as separate, inspectable attempts rather than vanishing into a black box.
When retries are exhausted, you don’t just get “failed”
A dead letter queue in the SQS sense replays messages. SteadyCron doesn’t try to be that — it’s not a message broker. What it does instead is make sure exhausted retries are never silent: the job’s execution log keeps every attempt and its response, and an alert fires the moment the last retry fails.
That alert can carry a runbook note you wrote
ahead of time — “this webhook forwards to billing-internal; if it’s down,
check #billing-incidents first” — so the person who gets paged doesn’t have
to go spelunking for context at 3am.
A good fit for
- Forwarding a third-party webhook (Stripe, a payment processor, a support tool) into an internal service that doesn’t have its own retry logic.
- Firing a notification or side-effect call that has to land — provisioning a resource, kicking off a downstream build, syncing a record to another system.
- Replacing a hand-rolled retry loop living inside application code, so the
retry logic survives a deploy and shows up in one place instead of scattered
try/catchblocks.
Related documentation
Stop finding out the hard way
Start on the free tier — no credit card required.
Start free