Maximum execution time exceeded in PHP: come risolverlo

Maximum execution time exceeded indica che PHP ha interrotto uno script perché ha superato il tempo massimo consentito. Il messaggio include normalmente il file e la riga in cui l’esecuzione si trovava quando il limite è stato raggiunto.

Questa guida approfondisce Maximum execution time exceeded con una procedura progressiva e reversibile. Non inviare password, codici 2FA, token, chiavi private o file di configurazione completi nei ticket.

Che cosa significa

Il file indicato non è sempre la causa originaria: può essere il punto nel quale uno script lento, una query o una chiamata esterna si trovava allo scadere del tempo.

Il parametro max_execution_time può essere gestito da cPanel quando il piano lo consente, ma un aumento deve seguire la diagnosi e non sostituirla.

Come riconoscere il problema

  • Importazioni o aggiornamenti si interrompono.
  • error_log mostra Maximum execution time of N seconds exceeded.
  • Una pagina amministrativa resta in caricamento.
  • Il problema riguarda un plugin specifico.
  • La stessa operazione funziona con dataset più piccoli.

Cause più frequenti

1. Ciclo o elaborazione eccessiva

Codice difettoso o dataset molto grande mantiene PHP occupato. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

2. Query lenta

Il processo attende il database per gran parte del tempo. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

3. API esterna

Una chiamata HTTP priva di timeout adeguato blocca l’operazione. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

4. Importazione via browser

Il lavoro è troppo grande per una singola richiesta web. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

5. Cron sovrapposti

Più esecuzioni della stessa attività competono per risorse. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

6. Limite troppo basso per attività legittima

Alcune procedure controllate richiedono più tempo del valore attuale. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

Diagnosi passo per passo

  1. Leggi file e riga. Usa il percorso per identificare plugin, tema o core coinvolto. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
  2. Riproduci con log attivo. Registra l’orario e limita il test a una sola operazione. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
  3. Riduci i dati. Confronta un batch piccolo per capire se il tempo cresce con il volume. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
  4. Controlla query e API. Cerca slow query, cURL timeout e servizi remoti. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
  5. Verifica cron. Controlla attività duplicate o processi ancora attivi. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
  6. Consulta il valore PHP. In cPanel apri Select PHP Version → Options o lo strumento previsto dal piano. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
  7. Controlla altri limiti. Memoria, processi, CPU e I/O possono rallentare lo script. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.

Metodo sicuro di intervento

Prima di modificare la configurazione, registra lo stato iniziale: indirizzo o funzione coinvolta, messaggio completo, data e ora, ultima modifica nota e risultato da un secondo dispositivo, rete o strumento. Una diagnosi ripetibile è più utile di molti tentativi eseguiti contemporaneamente.

Applica una sola correzione alla volta e conserva una copia dei file, dei record o dei valori precedenti. Dopo ogni intervento ripeti esattamente il test originale e controlla i log relativi allo stesso intervallo temporale. Se il risultato cambia, annota quale modifica lo ha prodotto.

Evita disattivazioni globali di firewall, WAF, TLS, cache o sistemi di sicurezza. Quando serve una eccezione, deve essere limitata all’URL, al parametro, al processo o al servizio realmente interessato.

Procedura di risoluzione

  1. Correggi il componente. Aggiorna, sostituisci o configura il plugin indicato. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
  2. Suddividi in batch. Riduci il numero di record elaborati per richiesta. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
  3. Ottimizza database e codice. Evita query ripetute e caricamento di dati non necessari. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
  4. Imposta timeout per API. La richiesta remota deve fallire rapidamente e gestire l’errore. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
  5. Elimina sovrapposizioni cron. Usa lock e frequenze coerenti. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
  6. Aumenta max_execution_time con moderazione. Da Select PHP Version → Options scegli un valore adeguato solo per l’operazione verificata. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
  7. Riporta il limite al valore previsto. Dopo attività eccezionali evita di lasciare soglie inutilmente alte. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.

Controlli finali

  • L’operazione termina.
  • Nessun nuovo fatal error.
  • Il tempo resta prevedibile.
  • Le risorse non raggiungono il limite.
  • Cron e importazioni non si sovrappongono.

Prevenzione

  • Usa batch.
  • Imposta timeout esterni.
  • Monitora log.
  • Aggiorna plugin.
  • Programma attività pesanti.

Errori da evitare

  • Non impostare valori illimitati.
  • Non modificare php.ini fuori dal pannello previsto.
  • Non ignorare il file indicato nel log.
  • Non rilanciare l’importazione ripetutamente.
  • Non confondere timeout PHP e gateway timeout.

Come documentare la verifica

Conserva una breve nota con configurazione iniziale, risultato di ogni controllo e modifica applicata. Inserisci sempre data e ora, perché cache, log, code, rate limit e processi pianificati possono cambiare nel tempo. Questa documentazione facilita il rollback e permette all’assistenza di evitare verifiche già eseguite.

Quando confronti due test, usa le stesse condizioni: stesso URL o destinatario, stesso file, stesso client e stessa rete quando possibile. Se cambi più variabili, il risultato non permette di individuare con certezza la causa.

Controllo incrociato

Dopo la correzione esegui almeno un controllo indipendente. Per un sito confronta browser, risposta HTTP e log; per DNS interroga autoritativo e resolver pubblico; per la posta confronta Webmail, intestazioni e Track Delivery; per PHP verifica il valore effettivamente applicato al dominio. Un solo indicatore può essere influenzato da cache o configurazioni locali.

Se il problema ricompare, evita ulteriori modifiche e raccogli nuovamente i dati. La ricorrenza può indicare un processo pianificato, un limite raggiunto, una dipendenza esterna o una configurazione che viene rigenerata automaticamente.

Quando contattare l’assistenza Xlogic

Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi oppure richiede log e configurazioni non disponibili nel pannello. Indica:

  • errore completo
  • file e riga
  • orario
  • operazione eseguita
  • valore max_execution_time

Non inviare credenziali. Per iniziare la diagnosi sono sufficienti dati tecnici, orari, URL, codici e messaggi di errore.

Fonti tecniche ufficiali

Domande frequenti su Maximum execution time exceeded

Aumentare max_execution_time risolve sempre?

No. Un ciclo, una query lenta o un’API bloccata continueranno a causare problemi.

Dove modifico il valore su Xlogic?

Quando disponibile, in cPanel → Select PHP Version → Options.

Il file indicato è sempre colpevole?

No. Può essere soltanto il punto raggiunto quando il tempo è scaduto.

Zero significa illimitato?

Il comportamento dipende dall’ambiente; non è consigliabile usare valori illimitati su produzione.

Perché l’import piccolo funziona?

Il tempo richiesto cresce con il numero di record e può superare la soglia solo sul dataset completo.

Maximum execution time exceeded in PHP: come risolverlo ultima modifica: 2026-08-02T02:07:14+02:00 da Team tecnico Xlogic

Ti è piaciuto questo Post?