Wat betekent Maximum execution time exceeded in WordPress?

PHP heeft het actieve script afgebroken omdat de ingestelde max_execution_time werd bereikt. De genoemde bestandsregel is het punt waar PHP stopte, maar niet automatisch de oorspronkelijke oorzaak van de vertraging.

Is een 504 Gateway Timeout hetzelfde als max_execution_time?

Nee. Een 504 komt van een gateway of proxy die niet op tijd een antwoord van de achterliggende server kreeg. PHP kan nog bezig zijn of al door PHP-FPM zijn gestopt, dus controleer proxy-, webserver-, PHP-FPM- en PHP-logs op hetzelfde tijdstip.

Moet ik max_execution_time gewoon verhogen?

Niet zonder diagnose. Een verhoging kan een legitieme import tijdelijk ruimte geven, maar maskeert ook oneindige lussen, trage queries, vastlopende externe verzoeken en te grote batches. Meet eerst de taak en verklein of repareer haar.

Waar wijzig ik max_execution_time bij WordPress?

Dat hangt af van de PHP-handler en hosting. Gebruik de gedocumenteerde PHP-instellingen van je hostingpaneel of laat de beheerder het juiste php.ini- of poolniveau aanpassen. Een php_value-regel in .htaccess werkt niet op iedere PHP-opzet en kan juist een 500-fout veroorzaken.

Waarom blijft de timeout gelijk nadat ik PHP heb aangepast?

Je kunt het verkeerde php.ini-bestand of alleen de CLI-configuratie hebben aangepast, de host kan de waarde begrenzen of een eerdere proxy- of PHP-FPM-limiet kan de aanvraag stoppen. Controleer de effectieve webwaarde en de log van de laag die daadwerkelijk afbreekt.

Kan WP-Cron een WordPress-timeout veroorzaken?

Ja. WordPress controleert verschuldigde WP-Cron-taken tijdens paginaladen en plugins kunnen daar zwaar werk aan koppelen. Splits lange taken op, voorkom dubbele planning en laat een beheerder zo nodig een gecontroleerde systeemplanning gebruiken.

Welke informatie heeft mijn hostingprovider nodig?

Stuur de volledige URL of beheeractie, exact tijdstip met tijdzone, fouttekst, eventuele request-ID, betrokken plugin of import en de gebruikelijke looptijd. Vraag welke timeoutlaag ingreep en om de bijbehorende logregel plus de effectieve waarden.

Maximum execution time in WordPress oplossen (2026)

De melding Maximum execution time exceeded betekent dat PHP een WordPress-verzoek heeft gestopt omdat de ingestelde uitvoeringstijd werd bereikt. Zoek eerst welke taak, plugin of query de tijd verbruikt en verklein of repareer die belasting; verhoog een limiet alleen wanneer de gemeten taak legitiem is en alle andere timeoutlagen daarop zijn afgestemd.

Herken welke timeout je werkelijk ziet

Een PHP-fout ziet er meestal ongeveer zo uit:

Fatal error: Maximum execution time of ... seconds exceeded

Het genoemde bestand en regelnummer laten zien waar PHP op dat moment bezig was. Dat bestand is niet altijd de veroorzaker. Een databasefunctie kan bijvoorbeeld wachten op een trage pluginquery, en een WordPress-corebestand kan worden genoemd terwijl plugincode de aanroep begon.

Een 504 Gateway Timeout is iets anders. Volgens MDN over 504 heeft een gateway of proxy niet op tijd antwoord van de achterliggende server ontvangen. Zie je een 500, wit scherm of kritieke-foutmelding, vergelijk dan ook de gerichte uitleg voor een 500 Internal Server Error, een wit WordPress-scherm en een kritieke WordPress-fout.

De timeoutlagen in de juiste volgorde

Een WordPress-verzoek kan door meerdere klokken lopen:

een CDN, load balancer of hostingproxy wacht op de origin;
Apache of nginx wacht op PHP of een andere upstream;
PHP-FPM kan een verzoek op poolniveau beëindigen;
PHP bewaakt max_execution_time;
de plugin of externe dienst kan een eigen timeout gebruiken.

De kortste toepasselijke limiet wint. Alleen max_execution_time verhogen helpt dus niet wanneer nginx, PHP-FPM of een beheerde proxy eerder stopt.

De officiële PHP-documentatie voor max_execution_time merkt bovendien op dat op niet-Windows-systemen tijd in bepaalde systeemaanroepen, streambewerkingen en databasevragen niet op dezelfde manier meetelt als pure scriptuitvoering. Een langzaam verzoek kan daardoor een proxytimeout krijgen zonder de letterlijke PHP-melding te bereiken.

Stappenplan: de WordPress-timeout veilig oplossen

1. Leg fout, actie en herstelpunt vast

Maak een actuele back-up van bestanden en database en controleer de terugzetroute. De officiële WordPress-handleiding voor back-ups benadrukt dat bestanden en database samen één herstelset vormen.

