Quanti cron job gira davvero il tuo hosting e come scoprirlo

Un sito WordPress che rallenta senza una causa evidente ha spesso un colpevole noioso: troppi cron job, reali o simulati, che girano più spesso del necessario. Prima di aggiungere cache o CDN, conviene controllare cosa sta effettivamente in coda.

Verificare i cron job di sistema: crontab -l

Su un VPS o su un hosting con accesso SSH, il primo comando da lanciare è crontab -l. Mostra la tabella cron dell'utente con cui sei collegato, senza aprirla in modifica. Se non c'è nulla di pianificato, il sistema risponde con un messaggio del tipo "no crontab for nomeutente", come documentato nelle guide tecniche sulla sintassi di crontab.

Attenzione: crontab -l mostra solo i job dell'utente corrente. Su un server condiviso tra più account (tipico di un VPS con più siti), bisogna controllare utente per utente. Da root si usa crontab -l -u nomeutente per vedere la tabella di un altro utente, opzione prevista proprio per questo caso d'uso. Per sapere quali utenti hanno una crontab attiva sul sistema, si può elencare il contenuto di /var/spool/cron/crontabs, dove ogni utente con job pianificati ha un file con il proprio nome.

Su hosting condiviso senza accesso SSH la via è un'altra: il pannello di controllo (cPanel, Plesk o equivalenti) ha una sezione Cron Job Manager dove i job compaiono già elencati con orario e comando, senza bisogno di terminale.

Il caso WordPress: WP-Cron non è un cron reale

WordPress non usa il cron di sistema per default. Usa un file chiamato wp-cron.php che viene eseguito a ogni visita del sito, per controllare se ci sono task in scadenza (pubblicazione posts programmati, controllo aggiornamenti, invio notifiche dei plugin). Su un sito con traffico alto questo significa che il controllo dei task gira a ogni richiesta, con un carico proporzionale al traffico e al numero di task registrati dai plugin.

Per vedere esattamente cosa WordPress ha in coda, se hai WP-CLI installato (molti hosting lo offrono già pronto nel terminale), il comando è:

wp cron event list

Restituisce una tabella con hook, orario della prossima esecuzione (next_run_gmt), tempo relativo alla prossima esecuzione (next_run_relative) e ricorrenza, secondo la documentazione ufficiale di WP-CLI. È lo strumento più rapido per scoprire se un plugin ha registrato lo stesso hook più volte, o con una ricorrenza troppo stretta (ogni 5 minuti invece che ogni ora, per esempio): basta leggere la colonna "recurrence" e cercare righe duplicate o sospettosamente frequenti.

Chi preferisce l'interfaccia grafica può installare il plugin WP Crontrol, che mostra la stessa lista degli eventi pianificati direttamente nella bacheca di WordPress, con la possibilità di eseguire o cancellare manualmente un singolo hook.

Disattivare WP-Cron e sostituirlo con un cron di sistema

La sequenza corretta, documentata sia nella pagina wp-config.php del WordPress Developer Resources sia nelle guide tecniche dei provider, è:

1. Prima si crea il cron di sistema sostitutivo, poi si disattiva WP-Cron. Mai il contrario: se disattivi WP-Cron senza un sostituto attivo, i task programmati (post schedulati, backup, controllo aggiornamenti, notifiche) smettono di girare senza generare errori visibili, semplicemente non vengono più eseguiti.

Il job di sistema, da inserire con crontab -e, può usare wget:

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

oppure, se hai WP-CLI disponibile, la via consigliata dai provider che lo offrono è passare per il comando nativo:

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

2. Poi si disattiva WP-Cron aggiungendo in wp-config.php, prima della riga "That's all, stop editing!":

define('DISABLE_WP_CRON', true);

Su WordPress Multisite la costante si imposta una sola volta e vale per l'intera rete, non va ripetuta per ogni sito della installazione.

Cosa controllare dopo il cambio

Dopo aver attivato il cron di sistema e disattivato WP-Cron, torna a lanciare wp cron event list: gli orari di next_run devono continuare ad aggiornarsi agli intervalli previsti. Se restano fermi, il cron di sistema non sta effettivamente chiamando wp-cron.php: controlla il percorso nel comando e i permessi di esecuzione dell'utente con cui gira il job.