"Briefly unavailable for scheduled maintenance" — WordPress onderhoudsmodus oplossen

De volledige meldingen die je in beeld krijgt:

Briefly unavailable for scheduled maintenance.
Check back in a minute.

Op Nederlandse installaties:

Even niet beschikbaar voor gepland onderhoud.
Kom over een minuut terug.

Op nog oudere/handmatig vertaalde installaties zie je soms varianten als "Tijdelijk niet beschikbaar wegens gepland onderhoud". Hetzelfde mechanisme, hetzelfde fix.

Wat is dit eigenlijk?

Wanneer WordPress aan een update begint (core, plugin of theme), maakt 'ie een leeg bestand met de naam .maintenance in de hoofdmap van je installatie. Zolang dat bestand bestaat, toont WordPress aan iedereen — bezoekers, jou, Googlebot — diezelfde maintenance-melding in plaats van de site.

Tijdens een normale update gebeurt dit:

1. WordPress maakt .maintenance aan → site offline
2. Bestanden worden vervangen, database wordt bijgewerkt
3. WordPress verwijdert .maintenance → site online

Het hele proces duurt typisch 10-30 seconden. Maar als stap 2 mislukt — bijvoorbeeld de browser wordt gesloten, PHP loopt over de timeout, het geheugen raakt op, of de server-verbinding valt weg — dan wordt stap 3 nooit uitgevoerd. Het .maintenance-bestand blijft staan, en WordPress blijft denken: "er is een update bezig, ik moet de site offline houden."

Je site is technisch helemaal niet kapot. Eén leeg bestand verwijderen en je bent weer live.

De automatische 10-minuten-regel — wachten is óók een optie

WordPress heeft een ingebouwde veiligheidsklep: als het .maintenance-bestand ouder dan 10 minuten is, negeert WP het automatisch en gaat de site weer online. Dus als je nu 11 minuten wacht, lost het probleem zichzelf op zonder dat je iets hoeft te doen.

In de praktijk wachten weinig mensen 10 minuten — bezoekers en Googlebot evenmin. Door .maintenance handmatig te verwijderen ben je in 30 seconden klaar. Hieronder de drie methodes.

Methode 1: via je hosting file manager (meest direct)

De snelste route als je geen FTP-client klaar hebt staan:

1. Log in op je hosting control panel (cPanel, Plesk, DirectAdmin, of provider-specifiek)
2. Open de File Manager
3. Navigeer naar de hoofdmap van je site — vaak public_html/, httpdocs/ of www/
4. Belangrijk: zet "verborgen bestanden tonen" aan. Bestanden die met een punt beginnen (zoals .maintenance en .htaccess) zijn standaard verborgen op Linux
5. Zoek .maintenance en verwijder het
6. Refresh je site — terug online

Per control panel verschilt waar je "verborgen bestanden tonen" aan zet:

• cPanel File Manager: bovenin "Settings" → "Show Hidden Files (dotfiles)"
• Plesk File Manager: tandwieltje rechtsboven → "Show Hidden Files"
• DirectAdmin: meestal onder "View" of in instellingen

Methode 2: via FTP/SFTP

1. Open je FTP-client (FileZilla, Cyberduck, Transmit)
2. Verbind met je site
3. Zorg dat verborgen bestanden zichtbaar zijn — in FileZilla: Server → Force showing hidden files
4. Navigeer naar de hoofdmap van WordPress (waar wp-config.php staat)
5. Verwijder .maintenance
6. Refresh site

Methode 3: via SSH (snelste als je terminal-toegang hebt)

cd /home/jouwsite/public_html  # of waar WP draait
ls -la .maintenance              # check of 't bestaat
rm .maintenance                  # verwijder

Drie commando's, klaar in 5 seconden. Voor power users de beste route.

Methode 4: via WP-CLI (handig als je dit vaker doet)

wp maintenance-mode deactivate

WP-CLI heeft een ingebouwd subcommando dat 't bestand veilig verwijdert. Werkt vaak zelfs als WP niet helemaal stabiel is.

Stap 2: controleer of de update wél is afgerond

Site is weer online — maar de update die de boel deed crashen is misschien half doorgevoerd. Check:

Welke update was bezig?

Ga in wp-admin naar Dashboard → Updates. Zie je daar dezelfde plugin/theme/core nog als "update beschikbaar", dan is de update gedeeltelijk mislukt. Lopende plugin-bestanden zijn deels vervangen, maar database-updates of finale wijzigingen ontbreken.

Aanpak: voer de update opnieuw uit. Meestal pakt WordPress het waar 't gestopt was en gaat het deze keer wel door. Wel eerst zorgen dat het rootprobleem (zie hieronder) is opgelost.

Werkt de site goed?

Klik door de homepage, een productpagina, een blogpost, het contactformulier, en log eens uit en weer in. Half voltooide updates kunnen rare side-effects hebben:

• Plugin werkt niet meer correct (helft op nieuwe versie, helft op oude)
• Database-schema-mismatch — sommige plugins triggeren database-updates die niet hebben gelopen
• Cache toont oude content terwijl onderliggende data nieuw is
• Critical error die nu ergens anders verschijnt — zie WordPress critical error oplossen

Check debug.log

Tijdens een mislukte update worden vaak fatal errors gelogd. Zet WP_DEBUG_LOG aan (zie hetzelfde stappenplan in het critical-error-artikel hierboven), refresh, lees wp-content/debug.log. Zie je daar errors die direct in plugin-of theme-bestanden voorkomen, dan is de update niet schoon doorgekomen.

