How many cron jobs is your hosting really running and how to check

A WordPress site that slows down without an obvious cause often has a tiresome culprit: too many cron jobs, real or simulated, running more frequently than necessary. Before adding cache or CDN, it's worth checking what's actually in the queue.

Checking system cron jobs: crontab -l

On a VPS or hosting with SSH access, the first command to run is crontab -l. It shows the cron table for the user you're logged in as, without opening it for editing. If nothing is scheduled, the system responds with a message like "no crontab for username", as documented in technical guides on crontab syntax.

Be aware: crontab -l only shows jobs for the current user. On a server shared between multiple accounts (typical of a VPS with several sites), you need to check user by user. From root you use crontab -l -u username to view another user's cron table, an option provided specifically for this use case. To find which users have an active crontab on the system, you can list the contents of /var/spool/cron/crontabs, where each user with scheduled jobs has a file with their own name.

On shared hosting without SSH access, the route is different: the control panel (cPanel, Plesk or equivalents) has a Cron Job Manager section where jobs are already listed with timing and command, no terminal needed.

The WordPress case: WP-Cron is not a real cron

WordPress doesn't use the system cron by default. It uses a file called wp-cron.php that gets executed on every site visit to check if there are tasks due (scheduled post publication, update checks, plugin notifications). On a high-traffic site this means the task check runs with every request, with a load proportional to traffic and the number of tasks registered by plugins.

To see exactly what WordPress has queued, if you have WP-CLI installed (many hosting providers already include it ready in the terminal), the command is:

wp cron event list

It returns a table with hooks, the time of the next execution (next_run_gmt), relative time to next execution (next_run_relative) and recurrence, according to the official WP-CLI documentation. It's the quickest way to discover if a plugin has registered the same hook multiple times, or with a recurrence that's too tight (every 5 minutes instead of hourly, for example): just read the "recurrence" column and look for duplicate or suspiciously frequent rows.

Those who prefer a graphical interface can install the WP Crontrol plugin, which shows the same list of scheduled events directly in the WordPress dashboard, with the ability to run or manually delete a single hook.

Disabling WP-Cron and replacing it with a system cron

The correct sequence, documented both on the WordPress Developer Resources wp-config.php page and in technical guides from providers, is:

1. First create the replacement system cron, then disable WP-Cron. Never the other way round: if you disable WP-Cron without an active replacement, scheduled tasks (scheduled posts, backups, update checks, notifications) stop running without generating visible errors, they simply don't execute anymore.

The system job, to be added with crontab -e, can use wget:

*/15 * * * * wget -q -O - https://yourdomain.it/wp-cron.php?doing_wp_cron >/dev/null 2>&1

or, if you have WP-CLI available, the route recommended by providers who offer it is to use the native command:

*/15 * * * * wp cron event run --due-now --path=/home/user/public_html/ >/dev/null 2>&1

2. Then disable WP-Cron by adding to wp-config.php, before the line "That's all, stop editing!":

define('DISABLE_WP_CRON', true);

On WordPress Multisite the constant is set only once and applies to the entire network, it doesn't need to be repeated for each site in the installation.

What to check after the change

After activating the system cron and disabling WP-Cron, run wp cron event list again: the next_run times should continue to update at the expected intervals. If they stay static, the system cron isn't actually calling wp-cron.php: check the path in the command and the execution permissions of the user running the job.