Maximum execution time exceeded — sådan får du opgaven færdig

Kort svar: “Maximum execution time of 30 seconds exceeded” betyder, at PHP stoppede et script, fordi det kørte længere end max_execution_time tillader. Læs fil og linje i fejlen for at se, hvilket plugin eller tema der arbejdede. Er det en engangsopgave som import eller migrering, så kør den med WP-CLI eller hæv grænsen midlertidigt. Sker det ved almindelige sidevisninger, er tiden et symptom – find det langsomme kald i stedet for at give det længere snor.

Fagligt gennemgået: 2. oktober 2026

“Maximum execution time of 30 seconds exceeded” betyder, at et PHP-script kørte længere, end serveren tillader, og blev stoppet. Det sker typisk under opdateringer, import, backup eller billedbehandling – men det kan også ramme helt almindelige sider, når en database- eller API-forespørgsel er blevet for tung.

Grænsen findes for at beskytte serveren mod scripts, der aldrig bliver færdige. At hæve den er nogle gange rigtigt – men lige så ofte er det opgaven, der skal deles op eller flyttes væk fra browseren.

Før du ændrer noget: Tag en backup af filer og database, især hvis fejlen ramte midt i en opdatering, import eller søg-og-erstat. En afbrudt opgave kan have efterladt halvt opdaterede data. Notér også den præcise fejltekst med fil, linje og tidspunkt – den er dit vigtigste spor.

Hvornår opstår fejlen – og hvad betyder det?

Situation	Sandsynlig årsag	Første løsning
Under import, migrering eller billedgenberegning	Opgaven er reelt stor	Kør den med WP-CLI eller i mindre bidder
Under en plugin- eller WordPress-opdatering	Langsom download, udpakning eller databaseopgradering	Fjern .maintenance, kør opdateringen igen – helst med WP-CLI
Ved almindelige sidevisninger	Tung databaseforespørgsel eller ophobet wp-cron	Find den langsomme forespørgsel, ret cron
Kun ved én bestemt handling, fx gem eller checkout	Et plugin, der venter på noget eller looper	Fil og linje i fejlen, derefter pluginets log
Beskeden siger 30 sek., selv om panelet siger mere	Grænsen sættes ned et andet sted	Tjek .user.ini, php.ini og set_time_limit()

1. Læs fejlbeskeden – den fortæller, hvor problemet sidder

Beskeden nævner altid en fil og et linjenummer, fx:

PHP Fatal error:  Maximum execution time of 30 seconds exceeded in /wp-content/plugins/et-plugin/inc/import.php on line 214

Det er ikke nødvendigvis dér, fejlen ligger – det er der, tiden løb ud. Men filstien peger på det plugin eller tema, der stod for arbejdet, og det er nok til at vide, hvor du skal lede. Ligger filen under wp-includes, er det som regel WordPress selv, der arbejdede på vegne af noget andet: et plugin, der bad om en tung forespørgsel, eller en løkke, der aldrig blev færdig.

Ser du ikke fejlen på skærmen, så find den i PHP-fejlloggen i kontrolpanelet, eller slå WordPress’ egen logning til kortvarigt:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Konstanterne placeres i wp-config.php før linjen “That’s all, stop editing”. Loggen skrives til wp-content/debug.log. Slå logningen fra igen, når du har fundet fejlen. Får du en kritisk fejl i stedet for den rå besked, er det samme fatale fejl – WordPress viser blot den neutrale besked til besøgende.

2. Find ud af, hvor grænsen faktisk bliver sat

Grænsen på 30 sekunder er PHP’s standard, men den kan være sat flere steder, og det højeste niveau vinder ikke altid:

1. Kontrolpanelets PHP-indstillinger sætter max_execution_time for hele sitet.
2. En .user.ini eller php.ini i roden kan overstyre panelet. Ændringer i .user.ini læses typisk først igen efter nogle minutter, fordi PHP cacher filen.
3. Et plugin kan sætte den i farten med set_time_limit() – både op og ned.
4. Serveren kan have en hård grænse, som du ikke selv kan ændre, fx en timeout i PHP-FPM eller i webserveren foran PHP.

Ser du 30 sekunder i beskeden, selv om panelet siger 300, er det næsten altid et plugin eller en fil i roden, der trækker den ned igen. Den aktuelle værdi kan du se under Værktøjer → Webstedstilstand → Info → Server i WordPress, eller med WP-CLI:

wp eval 'echo ini_get("max_execution_time");'
grep -rn "set_time_limit" wp-content/plugins/ | head

