Waarom blijft WordPress in onderhoudsmodus hangen?

WordPress maakt tijdens bepaalde updates een .maintenance-bestand en verwijdert het normaal na afloop. Als een updateproces wordt onderbroken door een timeout, verbroken verbinding, rechtenprobleem of fout bij het kopiëren, kan het bestand blijven staan of kan een cache de onderhoudspagina blijven tonen.

Kan ik .maintenance meteen verwijderen?

Niet zolang een update mogelijk nog actief bestanden kopieert. Controleer eerst andere beheerders, actieve hosting- of CLI-taken, logs en recente bestandswijzigingen. Maak daarna een back-up en hernoem een achtergebleven bestand, zodat je het kunt terugzetten.

Waar staat het .maintenance-bestand?

Het staat in de WordPress-root, dezelfde map waarin doorgaans wp-admin, wp-content, wp-includes en wp-config.php staan. Het is een verborgen bestand, dus zet in SFTP of het hostingpaneel zo nodig de weergave van verborgen bestanden aan.

Waarom zie ik de onderhoudsmelding zonder .maintenance-bestand?

De pagina kan nog in browser-, plugin-, server- of CDN-cache staan, of een onderhoudsplugin en hostingfunctie kan een eigen modus gebruiken. Controleer de echte HTTP-response, leeg alleen de relevante cache en zoek welke laag de pagina levert.

Verwijdert WordPress .maintenance vanzelf?

Een normale WordPress-upgrade schakelt onderhoudsmodus na afloop uit. WordPress behandelt een regulier .maintenance-bestand met een upgrading-tijdstempel bovendien na tien minuten niet meer als actieve core-onderhoudsmodus, maar een cache of afwijkende onderhoudsoplossing kan langer zichtbaar blijven.

Hoe controleer ik of een WordPress-update compleet is?

Vergelijk versies in Dashboard > Updates, lees de update- en errorlogs en test frontend, beheer en belangrijke functies. Met bevoegde WP-CLI-toegang kun je WordPress-core en ondersteunde WordPress.org-plugins tegen officiële checksums controleren.

Wat doe ik als de site na het hernoemen van .maintenance een fout geeft?

Zet de onderhoudsnaam zo nodig tijdelijk terug om bezoekers geen gedeeltelijke site te tonen, maar beschouw dat niet als reparatie. Herstel de mislukte component via de officiële updateprocedure of zet de volledige bestanden-en-databaseback-up van vóór de update terug.

WordPress blijft in onderhoudsmodus hangen (2026)

Blijft WordPress hangen op “Briefly unavailable for scheduled maintenance”, dan is een update waarschijnlijk onderbroken of zie je nog een gecachte onderhoudspagina. Controleer eerst of geen updateproces meer actief is, maak een herstelset en hernoem pas daarna het achtergebleven .maintenance-bestand voordat je de update-integriteit controleert.

Waarom WordPress deze melding toont

WordPress gebruikt voor core-, plugin- en thema-updates tijdelijk onderhoudsmodus. De coremethode WP_Upgrader::maintenance_mode() maakt in de WordPress-root een bestand met de naam .maintenance en verwijdert dat normaal wanneer de updater de modus uitschakelt.

De standaard onderhoudsresponse heeft status 503 en een Retry-After-header. Dat blijkt uit de officiële bronbeschrijving van wp_maintenance(). Een 503 tijdens een lopende update is dus niet automatisch een storing. Het wordt pas een herstelprobleem wanneer de update niet meer loopt, maar bezoekers de melding blijven zien.

WordPress controleert de tijdstempel in .maintenance. Volgens wp_is_maintenance_mode() geldt een regulier bestand met een $upgrading-tijdstempel van tien minuten of ouder niet meer als actieve core-onderhoudsmodus. Zie je daarna nog steeds de pagina, controleer dan cache, een afwijkend bestand of een aparte onderhoudsfunctie.

Controleer vóór je een bestand aanraakt

Verwijder .maintenance niet terwijl een update nog bestanden kopieert. De onderhoudspagina beschermt bezoekers dan tegen een combinatie van oude en nieuwe code.

Controleer:

of een collega of beheerder de update nog uitvoert;
of een terminal met WP-CLI nog actief is;
of het hostingpaneel een update- of herstelactie toont;
of update-, PHP- en serverlogs nog voortgang registreren;
of bestanden in de betrokken core-, plugin- of themamap nog recent veranderen;
welk onderdeel en welke versie werden bijgewerkt.

Een langlopende update kan ook door een uitvoeringstijd zijn afgebroken. Staat in de log Maximum execution time exceeded of een 504, onderzoek dan eerst de WordPress-timeoutlaag. Start niet tegelijk een tweede update.

Stappenplan: onderhoudsmodus veilig herstellen

1. Leg de beginsituatie en update vast