Noteer daarna:

de volledige fouttekst en het genoemde bestand;
het exacte tijdstip met tijdzone;
de URL, beheeractie of cron-taak;
de omvang van import, export, back-up of mediabewerking;
wijzigingen vlak vóór de eerste fout;
of de fout altijd na ongeveer dezelfde tijd verschijnt.

Verander nog geen limiet. Deze beginsituatie is nodig om vast te stellen welke ingreep werkelijk helpt.

2. Zoek de laag die het verzoek afbreekt

Vergelijk op hetzelfde tijdstip de PHP-errorlog, PHP-FPM-log, webserverlog en log van CDN of hostingproxy. Vraag bij managed hosting om de bijbehorende request-ID of logregel.

Gebruik deze signalen:

De letterlijke PHP-fatal wijst naar max_execution_time.
Een PHP-FPM-melding over beëindigen wijst naar de poollimiet.
upstream timed out in nginx wijst naar FastCGI of proxy.
Een 504 zonder PHP-fatal wijst eerst naar gateway, proxy of een stilgevallen upstream.
Een pluginlog met steeds hetzelfde object of record wijst naar invoer of applicatielogica.

Een databaseverbindingsfout vraagt een andere herstelroute. Verhoog geen uitvoeringstijd wanneer de database helemaal niet bereikbaar is.

3. Reproduceer klein en bij voorkeur op staging

Herhaal de actie met de kleinst mogelijke veilige invoer: één afbeelding, enkele importregels, één taal, één pluginupdate of één exportonderdeel. Werkt een kleine batch wel en groeit de looptijd evenredig, dan moet de taak waarschijnlijk worden opgesplitst. Blijft zelfs één item hangen, onderzoek dat item en de betrokken code.

Test op staging als de actie schrijft naar content, bestellingen of bestanden. Voer geen herhaalde live import uit die telkens gedeeltelijke records kan maken. Controleer vóór iedere herhaling welke wijzigingen de mislukte poging al heeft opgeslagen en zet die alleen terug via de eigen rollback van de plugin of je back-up.

4. Verzamel WordPress- en PHP-logging zonder bezoekersdetails te tonen

Laat WordPress tijdelijk naar een logbestand schrijven en houd foutweergave voor bezoekers uit. De officiële WordPress-uitleg voor debuggen beschrijft WP_DEBUG_LOG samen met WP_DEBUG_DISPLAY op false en adviseert debugging op staging.

Zoek vanaf de fout terug naar:

herhaalde functies of dezelfde record-ID;
een plugin- of themapad;
trage databasevragen;
een externe API zonder afgebakende wachttijd;
beeldbewerking van uitzonderlijk grote bestanden;
recursie of een lus die geen voortgang maakt;
een cron-taak die opnieuw wordt ingepland terwijl hij nog loopt.

Schakel tijdelijke debuginstellingen na de test weer uit en bescherm of verwijder het logbestand volgens je beheerbeleid.

5. Isoleer de veroorzaker omkeerbaar

Begon de fout na een pluginupdate, pauzeer dan alleen die plugin op staging of binnen een onderhoudsvenster. Kun je niet inloggen, hernoem via SFTP alleen de vermoedelijke pluginmap en noteer de oorspronkelijke naam. Test eenmaal en zet de naam direct terug als de fout blijft.

Controleer bij een themagerelateerde actie tijdelijk met een standaardthema, zonder het actieve thema te verwijderen. Leidt de test tot een andere fatale fout, gebruik dan het herstelpad voor een kritieke WordPress-fout.

Het doel is bewijs verzamelen. Alle plugins uitschakelen en tegelijk een limiet verhogen maakt onduidelijk welke wijziging de fout heeft beïnvloed.

6. Repareer de werklast vóór de klok

Kies de reparatie die bij de gevonden oorzaak hoort:

verwerk import- of exportregels in kleinere batches;
schaal afbeeldingen vóór upload naar een passende grootte;
haal alleen noodzakelijke databasekolommen en rijen op;
voeg paginering of hervatbare checkpoints toe aan maatwerk;
begrens externe HTTP-verzoeken en handel uitval af;
voorkom dat dezelfde cron-taak dubbel wordt gepland;
verplaats langdurig werk uit een bezoekersrequest naar een gecontroleerde achtergrondtaak.

WordPress legt in de officiële uitleg over WP-Cron uit dat verschuldigde taken bij een paginalaad worden aangeroepen. Een zware taak kan daardoor een gewone bezoeker raken. Een beheerder kan geplande taken inspecteren met de officiële wp cron-commando’s, maar verwijder geen onbekende events zonder te bepalen welke plugin eigenaar is.

7. Beoordeel PHP max_execution_time pas na meting

