The CronRadar Scheduled Job Methodology

Every scheduled job is monitored. What differs from job to job is how much protection it gets, how loudly a failure is raised, and how the job must be built. One question decides all three: what does a failed run cost?

1. Rank every job#

R1. Monitor every job, then rank it. The rank decides how much a job gets, never whether it is watched. Why: cron launches are "fire-and-forget" (SRE book, ch. 24), so an unwatched job fails silently.

R2. Rank by five questions. Can a run be skipped? Can it safely run twice? Does it have a finish-by deadline? What depends on it? Can it succeed with a wrong result?

R3. Assign the first class that fits.

2. Escalate by class#

R4. Only P1 pages. Why: PagerDuty treats Error like Critical, as high urgency (Dynamic Notifications), so a P2 job sent there would wake someone.

R5. Leave escalation to the paging tool. CronRadar sends the first alert and a daily reminder while a job stays overdue; PagerDuty's escalation policy handles levels, timeouts, and on-call.

3. Build for your scale#

R6. One host: every job checks in, overlap is handled on purpose, and catch-up after downtime is a choice, not a default.

R7. A scheduler inside the app: exactly one instance schedules, and monitoring runs outside the app, because a check inside it stops with it.

R8. A scheduler service: one leader that only launches, and each run identified by its scheduled time. A job that must not run twice skips when in doubt; a job that must not be skipped runs at least once with an idempotency key.

R9. A shared platform: an owner for every job, jittered start times, quotas per team, retries capped by error type, and data dependencies triggered by events, not clock offsets.

Why: each scale fails in its own way. Google, Slack, and Airbnb replaced cron on one host because one machine was the whole failure domain; Netflix replaced a single-leader scheduler when it stopped scaling. The evidence traces every rule above to published sources.

4. Write it down#

R10. Give every job a contract: owner, class, schedule in UTC, overlap and missed-run policy, finish-by deadline, retry cap, run identity, grace period, alert destinations, and runbook.

R11. Review the ranking: reconcile the inventory against monitors, re-rank a job when what depends on it changes, and review after every P1 incident.

Applying the methodology covers each rule in CronRadar step by step.