Noteer de exacte melding, het tijdstip waarop de update begon, de beheerder die haar startte en de bijgewerkte onderdelen. Maak screenshots van het hostingpaneel en Dashboard > Updates als dat nog bereikbaar is. Download de relevante update- en errorlogs.

Controleer de HTTP-status in de netwerkdetails van je browser. Een standaard WordPress-onderhoudspagina hoort bij een 503. Een 500, kritieke fout of leeg scherm vraagt mogelijk om de decoder voor een 500 Internal Server Error, een kritieke WordPress-fout of een wit WordPress-scherm.

2. Wacht op een aantoonbaar actief updateproces

Loopt een beheer-, CLI- of hostingtaak nog en veranderen de doelbestanden, laat die taak afronden. Sluit het browservenster van een actieve handmatige update niet bewust en herstart geen web- of PHP-dienst midden in het kopiëren.

Is er langere tijd geen voortgang, verzamel dan eerst de laatste logregel en processtatus. Vraag bij managed hosting of de updateworker nog leeft. Alleen een draaiend proces in een lijst is onvoldoende bewijs: controleer ook CPU-, log- of bestandsactiviteit. Laat de provider een vastgelopen worker gecontroleerd beëindigen als je daar zelf niet verantwoordelijk voor bent.

3. Maak een bruikbaar herstelpunt

Gebruik bij voorkeur de complete bestanden-en-databaseback-up van vóór de update. Maak daarnaast vóór je .maintenance wijzigt een momentopname van de huidige staat en bewaar de logs. Die huidige kopie is nuttig voor onderzoek, maar kan gedeeltelijk bijgewerkte code bevatten en vervangt daarom niet automatisch de laatste bekende goede back-up.

De officiële WordPress-handleiding voor back-ups legt uit dat bestanden en database allebei nodig zijn voor volledig herstel. Controleer de locatie, datum en terugzetprocedure. Download ook .maintenance afzonderlijk, inclusief de inhoud en wijzigingsdatum.

4. Zoek het juiste .maintenance-bestand

Open via SFTP of het hostingbestandsbeheer de WordPress-root. Dit is doorgaans de map met:

wp-admin/
wp-content/
wp-includes/
wp-config.php
.maintenance

Zet de weergave van verborgen bestanden aan als .maintenance niet zichtbaar is. Controleer dat je niet in een bovenliggende domeinmap of een oude staginginstallatie kijkt. Bij meerdere WordPress-installaties kan ieder exemplaar een eigen root hebben.

Open het bestand alleen om de inhoud en tijdstempel te controleren. Een door WordPress gemaakte variant bevat een PHP-waarde voor $upgrading. Voeg daar geen eigen logica aan toe.

5. Sluit cache en een aparte onderhoudsmodus uit

Is .maintenance afwezig of negeert WordPress het bestand al op basis van de tijdstempel, vraag de pagina dan op in een privévenster en controleer responseheaders. Leeg vervolgens alleen de relevante browser-, plugin-, server- en CDN-cache.

Controleer ook:

een actieve onderhouds- of coming-soon-plugin;
een hostingknop voor onderhoudsmodus;
een statische onderhoudsregel van de proxy;
een aangepaste wp-content/maintenance.php;
een andere documentroot dan de map die je hebt geopend.

wp-content/maintenance.php kan de standaardtekst vervangen, maar WordPress laadt die binnen zijn eigen actieve onderhoudscontrole. Verwijder dit bestand niet blind: het kan bewuste huisstijl of statusinformatie bevatten.

6. Hernoem het achtergebleven bestand omkeerbaar

Heb je vastgesteld dat geen update meer actief is en heb je de back-ups gecontroleerd, hernoem dan:

.maintenance

naar bijvoorbeeld:

.maintenance.stuck-20260728

Hernoemen bewaart inhoud, rechten en tijdstempel voor rollback en onderzoek. De officiële WordPress-handleiding voor updaten noemt het verwijderen van .maintenance na een mislukte update; een tijdelijke hernoeming is hier de voorzichtige, herstelbare uitvoering daarvan.

Vraag eerst de homepage en /wp-admin/ op zonder cache. Krijg je nu een fatale fout of ontbrekende bestanden, zet de naam tijdelijk terug om bezoekers af te schermen. De onderhoudsmodus is dan niet de oorzaak, maar maskeerde een onvolledige update.

7. Bepaal welk onderdeel onvolledig is

Open Dashboard > Updates en vergelijk:

geïnstalleerde WordPress-versie;
plugins en thema’s die nog een update aanbieden;
foutmeldingen of een verzoek om de update opnieuw uit te voeren;
de logregel vlak vóór het proces stopte.

De officiële uitleg van het Dashboard Updates-scherm toont dat WordPress onderhoudsmodus rond bulkupdates in- en uitschakelt en adviseert vóór upgraden een back-up van database en bestanden.