Waarom liep de update vast? — vijf veelvoorkomende oorzaken

Als .maintenance blijft hangen, ging er tijdens de update iets mis. Belangrijk om te weten welk type, want anders gebeurt het bij de volgende update opnieuw.

1. PHP memory_limit te krap

Updates zijn geheugen-intensief: bestanden worden in geheugen ingelezen, gepatcht, weggeschreven. Op een 64 MB-limiet crasht dat regelmatig. Als je wp-content/debug.log of server error_log "Allowed memory size exhausted" bevat, dat is je oorzaak. Verhogen — zie Allowed memory size exhausted oplossen.

2. PHP max_execution_time bereikt

Standaard 30 seconden. Een grote update (bijvoorbeeld WooCommerce of een major core-update) kan langer duren. Foutmelding in error_log: "Maximum execution time of 30 seconds exceeded". Verhoog tijdelijk via .htaccess of php.ini:

// In .htaccess (als je hoster php_value toestaat)
php_value max_execution_time 300

// Of in .user.ini / php.ini
max_execution_time = 300

3. Browser gesloten of internet weggevallen tijdens update

Klassieker: je drukt op "update", WordPress zet onderhoudsmodus aan, en daarna sluit je per ongeluk de tab — of je wifi valt weg. WP-side draait de update meestal toch door. Maar als de PHP-request tussen browser en server wordt afgekapt, kan WP de finale stap (de .maintenance-removal) missen.

Preventie: laat altijd een tabblad open tijdens updates. Of gebruik WP-CLI voor updates — dat draait server-side, maakt niet uit of jouw browser openblijft.

4. Plugin- of theme-conflict

Een plugin doet iets onverwachts tijdens andere plugin's updateproces (bijvoorbeeld een security-plugin die het update-bestand "verdacht" vindt en blokkeert). Resultaat: update faalt halverwege. Soms zie je dan ook fatal errors in debug.log.

Preventie: deactiveer security/firewall-plugins tijdens grote updates. Of werk via staging eerst.

5. Disk space vol

Op shared hosting met krappe quota: WordPress kan het update-bestand niet uitpakken omdat de schijf vol is. Check via control panel of CLI: df -h. Bij 95%+ benut: opruimen (oude backups, logs) of upgraden van pakket. Zonder ruimte komt geen enkele update door.

Voorkomen dat het weer gebeurt

• Test grote updates op staging. Een staging-omgeving vangt 90% van de problemen voor ze productie raken. Zie WordPress staging site opzetten
• Backup vóór elke update. Als de update echt strandt en je moet rollbacken, scheelt dat uren werk
• Update via WP-CLI als je SSH hebt: wp core update, wp plugin update --all. Geen browser-afhankelijkheid, beter geheugenbeheer, en je ziet in real-time of er iets crasht
• Update buiten piekuren: 's avonds of 's nachts. Minder bezoekers betekent minder kans op resource-pieken die de update doen falen
• Niet meerdere plugins tegelijk updaten. Update er één, check, dan de volgende. Lijkt traag, maar als er één crasht weet je direct welke
• Verhoog memory_limit naar minimaal 256 MB voor admin-acties (WP_MAX_MEMORY_LIMIT in wp-config.php)
• Verhoog max_execution_time voor updates — 60-120 seconden is gangbaar veilig

Aanverwante gevallen

"Maintenance Mode"-plugin actief

Niet hetzelfde probleem: sommige sites gebruiken een plugin (Coming Soon Page, WP Maintenance Mode, etc.) die bewust een onderhoudspagina toont. Tekst is dan vaak custom en mooier opgemaakt. Fix: log in op wp-admin, deactiveer de plugin of zet 'm uit op het instellingen-paneel.

503 Service Unavailable

Tijdens echte server-onderhoud krijg je een 503-status, geen WordPress-melding. Dat is server-niveau, niet WP-niveau. Check je hoster's status-pagina.

Custom WordPress maintenance via .htaccess

Sommige beheerders zetten zelf een onderhoudsbestand neer met een redirect-rule in .htaccess. Herken je aan een eigen design en consistent gedrag op alle URL's. Verwijder de regel uit .htaccess om terug live te gaan. Zie ook .htaccess uitgelegd.

Wanneer schakel je hulp in?

• Je verwijdert .maintenance en de site komt nog steeds niet terug — dan zit er een dieper probleem (database, fatal error, hosting-issue)
• Update is half doorgekomen, site werkt nu raar, je weet niet welke versies waar zitten
• Telkens als je een update doet komt de site in onderhoudsmodus vast — terugkerend rootprobleem
• WooCommerce-shop met live klanten: elke minuut downtime kost orders, je wilt geen experimenteer-aanpak
• Geen toegang tot file manager, FTP of SSH — soms heeft de website-eigenaar nooit credentials gehad
• Combineert met andere errors (critical error, mysqli-fouten, memory exhausted) — meerdere problemen tegelijk vraagt geconsolideerde aanpak

Een vastzittende WordPress-onderhoudsmodus is een 30-seconden-fix met de juiste tools. De vraag is meestal niet hoe je .maintenance verwijdert, maar waarom 'ie er nog stond — en die oorzaak vindt en oplost vóór de volgende update opnieuw vastloopt. Dat tweede deel is waar het werk zit.