(01)
One Run Per Schedule
Each due run is claimed in the database before it fires, so a second worker that sees the same job finds it already taken. One trigger per scheduled slot, even if your architecture scales to 100 instances.
(Verne Clockwork · Cron-as-a-Service)
Cron Jobs for Apps That Run on More Than One Box Serverless background jobs, one run per schedule, fully logged
Stop managing crontabs on fragile instances. Clockwork provides API-driven, serverless background jobs with automatic retries, a log of every run, and no duplicates however many instances you deploy.
curl -X POST https://api.vernesoft.com/v1/clockwork/jobs \
-H "Authorization: Bearer vrn_clockwork_•••" \
-d '{"name":"billing","schedule":"0 0 1 * *","url":"https://api.yourdomain.com/billing"}'(The Local Crontab Trap)
Why Traditional Crontabs Break in Distributed Systems
Running a local cron daemon on a VPS is easy until you scale. When you deploy multiple application instances, traditional crons lead to race conditions, overlapping executions, and silent failures.
Traditional / In-House Cron
- ✕ Race conditions: multiple instances trigger the same billing script simultaneously.
- ✕ Silent failures: no built-in alerting if a job fails to execute.
- ✕ No retries: when a run fails, nothing tries again until the next scheduled time.
- ✕ Hardcoded schedules requiring full application redeployments to change.
Verne Software Clockwork
- ✓ Distributed locks guarantee exact-once execution across your entire cluster.
- ✓ No silent failures: every trigger is recorded with the response it returned.
- ✓ Automatic retries, with the outcome of every attempt recorded.
- ✓ Dynamic schedule management via REST API — no redeployments needed.
(Core Features)
Precision Engineering for Background Jobs
(02)
Dynamic API Control
Create, pause, update, or delete schedules programmatically. Let your users define their own background tasks directly from your SaaS dashboard.
(03)
Retries That Survive Deploys
A failed run is retried up to three times — one minute, then five minutes later. Retry state lives with the job rather than in memory, so a pending retry survives a worker restart or a deployment.
(04)
Minute-Accurate Scheduling
The scheduler wakes every minute and fires what is due. Each run is computed from the cron expression itself, so schedules never drift the way a hand-rolled interval loop does.
(05)
Observability & Logs
Complete audit trails for every trigger. See exactly when a job fired, what payload was sent, and the response it received.
(06)
Standard Cron Syntax
Standard 5-field POSIX cron expressions, resolved in UTC. Every schedule is validated when you create it, so an expression that could never fire is rejected up front instead of silently never running.
(Nautilus Ecosystem)
The Perfect Match with Verne Relay
Clockwork handles the when, Relay handles the how. Use Clockwork to trigger scheduled events and route them through Relay for secure delivery with exponential backoff. Secure the entire pipeline with Auth.
Clockwork (Timer fires)Relay (Retries & fan-out)Client Application
(Developer Experience)
Schedule a Job via API
Manage your recurring tasks dynamically using any language. Just provide a cron expression and the target endpoint.
curl -X POST https://api.vernesoft.com/v1/clockwork/jobs \
-H "Authorization: Bearer $VERNE_CLOCKWORK_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "Monthly Billing Run",
"schedule": "0 0 1 * *",
"url": "https://api.yourdomain.com/billing/process",
"method": "POST",
"body": "{\"batch\":\"auto\"}"
}'(FAQ)
Frequently Asked Questions
How does Clockwork prevent duplicate executions?
Each due run is claimed with a conditional update in the database before anything fires: a second worker that sees the same job finds the row already advanced and does nothing. That gives you one trigger per scheduled slot, however many instances you run. Delivery itself is at-least-once — a failed attempt is retried — so make your endpoint idempotent and use the X-Clockwork-Attempt header to guard side effects.
What happens if the target endpoint is down when the cron fires?
Each run gets up to three attempts: the first, then retries one minute and five minutes later. Network failures, 5xx and 429 are retried; other 4xx responses are not, since an identical retry would get the same answer. Every attempt is recorded with the response it returned, and a pending retry survives a worker restart.
Can I schedule one-off tasks (delayed jobs)?
Yes. Alongside recurring cron expressions, the Clockwork API supports precise timestamp scheduling for single-execution delayed tasks — for example, send an email 24 hours after registration.
We already use Vercel Cron, Supabase pg_cron or GitHub Actions — why change?
Each one is good inside its own platform and stops at its edge. Vercel Cron schedules Vercel functions and its free tier is deliberately narrow. pg_cron runs inside your Supabase database and reaches only what the database can reach. GitHub Actions schedules on a best-effort queue and, by its own documentation, can fire late under load. Clockwork calls any HTTPS endpoint on any host, on the schedule you set, with an execution log per run.
How do I test a job without waiting for its schedule?
Create a delayed job a minute out with POST /v1/clockwork/delayed, watch it in the execution log, then delete it. A one-off run uses the same worker and the same logs as a recurring one.
Is there a free tier?
Yes — 3,000 API requests a month across every engine, cron included, with no card. After that it is €3 per 10,000 requests, and a monthly spend cap keeps the bill bounded.
(Get Started Today)
Take Control of Your Background Jobs
Eliminate crontab anxiety. Build reliable, scalable, and observable scheduled tasks for your platform today.
When you do not need this
If you run one application on one machine, crontab is fine and you should keep it. The same holds for work that never leaves its own platform: Vercel Cron suits a Vercel function, pg_cron suits a job that only touches your Supabase database, and a GitHub Actions schedule is fine for a nightly task that can afford to be late.
Clockwork earns its place at the boundary where those stop, and that boundary arrives sooner than people expect. The second instance, where two copies of the same crontab fire the same billing run twice. The job that has to call a service on another host. The schedule your own customers set from your dashboard. The run that failed at 03:00 with nobody to tell.
Those four are what Clockwork answers: one execution per schedule however many instances you deploy, any HTTPS endpoint on any host, schedules created and cancelled through an API, and a log of every trigger with the response it returned. The first 3,000 requests each month are free.