Cron di WordPress sotto carico: perché il cron di sistema non basta

Un post programmato pubblicato in ritardo, un’email che parte ore dopo, uno stock non aggiornato o una sincronizzazione CRM incompleta vengono spesso liquidati con una frase: “si è rotto il cron”. In realtà, le cause possono essere diverse.

Può mancare un avvio regolare del processo. Oppure il job parte, ma deve elaborare troppo lavoro in una volta sola. Oppure ancora viene ripetuto dopo un timeout e produce un doppio invio, un contatto duplicato o un dato incoerente.

Il principio utile è questo: un cron di sistema non rende affidabile un job; rende più affidabile il suo risveglio. Per decidere bene occorre separare almeno quattro aspetti: quando un’attività viene avviata, quanto lavoro deve gestire, come reagisce a errori e riavvii e come ci si accorge che non ha concluso correttamente.

WP-Cron non è un cron di sistema

WP-Cron è il sistema con cui WordPress gestisce gli eventi pianificati. A differenza del task scheduler di un server, non è un processo residente che resta attivo in attesa dell’orario previsto: WordPress controlla ed esegue gli eventi dovuti in relazione alle richieste ricevute dal sito.

La conseguenza è intuitiva. Se un evento è previsto alle 14:00 ma il sito non riceve richieste fino alle 17:00, l’esecuzione può iniziare soltanto alla prima richiesta successiva. Per un blog con pubblicazioni non urgenti può essere un compromesso ragionevole. Per un backup, una promozione a scadenza, un rinnovo o una sincronizzazione di dati commerciali può non esserlo.

Anche il traffico molto alto può creare un problema diverso: i tentativi di avvio di WP-Cron aggiungono lavoro al server. WordPress usa un lock, associato al transient doing_cron, per limitare avvii concorrenti; la logica è descritta nella funzione spawn_cron(). Questo meccanismo riduce il rischio di esecuzioni sovrapposte, ma non trasforma WP-Cron in un sistema distribuito di elaborazione code.

In sintesi, WP-Cron è uno scheduler applicativo utile e flessibile, ma non offre da solo una garanzia di puntualità o di completamento del lavoro.

Quando WP-Cron può essere sufficiente

Non è necessario disabilitare WP-Cron su ogni installazione. La scelta dovrebbe partire dalla criticità dell’automazione, non dal fatto che il sito usi WordPress o abbia un certo numero di plugin.

WP-Cron può essere proporzionato per attività leggere e tolleranti al ritardo, per esempio:

pubblicazioni editoriali per cui uno slittamento non crea un problema operativo;
pulizie periodiche non urgenti;
controlli di manutenzione senza una scadenza stretta;
un sito vetrina o un blog con poche automazioni e conseguenze limitate in caso di ritardo.

Un criterio pratico è chiedersi: se questa attività slitta di un’ora, cosa succede? Se la risposta è “nulla di rilevante”, WP-Cron può bastare. Se lo slittamento può incidere su vendite, ordini, dati, comunicazioni ai clienti o attività interne, conviene valutare un trigger indipendente dalle visite.

Quando usare un cron di sistema

Un cron di sistema è normalmente la scelta più lineare quando un’attività deve essere avviata con maggiore prevedibilità. WordPress documenta il collegamento di WP-Cron al task scheduler del server nella guida su come agganciare WP-Cron allo scheduler di sistema.

I casi tipici includono backup, campagne email, lead nurturing, import ed export, sincronizzazioni con CRM o gestionale, aggiornamenti di prezzi e disponibilità, operazioni relative a ordini e rinnovi.

Il modello corretto è composto da due parti:

configurare un’attività pianificata lato server che richiami wp-cron.php;
solo dopo averne verificato il funzionamento, disabilitare l’avvio di WP-Cron durante le normali visite con DISABLE_WP_CRON.

La costante va inserita in wp-config.php secondo la documentazione su wp-config.php. Disabilitarla senza un sostituto funzionante significa però togliere il meccanismo che avvia gli eventi: le automazioni possono fermarsi o accumulare ritardi.

Su Linux e macOS, una pianificazione espressa come */15 * * * * indica un avvio ogni 15 minuti. È un esempio di sintassi, non una frequenza universale né un comando da copiare senza controllo. Hosting gestito, cPanel, Plesk e server amministrati possono offrire modalità, permessi e strumenti diversi. La configurazione va quindi verificata con chi gestisce hosting e sviluppo.

La frequenza parte dal ritardo tollerabile

“Ogni minuto” non è una risposta tecnica completa. Un intervallo definisce quanto spesso il sistema prova a risvegliare WordPress; non garantisce che il lavoro termini entro quell’intervallo.

Per scegliere la frequenza, per ogni automazione conviene definire:

il ritardo massimo accettabile;
la durata media e quella peggiore del job;
il numero di operazioni da elaborare;
il carico su PHP e database;
le dipendenze esterne, come API di CRM, gestionali, gateway o servizi email.

Una sincronizzazione non urgente può tollerare 15 minuti. Un processo commerciale sensibile può richiedere una soglia più stretta. Ma se il job impiega più tempo dell’intervallo, esegue query lente, attende API esterne o consuma tutte le risorse disponibili, aumentare la frequenza può creare sovrapposizioni o arretrati anziché risolverli.

È importante distinguere la puntualità del trigger dalla conclusione effettiva del lavoro. Il primo è un compito dello scheduler; il secondo dipende dal progetto del job e dalla capacità dell’infrastruttura.

Quando il limite è il volume: code e Scheduled Actions

Se un’attività deve elaborare centinaia o migliaia di record, un singolo evento cron che tenta di fare tutto insieme è fragile. Un invio massivo, un feed prodotti, un’importazione, l’elaborazione di file o una serie di webhook sono più gestibili se divisi in unità piccole.

