I would like to know how accurate and certain cron timing is. Lets say I got cronjob to run at 11:00:00 and then I pass time as a parameter for this cron job. Would it be possible, in any scenario, that the time in the parameter would be different, like 11:00:01 for example. Can I be 100% sure that the execution will happen at the exact time? I am concerned about things like heavy server load or any unforeseen circumstances. Can anything affect it? I am assuming it can.

I would also like to know how to pass planned time of execution as a parameter, instead of actual time. Lets assume that actual execution was late, like 11:00:01. How can I pass planned time that is defined in cronjobs, so 11:00:00 and how to do it when cron job is set to run let's say every 10 min? Is it possible to get planned time in that case, so that each time script was executed it has planned time as a parameter?

10 * * * * /tmp/script.sh $(date)
  • Basically the same question: serverfault.com/questions/721088/how-precise-is-a-cron-daemon/… Possible solution: Start you script sooner and check when the correct time is reached in there. – Panki Aug 4 '20 at 11:32
  • @Panki thank you, but my point is not to run it at the exact time. I just want to know what was the planned time of execution each time it runs. – rumburak Aug 4 '20 at 11:39
  • crontab only lets you specify mm hh, so the 'planned time' is always hh:mm:00. I'm not sure how many concurrent jobs you would have to run to have one of them take more than 59 seconds to start. You could run this job every minute for a week: * * * * * date >> ~/cron.tester and do the statistics on the :SS field. Perhaps running a script to run the date would be a more realistic scenario, though. – Paul_Pedant Aug 4 '20 at 20:32

Just by checking through my own syslog I can see that cron jobs usuallY start 1 second past the minute (Ubuntu 20.04). (Eg: ten past five triggers at 05:10:01). On my system this is pretty stable, but I wouldn't garentee it.

Under heavy load this might be worse because even if the cronjob triggered at the right time, extremely heavy load could delay excve for more than a second. But then such extreme load would slow your script down so much the start time would become largely meaningless.

Cron can and does occasionally skip jobs, for example if the system is switched off it will never catch up. I would be especially careful of this note in the manual:

Note that this means that non-existent times, such as "missing hours" during daylight savings conversion, will never match, causing jobs scheduled during the "missing times" not to be run. Similarly, times that occur more than once (again, during daylight savings conversion) will cause matching jobs to be run twice.

Make sure your code won't break if it runs at 05:10:02 instead of 05:10:01.

There's no elegant way to get cron to tell you which job is running. You can setup many identical jobs to run at different times, each job could pass in the time as an argument. I see two options:

Setup a crontab with many entries

Do check the notes below.

Yes there's 1440 minutes in a day, so if you need a crontab to run this minutely you might need a script to generate your crontab:


for hour in {0..23} ; do
  for minute in {0..59} ; do
    echo "${minute} ${hour} * * *   root    /path/to/script.sh ${hour}:${minute}:01"
done > /etc/cron.d/my-job

You'll end up with something like this:

01 00 * * *   root    my-job 00:01:01
02 00 * * *   root    my-job 00:02:01
03 00 * * *   root    my-job 00:03:01

Create a wrapper script to find the nearest expected run

It might be better to create a wrapper script which checks the current time and finds the nearest entry. If your job is set to run every 15 minutes you could use the example provided here:

curdate=`date "+%s"`
run_time=$(($curdate - ($curdate % (15 * 60))))
run_time_arg=$(date -d"@$run_time" "+%H:%M:%S")
/path/to/script.sh $run_time_arg

Note this does use behaviour specfic to GNU date and may not work on all implementations

  • 1
    using "$(date +'%H:%M:01')" might be easier than 1440 crontab entries – roaima Aug 4 '20 at 12:56
  • 1
    @roaima absolutely agree although they have subtally different behaviour on a very heavily loaded system so I included both examples for the OP's benefit. – Philip Couling Aug 4 '20 at 13:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.