Ingest channel
Fire a webhook on a cron cadence, with no producer to run.
A scheduled webhook fires on a cron cadence with no external producer: you attach a five-field UTC cron expression and an optional JSON payload template to a webhook, and each firing creates a normal delivery that inherits the same destination, routing, retries, signing, analytics, replay, and dead-letter handling as an inbound event.
Agents need to wake up on their own — a nightly reconciliation, an hourly freshness check, a catch-up pass after an outage. That is usually where a separate cron service gets bolted on, with its own retry semantics, its own history, and its own way of failing.
Scheduled webhooks require Starter or above. Schedules are managed from the dashboard or through the Public API.
How it works
A schedule belongs to one webhook and stores a five-field cron expression in UTC, an optional name, an optional JSON payload template, and a status of active or paused.
Without a template, each firing sends a default body identifying the run: source set to scheduled, plus scheduleId, webhookId, cronExpression, and firedAt. Setting a payloadTemplate replaces that body entirely with your own JSON — useful for telling the agent which job this is, at the cost of the default fields.
Schedules are independent of public ingest but create deliveries through the same delivery engine, so the webhook destination, Automations, routing rules, retry policy, analytics, and dead-letter behaviour all apply exactly as they would for inbound traffic.
Each schedule tracks lastFiredAt and nextFireAt. Pause and resume without deleting, from the dashboard or the API, and read every firing back out of delivery history.
Scheduled webhooks at a glance
| Expression | Standard five-field cron, evaluated in UTC |
|---|---|
| Scope | One or more schedules per webhook |
| Body | A default body with scheduleId, cronExpression, and firedAt, or an optional JSON payload template that replaces it |
| State | active or paused, with lastFiredAt and nextFireAt in Unix milliseconds |
| API | /v1/webhooks/{id}/schedules to list, create, pause, resume, and delete |
| Retries on failure | Same retry policy, dead-letter path, and replay as inbound deliveries |
Scheduled webhooks is not a side door.
Every channel lands in the same delivery engine. The same routing rules, Automations, retry policy, Standard Webhooks-compatible signing, delivery history, analytics, deterministic replay, and dead-letter handling apply no matter how the event arrived.
- • A separate scheduler with its own uptime story
- • Retry logic for a scheduled run that failed at the destination
- • A record of which runs fired, which succeeded, and which did not
- • A way to re-run yesterday’s job against yesterday’s configuration
- • Alerting for a job that silently stopped firing
- • A second set of credentials and destinations to keep in sync
Cron services and HTTP schedulers will call a URL on a cadence, and several do it well. The difference is what happens after the call. A scheduled firing in Hooksbase is a delivery: it is recorded, retried under the same policy as inbound events, signed, replayable against the configuration that was live at the time, and it falls into the same dead-letter path when it ultimately fails. You are not operating one system for inbound events and a second for scheduled ones.
What teams use it for
A daily summary or hourly check wakes the agent with a payload template that says which job this is, and the result is delivered like any other event.
A periodic reconciliation pass gives the agent a second chance at work that failed earlier, with the failures still visible in delivery history and the dead-letter path.
A regular firing that exercises the whole path end to end, so a broken destination surfaces on your schedule rather than on a customer’s.
A cron firing can land directly in SQS, EventBridge, Pub/Sub, or object storage on Pro and above, without an HTTP endpoint in the middle.
Limits worth knowing before you build on it
Every channel has edges. These are the ones that change how you design around it.
A schedule is a recurring cron expression attached to a webhook. For a single event that should land at a specific future moment, use delayed delivery instead — send x-hooksbase-deliver-at on ingest, or set a webhook-level default delay, both up to one year out. Delayed delivery requires Pro or above, and strict-FIFO webhooks reject future scheduling.
Cron expressions are evaluated in UTC. There is no per-schedule timezone or daylight-saving handling, so convert before you write the expression.
Scheduled webhooks are not available on the Free plan. Email, form, and HTTP ingest are.
Frequently asked questions
- How do I trigger a webhook on a schedule?
- Attach a schedule to an existing Hooksbase webhook with a five-field UTC cron expression and an optional JSON payload template. Each firing creates a delivery that uses the webhook’s existing destination, routing, and retry configuration. Scheduled webhooks require Starter or above.
- What happens if a scheduled run fails?
- It is retried under the same retry policy as an inbound event, and if it ultimately fails it lands in the dead-letter path where it can be inspected, exported, or re-driven. It is not silently lost.
- Can I send a specific payload on each firing?
- Yes. Each schedule can carry an optional JSON payload template that becomes the request body. That is normally how you tell the receiving agent which job a given firing represents.
- Do scheduled events support replay?
- Yes. A scheduled firing produces a delivery with a persisted dispatch snapshot, so it can be replayed individually or in bulk and re-runs against the configuration captured at firing time.
- Are schedules in my local timezone?
- No. Cron expressions are evaluated in UTC, with no per-schedule timezone or daylight-saving adjustment. Convert your intended local time to UTC before writing the expression.
- Can I schedule a one-off event for a specific future time?
- Yes, but through a different mechanism. Schedules express a recurring cron cadence. For a single future delivery, send the x-hooksbase-deliver-at header on ingest with a Unix timestamp in milliseconds, or set a webhook-level default delay — both accept times up to a year out. Delayed delivery requires Pro or above, and webhooks configured for strict FIFO reject future scheduling.
Try it on the free plan
5,000 deliveries a month, no card. Create a webhook and the scheduled channel is available on it immediately.