Controleer de map van de betrokken plugin of het thema op een versie die past bij het dashboard en de bron. Verwijder niet op goed geluk een oude of nieuwe map. Een updater kan al een deel hebben verplaatst, en maatwerkbestanden zijn niet altijd opnieuw te downloaden.

8. Controleer core- en pluginbestanden

Alleen met bevoegde WP-CLI-toegang: controleer WordPress-core tegen de officiële checksums:

wp core verify-checksums

De officiële documentatie van wp core verify-checksums legt uit dat dit vóór het laden van WordPress draait en versie en locale kan meenemen. Een mismatch betekent dat je de genoemde bestanden moet onderzoeken; overschrijf ze niet zonder te bevestigen welke coreversie hoort te staan.

Voor plugins uit WordPress.org kun je aanvullend gebruiken:

wp plugin verify-checksums --all --strict

De officiële wp plugin verify-checksums-documentatie waarschuwt dat voor maatwerk of elders geleverde plugins mogelijk geen WordPress.org-checksums bestaan. Een overgeslagen plugin is dus geen bewijs dat hij goed of fout is.

9. Rond alleen de mislukte update gecontroleerd af

Werk één component tegelijk bij. Begin met het onderdeel dat volgens de log niet is afgerond en controleer dat schrijfrechten en vrije opslagruimte kloppen. Gebruik voor coreherstel de officiële procedure voor WordPress bijwerken en bewaar wp-content en wp-config.php volgens die instructies.

Start geen bulkupdate terwijl je nog niet weet welke component half is geïnstalleerd. Wijzig geen versienummers of update-opties rechtstreeks in de database om het dashboard groen te maken. Als WordPress na een complete core-update zelf een database-upgrade vraagt, volg die officiële beheerroute alleen met een geverifieerde back-up.

Faalt dezelfde component opnieuw, stop dan. Herstel de vorige werkende versie vanuit je back-up of laat leverancier en hosting de concrete foutlog beoordelen.

10. Test de update-integriteit en ruim tijdelijk werk op

Controleer na succesvol herstel:

homepage en meerdere contentpagina’s;
login en alle belangrijke beheerschermen;
formulieren, zoeken, uploads en geplande taken;
frontendfuncties van de bijgewerkte plugin of het thema;
REST-route /wp-json/;
PHP-, update- en serverlogs;
versies en beschikbare updates;
core- en toepasbare pluginchecksums.

Test ook een functie die schrijft, bijvoorbeeld een concept opslaan, zonder productiedata onnodig te veranderen. Komt daarbij een geheugenfout naar voren, gebruik dan de gerichte uitleg voor de WordPress memory-limit-fout.

Verwijder de hernoemde .maintenance-kopie pas nadat de update volledig is gevalideerd en je de relevante informatie elders hebt bewaard. Ruim tijdelijke updatebestanden niet op zolang je niet zeker weet dat geen herstel- of updateproces ze gebruikt.

Veelgemaakte fouten

.maintenance verwijderen terwijl de update nog loopt. Bezoekers kunnen dan gedeeltelijk gekopieerde code uitvoeren.
Alleen op de verstreken tijd vertrouwen. Controleer proces, logs en bestandsactiviteit.
Geen back-up van bestanden én database hebben. Een gedeeltelijke update kan beide lagen raken.
Het bestand in de verkeerde WordPress-root aanpassen. Meerdere installs en submappen maken dit makkelijk.
Een gecachte onderhoudspagina voor actuele originstatus aanzien. Controleer headers en de juiste cachelaag.
Een onderhoudsplugin of hostingmodus vergeten. Die werkt los van WordPress-core .maintenance.
Meteen alle updates opnieuw starten. Werk één mislukte component gecontroleerd af.
Een groen dashboard als volledige integriteitscheck zien. Test bestanden, functies, logs en checksums.
De onderhoudspagina terugzetten als reparatie beschouwen. Zij schermt een kapotte site af, maar herstelt geen bestanden.

Wanneer je hosting of een ontwikkelaar nodig hebt

Schakel hostingbeheer in wanneer je niet kunt zien of een updateworker actief is, geen complete back-up kunt herstellen, onvoldoende opslag of verkeerde eigenaar vermoedt, of de onderhoudspagina uit een beheerde proxy komt. Laat een ontwikkelaar meekijken bij checksumverschillen, maatwerkplugins, herhaalde updatefouten of een site die na herstel een fatale fout toont.

Meer foutdecoders en veilige WordPress-routes staan op de WordPress-hub. Wil je dat iemand de update en herstelset gecontroleerd verifieert, vraag een offerte aan via WhatsApp, mail naar w.bouwmeester@bouwmeesterconsultancy.nl of bel 0628963636.