How an every-minute cron job weighs on your server — and how to lighten it

Writing * * * * * in a crontab is easy: the task runs every minute and results appear almost instantly. But that short line spawns a new process 1,440 times a day. If each run is a half-second check, the cost is negligible. Often, though, every run loads the whole site framework and opens a database connection even when there is nothing to do. Here is what an every-minute job really does to a server and how to use it sensibly.

What each run costs

For each run the server starts a PHP process, loads the interpreter and compiles the script. In WordPress or Laravel the whole core, plugins and settings load too, plus several database queries — all to answer "is there any work?", where the answer is usually "no". On shared hosting hundreds of sites share one machine, so many such jobs wake up together at the top of each minute and slow every site, including yours. That is why plans limit CPU and process counts, and frequent heavy cron jobs hit those limits first.

Overlapping runs

The real danger starts when a run takes longer than a minute. If an external API stalls for three minutes, cron launches two more copies that stall too. Within minutes dozens of identical processes fill memory, the database hits its connection limit and the site shows "Database Error". A flock lock simply skips a run while the previous one is active:

* * * * * /usr/bin/flock -n /tmp/queue.lock /usr/bin/php /var/www/user/data/www/example.uz/cron/queue.php >> /var/www/user/data/logs/queue.log 2>&1

Calling your own site with wget or curl

A command like wget -q -O - https://example.uz/cron.php routes the job through the web server, occupying a PHP-FPM worker meant for real visitors and obeying web timeouts. Run scripts through PHP CLI directly whenever possible.

Which tasks really need every minute

Only tasks where delay hurts: payment status checks, SMS queues, verification codes. Exchange rates, sitemaps, session cleanup or statistics are fine every 15–30 minutes or once a day. Ask: "what happens if this result is 10 minutes late?"

Also avoid the top of the hour: since many people write 0 * * * *, load spikes then. A minute like 17 sidesteps the peak.

Cheap check first, heavy work only when needed

If a job must poll often, make its first lines cheap and load the framework only when there is work:

<?php
if (!file_exists(__DIR__ . '/../data/queue.flag')) {
    exit; // nothing to do
}
require __DIR__ . '/../bootstrap.php';
// ... process the queue ...
unlink(__DIR__ . '/../data/queue.flag');

Heavy but non-urgent jobs can run at low priority with nice and ionice:

15 4 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c3 /usr/bin/php /var/www/user/data/www/example.uz/cron/sitemap.php >> /var/www/user/data/logs/sitemap.log 2>&1

Example: a clinic website

A private clinic in Tashkent ran its appointment-reminder script every minute. Each run loaded the full CMS and pulled all of tomorrow's bookings, though only a few dozen reminders went out daily. Morning traffic slowed the site and CPU-limit warnings appeared. Switching to every 10 minutes, adding flock and querying only un-reminded bookings kept reminders on time and made the site fast again.

Measure it yourself

Run the script with /usr/bin/time -v and read "Elapsed (wall clock) time" and "Maximum resident set size", then multiply by the runs per day.

/usr/bin/time -v /usr/bin/php /var/www/user/data/www/example.uz/cron/queue.php

On sayt.uz hosting your cron jobs are listed in the ISPmanager panel, opened from the sayt.uz cabinet. If the site slows down and you can't tell whether cron is to blame, contact support so the heaviest processes can be checked server-side.