I have a series of cron jobs and I would like to test them in a more timely and automated way than the following:

  1. Test individual jobs in isolation by running them manually.
  2. Install job and update crontab.
  3. Wait for cron to execute jobs.
  4. Observe results.

I'm thinking that running a test script as root (in a development environment, of course) and fiddling with the system clock might be beneficial. What is best practice?

2 Answers 2


Best practice is to do all your testing in a development environment (which you already seem to know).

For testing cron jobs I generally don't like to muck around with the system clock (you can't just step the time to wherever you want - You need to let the clock run through all points to see how the jobs run and interact with each other.
You also can't just speed up the clock (x100) to make it faster: cron jobs that do a lot of number crunching won't be any faster, and you may have them stepping on themselves (or each other) depending on what the schedule looks like.

My standard for testing cron jobs is as follows:

  1. Test the job by running it manually.
    Debug the hell out of it here so you don't get bombarded with cron email later.
  2. Install the job, schedule it to run 2-3 minutes from now.
    • Observe the results running from cron (with no tty).
  3. Break something the job relies on and schedule it to run again in a few minutes.
    • Observe the reaction to breakage (make sure it does what you want).
  4. If the job runs OK in (2) & (3) schedule it to run at its normal time.
    • Observe the results of the job running at its normal time.
    • If the job runs OK promote the change to production.

In practice you can skip step 4 sometimes (if you KNOW that a job doesn't impact any other jobs and you're not worried about CPU/RAM/Disk load issues).

To really do an integration test on cron jobs you have to let a full year elapse (daylight saving time changes), and an argument can even be made for needing more than 4 years (leap years, leap seconds, etc.), but nobody I know does this. Just be aware that sometimes 2:30 happens more than once (or doesn't happen at all), and that there isn't always a February 29th and you're usually fine.

  1. Run it from the command line as the user whose privilege you want to run with.
  2. Always bear in mind that you should use the full path in crontab: -
    * * * * * /path/to/your/job >> /tmp/job.log 2>&1
  3. Check the job.log.
  • +1 for running as the target user -- Also a good idea to run once as root and then again as the target user to see if any permissions will get mangled (and make sure such mangling is handled as gracefully as possible)
    – voretaq7
    Sep 15, 2011 at 18:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .