Distributed job scheduler

Schedule one-off delayed tasks and recurring cron jobs across a fleet of workers with at-least-once execution, lease heartbeats, fencing tokens so zombie workers cannot corrupt downstream state, and isolation when every tenant schedules a job for 00:00 UTC.

Notes and ratings save in this browser. Completing self-assessment records your progress.

Duration 45:00

Requirements checklist

Register one-time delayed jobs (`runAt`) and recurring cron jobs (`0 * * * *`), with payload, retry policy, and timeout.Dispatch due jobs to worker nodes within ~1 second of their scheduled time, track execution status, and retry failed runs with exponential backoff up to `maxAttempts` before moving to a dead-letter queue.Allow tenants to cancel a scheduled job or inspect execution history.No lost jobs once acknowledged: every due job executes at least once even if schedulers or workers crash.Prevent duplicate side effects on worker lease expiry via fencing tokens (`leaseEpoch`) and execution idempotency keys.Absorb the top-of-the-hour ('00:00 UTC') thundering herd without starving real-time high-priority jobs.

Clarifying questions

What is the acceptable dispatch delay between a job's scheduled time and when a worker starts running it (e.g., <1 s vs <30 s)?
How long can a single job execution run (milliseconds vs hours), and do workers need heartbeats?
Are jobs strictly one-off, recurring cron, or DAG workflows with dependencies?
Is the system multi-tenant, where one tenant might dump 1M jobs at once?

Open a practice canvas (new tab)Estimation calculators (new tab)

requirements

Suggested time: about 6 minutes. Addresses lease heartbeats, cancellation, and multi-tenant fairness at 00:00 UTC.

Notes for requirements