I have a couple of cron jobs for basic maintenance which aren't very resource-intensive.

I also have custom task scheduling (which is just calling a .php file and passing information via GET, ie: cronjob.php?param1=param ...). These can add up pretty quickly.

These just call system commands and run external programs (Nmap is one of them). They usually don't take long either.

Anyway, can anyone tell me, roughly what point is too many? I know it's hard to say since it depends on what job is being run and how often, but at what point does the crontab program start "struggling"? Anyone have any idea?


  • How many entries can you add before the file grows so large you run out of disk space? May 11, 2010 at 5:39

4 Answers 4


I wouldn't worry about the load on the "crontab program" (cron) itself; it's your overall system load you might want to pay attention to. Look at metrics (cpu utilization, io rates, web query response times) during the time your job(s) are running - is there a noticeable spike? is it bad enough that it's disrupting actual use of the system?

If the programs "don't take long", that's a good sign that it's not a problem.

If you're still concerned, you can do other things to limit the load: run the jobs with nice to reduce their priority, run them sequentially instead of simultaneously, and so forth.


Just searching through our production systems, the largest one had 862 cron jobs (across all users, the largest single one, root, is 117), and it doesn't particularly break out in a sweat with that many.

If you start 60 jobs every minute, 24x7, and they all take two seconds to complete, then you'll probably end up in a world of pain. But, as long as the workload balances out (with quiet times and such), it should recover. Keep an eye on system loads during the peak times (CPU%, disk I/O, ...) and worry more about that than the number of actual jobs.

This question is akin to "How many processes can I run before getting into trouble?". The best bet is to try it, since it depends on your system. Cron itself has few limitations that I've found but, if you're trying to schedule tens of thousands of jobs, you're putting more of a strain on it than I ever had.

Measure, don't guess!


Cron itself will essentially never start to struggle; the system will be completely bogged down with workload long before that happens.


I agree with all the answers present here. To understand it with a slightly different perspective, think of cronjobs as users on your platform.

Let's say that a user utilizes 1% of your CPU (CRUD operations/networking etc.). If there are 100 such users (cronjobs) simultaneously, then your CPU would reach a threshold limit and the server might not able to process ultimately resulting in a crash.

So coming back to the question: "How many cron jobs are too many?" - As long as your analysis suggests that there might not be a sudden spike in the resources, even a 100 cronjobs are good to go.

You must log in to answer this question.