Bemærk, at wp eval kører fra kommandolinjen, hvor grænsen normalt er 0 (ingen grænse). Værdien i Webstedstilstand er den, webserveren bruger, og det er den, der tæller for besøgende.

3. Hæv grænsen kun til engangsopgaver

Hæv den, hvis opgaven er engangs og reelt tager tid: en stor import, en migrering, en genberegning af billedstørrelser. Sæt den i kontrolpanelet under PHP-indstillinger:

max_execution_time = 300

Sæt den tilbage bagefter. En permanent høj grænse betyder blot, at en fejlende proces får lov at holde en PHP-proces besat i fem minutter. På et site med få PHP-processer kan nogle få hængende requests være nok til, at nye besøgende må vente – og så får du 503- eller 504-fejl oven i den oprindelige fejl.

Kan du sætte den i wp-config.php? Det er muligt at skrive set_time_limit( 300 ); i filen, men mange servere ignorerer det, fordi funktionen er slået fra, eller fordi en hårdere grænse i serveren stopper requesten alligevel. Brug kontrolpanelet, så ved du, hvor værdien kommer fra.

4. Kør store opgaver uden tidsgrænse med WP-CLI

Tidsgrænsen gælder, når PHP kører gennem webserveren. Kører du den samme opgave fra kommandolinjen, er grænsen som udgangspunkt slået fra, og det er derfor, de tunge ting hører hjemme dér. Med WP-CLI kan du fx genberegne billedstørrelser, søge og erstatte i databasen efter en flytning eller køre WooCommerce-opgaver færdige, uden at nogen besøgende betaler for det:

wp media regenerate --yes
wp search-replace 'http://gammel.dk' 'https://ny.dk' --dry-run
wp action-scheduler run
wp core update-db

Kør altid search-replace med --dry-run først, og fjern det, når tallene ser rigtige ud. Har du ikke SSH-adgang, kan supporten hos de fleste udbydere køre kommandoen for dig. Det er en bedre løsning end at hæve grænsen til 600 sekunder og håbe, at importen bliver færdig, før browseren giver op. Se WP-CLI for begyndere for flere kommandoer.

Kan opgaven ikke køres fra kommandolinjen, så del den op. De fleste import-plugins kan importere i batches på fx 100 rækker ad gangen, og en stor CSV-fil kan deles i flere mindre filer. Hver batch er så sin egen request med sine egne 30 sekunder.

5. Ret wp-cron, hvis fejlen rammer tilfældige besøgende

WP-cron kører planlagte opgaver, når nogen besøger siden. Er der ophobet mange, kan én besøgende komme til at udføre dem alle på én gang – og ryge over grænsen. Kendetegnet er, at fejlen rammer tilfældige sider på tilfældige tidspunkter, og at filstien peger på et plugin med planlagte opgaver (backup, nyhedsbrev, feeds, WooCommerce).

define( 'DISABLE_WP_CRON', true );

Læg linjen i wp-config.php og opret i stedet et rigtigt cron-job i kontrolpanelet, der kører hvert femte minut. Vælg helst en kommando, der kører PHP fra kommandolinjen, så tunge opgaver ikke rammer webserverens tidsgrænse:

*/5 * * * * cd /sti/til/sitet && wp cron event run --due-now >/dev/null 2>&1

Et cron-job, der i stedet henter https://ditdomaene.dk/wp-cron.php med wget eller curl, går gennem webserveren og er stadig underlagt max_execution_time. Det løser problemet med tilfældige besøgende, men ikke med opgaver, der i sig selv er for lange. Læs mere i wp-cron virker ikke.

6. Hvis det sker ved almindelige sidevisninger

Sker det ved helt almindelig brug – en produktoversigt, en søgning, en sidevisning – er tiden symptomet, ikke problemet. En normal sidevisning bør tage langt under et sekund på serveren. Så skal du finde ud af, hvad der er langsomt, ikke give det længere snor.

• En database uden index. En tabel med 300.000 rækker i wp_postmeta uden de rigtige index gør en simpel søgning til et minutlangt job. Find de langsomme forespørgsler med Query Monitor, før du rører grænsen.
• Uendelige løkker. Et plugin, der opdaterer et indlæg, som udløser et hook, som opdaterer indlægget igen. Fejlen rammer så altid samme fil og samme handling.
• Billedbehandling ved upload. Et 20 MB-foto skaleres til mange størrelser, og hver skalering tager tid. Skalér billederne ned, før de uploades, eller lad serveren konvertere i baggrunden.
• Ophobede data. Store mængder transients, revisioner eller logrækker gør forespørgslerne langsommere over tid. Start med optimering af databasen.