Una coda di job serve proprio a questo: conserva lavori da eseguire, li elabora a gruppi, permette di vedere quali sono in attesa, completati o falliti e rende più praticabile un nuovo tentativo controllato.

WooCommerce usa Action Scheduler per varie attività in background. Le relative azioni sono consultabili in WooCommerce > Stato > Azioni pianificate, dove è possibile filtrare gli stati, cercare per hook o data e leggere i log disponibili. La documentazione di WooCommerce Scheduled Actions chiarisce che il comportamento della coda dipende anche dal modo in cui viene attivata: quando il trigger dipende dalle visite, conserva quel limite; un trigger server-side riduce l’incertezza dell’avvio.

Nei flussi che collegano e-commerce, CRM ed ERP, la coda è solo una parte della soluzione. Occorre anche definire la fonte autorevole dei dati, la gestione degli errori e la riconciliazione delle elaborazioni incomplete.

Un job affidabile deve poter ripartire senza fare danni

Un job può fallire per un timeout, una risposta lenta di un’API, un errore PHP o un riavvio del processo. Per questo non basta chiedersi se parte: bisogna chiedersi cosa accade se parte una seconda volta.

In termini tecnici, un job importante dovrebbe essere idempotente: rieseguirlo non deve produrre un effetto duplicato. Un retry non dovrebbe inviare due email, creare due contatti nel CRM, applicare due volte una modifica o registrare nuovamente la stessa operazione.

Le misure dipendono dal caso, ma il team tecnico può progettare identificativi univoci, stati di elaborazione, controlli prima della scrittura, retry limitati e log degli errori. Per un’integrazione può significare conservare l’identificativo dell’operazione già inviata; per un invio email può significare registrare in modo affidabile l’esito prima di tentare un nuovo invio.

Modificare WP_CRON_LOCK_TIMEOUT o altri timeout senza una diagnosi non risolve automaticamente query lente, memoria insufficiente, API esterne lente, job monolitici o duplicazioni logiche. Il lock limita gli avvii ravvicinati; non corregge il comportamento applicativo del lavoro eseguito.

Per processi realmente critici, nei quali ritardo, perdita o duplicazione non sono accettabili oltre una soglia molto stretta, può essere necessario valutare una coda persistente o un worker esterno con retry controllati, alert e tracciamento dell’esito. È una scelta architetturale da commisurare al rischio, non un requisito universale di WordPress.

Come diagnosticare ritardi, fallimenti e duplicazioni

Prima di cambiare impostazioni, è utile isolare il problema. Una sequenza di verifica può essere questa:

Capire l’estensione del ritardo. Riguarda un solo plugin o tutte le automazioni? Un solo tipo di evento o anche post programmati, email e sincronizzazioni?
Controllare gli eventi pianificati. Verificare eventi scaduti, ricorrenti, duplicati o non più necessari. Chi sviluppa plugin dovrebbe usare wp_next_scheduled() prima di registrare un evento, così da evitare nuove pianificazioni dello stesso hook a ogni caricamento.
Esaminare le Scheduled Actions di WooCommerce. Azioni in crescita, fallite o ripetute possono indicare backlog, errori ricorrenti o dipendenze esterne non disponibili.
Raccogliere evidenze tecniche. Durata delle richieste, log PHP, timeout, limiti di memoria, lentezza del database e risposte delle API aiutano a distinguere un problema di trigger da uno di esecuzione.
Usare WP-CLI quando disponibile. Il team con accesso al server può elencare, testare, eseguire o rimuovere eventi tramite i comandi wp cron di WP-CLI.

La correzione dovrebbe seguire l’evidenza: un cron di sistema per un risveglio irregolare, una coda per un volume eccessivo, una revisione del codice per duplicazioni o timeout, un controllo dell’infrastruttura quando il collo di bottiglia è nelle risorse.

Errori da evitare

Disabilitare WP-Cron senza avere verificato il cron di sistema.
Trattare un intervallo ricorrente come garanzia di esecuzione esatta al minuto.
Programmare lo stesso hook a ogni visita senza controllare se è già pianificato.
Lasciare eventi attivi dopo aver dismesso una funzione o un plugin.
Concentrare migliaia di operazioni in un’unica esecuzione.
Modificare lock e timeout per tentativi, senza conoscere durata, dipendenze e comportamento del job.
Considerare “partito” un processo come sinonimo di “concluso correttamente”.

Checklist per scegliere il prossimo intervento

Elenca le automazioni che impattano vendite, lead, pagamenti, dati clienti o operatività interna.
Definisci per ciascuna il ritardo massimo tollerabile e le conseguenze di un doppio avvio.
Misura o raccogli la durata del job, il volume elaborato e le dipendenze esterne.
Verifica se esistono eventi scaduti, falliti, duplicati o code in crescita.
Controlla se il provider offre cron di sistema, WP-CLI, log e alert utilizzabili.
Scegli un livello proporzionato: WP-Cron per attività tolleranti al ritardo; cron di sistema per trigger prevedibili; coda per volume e tracciabilità; worker o infrastruttura esterna per criticità elevate.

Prima di modificare wp-config.php, lo scheduler o i timeout, è opportuno far verificare configurazione, backlog e job personalizzati a chi gestisce sviluppo e hosting. La domanda non è soltanto “WP-Cron funziona?”. È: questo processo può partire, ripartire e concludersi nel tempo richiesto senza creare conseguenze indesiderate?

Fonti e approfondimenti

Vuoi dare una svolta alla tua attività online?

Ti affianco con esperienza e visione per portare risultati concreti al tuo business.

Dove siamo