Schedule a webhook

The tax of running your own scheduler

A small team building a SaaS product, an indie developer with a side project, or an internal tools team at a larger company all eventually need something to happen on a schedule, a nightly report, a subscription renewal check, a cache warm-up, and the traditional answer is a persistent process somewhere: a cron daemon on a VM, a scheduled container, a serverless function with its own scheduler configuration. Each of those needs monitoring, needs to survive restarts, and needs someone to notice when it silently stops firing. For a single recurring task, that infrastructure is disproportionate to the job it's doing.

Registering a schedule in one call

POST /dev/cron-webhook accepts a cron expression and a target webhook URL, along with the payload to send on each trigger; once registered, the schedule is stored and the webhook fires automatically at each matching time, no polling, no persistent connection required on your end. The registration request itself is queued asynchronously and returns a task_id confirming the schedule is active, with confirmation delivered via signed webhook or a signed link valid for 24 hours.

Cron syntax outliving the reasons it was invented

The cron expression format was built for the original Unix cron utility in the 1970s to let administrators list recurring jobs in a plain text table without a graphical scheduler. Decades later, that same compact syntax is still the common language for describing recurring schedules across almost every platform, which is why building on it rather than inventing a new scheduling syntax means existing cron expressions, and the knowledge of how to write them, transfer directly into this endpoint.

What this replaces in a real system

Instead of a background worker whose only job is to wake up, check the time and fire an HTTP request, that logic moves entirely into the schedule registration, and your application only needs to expose one endpoint that receives the webhook and does the actual work when called. This composes cleanly with the rest of a task pipeline: a webhook triggered on schedule can itself kick off further asynchronous jobs. At $0.002 per request, the cost of maintaining a scheduled trigger is negligible next to the infrastructure it replaces.

Access, reliability and current status

Using the endpoint requires prepaid balance; without one, the registration request returns HTTP 402 rather than a schedule that silently never fires. A failed trigger delivery is retried automatically up to three times before a clear error is reported, and a failed attempt is never charged. The endpoint is live now, and payload data associated with each schedule is handled under the same retention and deletion rules as the rest of the API, never used for training.