Cron Job Calculator

A five-field expression hides a surprising number of runs

*/5 * * * * runs every five minutes. Obvious. But 0 */4 * * 1-5? That one fires 30 times a week, not 42. Weekends are excluded, and most people don't notice until the reporting job they expected to run on Saturday just... didn't.

Once you combine day-of-month with day-of-week, standard cron's OR logic kicks in and the schedule fires more often than the expression suggests. This calculator expands every field and counts the real total across a full year. If the expression itself looks wrong, the cron expression builder helps construct one visually, and the validator confirms the syntax before you deploy it.

High frequency and low frequency fail differently

A job that fires 288 times a day has overlap problems. If the previous run hasn't finished when the next one starts, you get race conditions, duplicate rows, lock contention. Frequent jobs need a mutex or flock guard, and you should know the count before deciding whether to add one.

Monthly jobs have the opposite problem. They fail silently and nobody catches it for 30 days. By the time someone notices the report is missing, a month of data is gone. Infrequent jobs need someone watching, because they won't announce their own failure.

Theoretical schedules vs. what actually ran

This calculator tells you how many times a job should execute. Whether it actually did is a different question entirely. Servers reboot mid-run. Cron daemons freeze after an OOM kill. Jobs exit 0 despite the upload failing halfway through. Cron job monitoring tracks every execution and flags the ones that ran late, ran long, or never showed up.