Cron tools › Explain / Test
Cron overlap checker
Too many jobs at the top of the hour? Paste your schedules — one per line, with or without a name, or straight from a crontab — and see every minute where several of them start together, and which minute offsets would spread them out.
Top collisions
Minute of the hour
Stagger suggestions
How to find overlapping cron jobs
- Paste the schedules, one per line: a bare expression,
name: expression, or whole crontab lines (the command becomes the name). - Set the Dialect the jobs are written in and the Time zone they run in, then choose a 24-hour or 7-day window.
- Read the peak: the largest number of jobs that start in the same minute. Top collisions groups the minutes by which jobs collide and how often.
- Check the Minute of the hour histogram — a tall bar at :00 is the usual problem.
- Apply the Stagger suggestions: each moved job gets a new minute field that keeps its interval, and the peak after the changes is shown. Copy one line or the whole list.
Why :00 gets crowded, and why it matters
Most people write 0 * * * *, 0 0 * * * or */15, and every one of them fires at minute 0.
On a single server that means CPU, disk and database load arrive together. Hosted schedulers feel it too: GitHub Actions warns
that scheduled workflows can be delayed during periods of high load, "especially at the start of every hour", and that queued
jobs may be dropped. Jenkins' H takes the other route: it picks each job's minute from a hash of the job name, so jobs with the same spec start at different minutes.
This checker looks at start minutes. A job that runs for twenty minutes still overlaps the jobs after it, and the same
job can overlap itself: a Kubernetes CronJob's concurrencyPolicy decides that (Allow, the default,
Forbid or Replace). For a fresh set of evenly spread schedules, use the stagger generator.
How the suggestions are chosen
Jobs are taken in the order you listed them. The first job in a collision keeps its minutes; each later job that collides is
shifted by the smallest minute offset that removes its collisions with the jobs already placed (or, if none does, the one that
leaves the fewest). Only the minute field changes, and only by an offset that keeps every minute inside the hour, so
*/15 becomes 2-59/15 and still runs every 15 minutes. A job that runs every minute cannot be moved
this way and is listed as such. The same input always gives the same suggestions.
FAQ
Does it know how long my jobs run?
No — only start times, because that is all a cron line says. If a job takes longer than the gap to the next one, it overlaps
even when the start minutes differ. Leave headroom or add a lock (for example flock) to jobs that must not overlap.
How are seconds-level schedules counted?
Per minute: a node-cron or Quartz job that fires several times within a minute counts as one start in that minute, so the peak is the number of distinct jobs starting in the same minute.
Why does the time zone matter?
It sets which minutes "the next 24 hours" or "the next 7 days" covers. Collisions are counted on the wall clock of that zone, so jobs written for the same zone collide the same way in any of them; on a clock-change day the skipped hour is still counted and the repeated hour is counted once, as the clock reads.
Is my job list sent to a server?
No. Everything runs in this page. A short list is kept in the address bar after the # so that Copy link reopens it;
browsers never send that part to the server.