Is de taak na optimalisatie voorspelbaar, hervatbaar en aantoonbaar legitiem, vergelijk dan de gemeten looptijd met de effectieve PHP-webconfiguratie. Gebruik de door je host ondersteunde instelling of het juiste php.ini-niveau. Noteer de oude waarde, pas één waarde aan, herstart de vereiste dienst alleen als je die beheert en controleer de effectieve webwaarde opnieuw.

Plaats niet blind php_value max_execution_time in .htaccess. Dat is afhankelijk van Apache en de PHP-handler en kan bij PHP-FPM een 500-fout veroorzaken. Voeg ook niet zomaar set_time_limit(0) aan plugin- of themacode toe. De officiële PHP-referentie voor set_time_limit() legt uit dat iedere aanroep de teller opnieuw start en dat nul geen tijdslimiet oplegt.

Een geheugenfout is geen tijdslimiet. Staat in de log Allowed memory size exhausted, gebruik dan de aparte aanpak voor een WordPress memory-limit-fout.

8. Controleer PHP-FPM afzonderlijk

Alleen voor serverbeheerders: PHP-FPM heeft met request_terminate_timeout een eigen grens voor één request. De officiële PHP-FPM-configuratie beschrijft ook request_slowlog_timeout, waarmee een backtrace van een traag verzoek naar de slowlog kan worden geschreven.

Gebruik de slowlog om de vastlopende code te vinden voordat je de terminate-limiet verruimt. Maak een kopie van de poolconfiguratie, valideer de syntaxis volgens je distributie en herlaad PHP-FPM alleen als de controle slaagt. Herstel de oude configuratie wanneer de requestduur of log niet verbetert.

9. Controleer webserver en proxy afzonderlijk

nginx met PHP-FPM: fastcgi_read_timeout meet de tijd tussen opeenvolgende leesacties van FastCGI, niet automatisch de totale requestduur. Staat nginx als proxy vóór een andere origin, dan is proxy_read_timeout een andere instelling.

Apache of Apache als proxy: de officiële TimeOut-documentatie beschrijft wachttijden voor specifieke I/O-situaties en het standaardgedrag van mod_proxy wanneer geen afzonderlijke proxylimit geldt.

Hostingafhankelijke route: CDN’s en managed platforms kunnen een vaste maximale requestduur hebben die je zelf niet kunt verhogen. Vraag welke laag de 504 leverde en ontwerp langdurige taken als batches of achtergrondwerk. Vergroot nooit meerdere lagen tegelijk. Bewaar iedere oorspronkelijke configuratie, test de syntax en rol terug bij uitblijvende verbetering.

10. Valideer prestatie en rollback

Test na de reparatie dezelfde invoeromvang en leg looptijd, geheugengebruik en resultaat vast. Controleer:

een kleine en normale batch;
hervatten na een bewuste onderbreking;
dubbele records of bestanden;
frontend en beheer;
cronwachtrij en logs;
500- en 504-responses;
belasting tijdens gelijktijdige verzoeken.

Zet een tijdelijk verhoogde limiet terug als optimalisatie de extra ruimte overbodig maakt. Documenteer eigenaar, reden en eindwaarde als een afwijkende limiet nodig blijft.

Veelgemaakte fouten

Alle limieten tegelijk verhogen. Daardoor weet je niet welke laag afbrak en vergroot je de maximale belasting.
Het laatst genoemde PHP-bestand als oorzaak aanwijzen. Dat kan alleen het punt zijn waar de tijd opraakte.
Een 504 behandelen als bewezen PHP-fatal. Een gateway kan eerder stoppen zonder die PHP-melding.
Onbegrensde uitvoering toestaan. Een lus of trage externe dienst kan dan workers blijven bezetten.
.htaccess-instructies op iedere PHP-handler toepassen. Een ongeldige directive kan een 500 veroorzaken.
Een grote taak telkens live herhalen. Mislukte pogingen kunnen gedeeltelijke of dubbele data achterlaten.
WP-Cron-events blind verwijderen. Bepaal eerst welke plugin of coretaak ze gebruikt.
Debugweergave voor bezoekers aanzetten. Log op staging of buiten de publieke uitvoer.
Geen oude configuratiewaarden bewaren. Zonder rollback kun je een verslechtering niet gecontroleerd herstellen.

Wanneer je hosting of een ontwikkelaar nodig hebt

Vraag hostingbeheer om hulp wanneer je geen PHP-FPM-, webserver- of proxylogs ziet, wanneer de effectieve PHP-waarde afwijkt van je instelling of wanneer het platform een vaste requestduur gebruikt. Laat een ontwikkelaar de taak aanpassen als logs wijzen op recursie, zware queries, ontbrekende batching of een externe koppeling zonder foutafhandeling.

Meer veilige herstelroutes staan op de WordPress-hub. Wil je dat iemand de timeoutlaag en de werkelijke codeoorzaak gecontroleerd onderzoekt, vraag een offerte aan via WhatsApp, mail naar w.bouwmeester@bouwmeesterconsultancy.nl of bel 0628963636.