Cron overlap detector
Paste your crontab, your @Scheduled classes, Quartz triggers or CronJob YAML, mixed together if you like. Find the jobs that fire at the same moment before they deadlock your database.
Why collisions deserve a look
Schedules accumulate. One team adds a nightly report at midnight, another adds a backup, a third adds a cache refresh, all "just after midnight", and nobody sees the pile-up because each schedule looks innocent on its own. The symptoms appear as intermittent deadlocks, connection-pool exhaustion or a CPU spike at the top of the hour that no single job explains.
This tool reads schedules from several places at once: crontab lines, Spring @Scheduled annotations (cron, fixedRate, fixedDelay, zone, and ${placeholders} you supply), Quartz cronSchedule calls and XML triggers, Kubernetes CronJob YAML and GitHub Actions schedule blocks. It expands each one into its real run times, converts them all to the same clock (so a 05:30 IST job and a 00:00 UTC job are recognised as the same instant) and lists every group of jobs that fire together, biggest pile-ups first.
Fixed-interval Spring tasks are handled honestly: they start relative to application start-up, so exact collisions with cron jobs cannot be proven, but tasks that share a period and initial delay will start together and are flagged. Your schedules are analysed in the browser and never uploaded.
Frequently asked questions
Why do jobs that start at the same moment cause trouble?
They compete for the same database connections, locks and CPU. Several heavy jobs at 00:00 is a classic cause of deadlocks, slow queries and timeouts. Spreading them by even a few seconds usually removes the spike.
Can cron really collide to the millisecond?
Cron expressions have one-second resolution, so same-second is the finest collision this tool can prove. Spring fixedRate tasks run at millisecond precision but start relative to application start-up, so the tool reports those as "likely to start together" when they share a period and delay, and does not claim exact collisions.
Do two @Scheduled jobs in the same second run in parallel?
Not by default. Spring Boot's scheduler has a single thread (spring.task.scheduling.pool.size=1), so jobs due together run one after the other, and a long job delays the rest. Raising the pool size lets them overlap, which brings back the contention.
How do I use property placeholders like ${jobs.report.cron}?
Paste your properties into the box below the main input as key=value lines. Placeholders with a default (${key:0 0 * * * *}) resolve automatically. SpEL expressions cannot be resolved and are reported.