Eksterne kald: hvorfor du nogle gange får 504 i stedet

Et plugin, der spørger en ekstern tjeneste, som ikke svarer, kan vente længe. På Linux tæller den tid, PHP bruger på at vente på netværk, database og systemkald, som udgangspunkt ikke med i max_execution_time. Derfor ender et hængende API-kald ofte ikke med denne fejl, men med en 504 Gateway Timeout, fordi webserveren eller proxyen foran PHP giver op først. Ser du begge fejl på samme handling, så kig efter eksterne kald uden timeout i det plugin, filstien peger på – og slå integrationen fra, indtil tjenesten er oppe.

7. Hvis det sker under en opdatering

Bliver siden hængende i vedligeholdelsestilstand, fordi opdateringen blev afbrudt, slettes filen .maintenance i roden. Kontrollér derefter, at plugin- eller temamappen ikke er halvt udpakket – står der en mappe i wp-content/upgrade, eller mangler der filer i pluginet, så installér den samme version igen. Kør derefter opdateringen igen – helst i et testmiljø først, og gerne med WP-CLI:

wp plugin update plugin-navn
wp core update
wp core update-db

Se også WordPress sidder fast i vedligeholdelsestilstand.

Verificér, at problemet er løst

• Gentag præcis den handling, der fejlede – samme import, samme side, samme knap.
• Kontrollér PHP-fejlloggen for nye “Maximum execution time”-linjer efter testen.
• Sæt en midlertidigt hævet grænse tilbage til normalværdien, og test igen.
• Tjek under Værktøjer → Planlagte handlinger (eller WooCommerce → Status), at der ikke ligger en ophobning af opgaver, der venter.
• Slå WP_DEBUG fra igen, hvis du slog det til.

Når sitet er vokset fra sin hosting

Rammer du fejlen igen og igen på et site, der ikke er blevet ændret, er det tegn på, at sitet er vokset fra sin hosting. Flere produkter, flere ordrer og flere plugins giver længere forespørgsler, og på et delt webhotel deler du oven i købet processorkraften med andre. Inden du skifter, så saml dokumentationen: fejltekst, fil, linje, tidspunkt og hvilken handling der udløste den. Med det kan en udvikler eller supporten se, om det er koden eller kapaciteten, der er flaskehalsen. På WordPress hosting hos Hostious kører sitet på LiteSpeed og NVMe, og den danske support kan hjælpe dig med at læse loggen.

Læs også

• Hub: WordPress fejl og fejlfinding
• 504 Gateway Timeout i WordPress
• Allowed memory size exhausted i WordPress
• wp-cron virker ikke: planlagte opgaver kører aldrig
• WP-CLI for begyndere
• WordPress hosting hos Hostious – fra 39 kr./md. ekskl. moms med dansk support
• Hastighedsoptimering af WordPress – vi finder og fjerner flaskehalsene for dig

Ofte stillede spørgsmål om maximum execution time

Hvorfor er grænsen kun 30 sekunder?

Fordi en normal sidevisning tager under et sekund. 30 sekunder er allerede rundhåndet – det er beregnet til tunge enkeltopgaver, ikke til besøgende, der venter.

Kan jeg sætte den i wp-config.php?

Ofte ikke. Mange servere ignorerer det, fordi grænsen er låst eller set_time_limit() er slået fra. Brug kontrolpanelet.

Hvorfor virker det ikke, når jeg hæver max_execution_time i kontrolpanelet?

Fordi en .user.ini eller php.ini i sitets rod, eller et plugin der kalder set_time_limit(), kan sætte grænsen ned igen. Tjek roden for de to filer, og søg i plugins efter set_time_limit.

Gælder tidsgrænsen også for WP-CLI og cron?

Ikke for WP-CLI og cron-jobs, der kører PHP direkte fra kommandolinjen – dér er grænsen som udgangspunkt slået fra. Et cron-job, der kalder wp-cron.php via wget eller curl, går derimod gennem webserveren og har den samme grænse som en sidevisning.

Hvad er forskellen på denne fejl og 504 Gateway Timeout?

Maximum execution time er PHP, der stopper sit eget script. 504 er webserveren eller proxyen foran PHP, der giver op, fordi svaret ikke kom i tide. Venter scriptet på et eksternt kald eller databasen, får du ofte 504, fordi den ventetid typisk ikke tæller med i PHP’s egen grænse.