Contact
← Terug naar kennisbank HOSTING

503 Service Unavailable — wat het betekent en hoe je 'm oplost

Je site geeft "503 Service Unavailable" of "Service Temporarily Unavailable". De server zegt: "Ik leef nog, maar ik kan jouw verzoek nu niet aan." Anders dan een 500 (applicatie crashte) of een 502/504 (gateway-probleem) is een 503 een bewuste afwijzing — door overload, rate limits, bewust onderhoud, of WAF/protectie. Deze gids legt uit wáárom de server weigert en hoe je 'm fixt.

11 min lezen · Laatst gecheckt:

De varianten:

  • 503 Service Unavailable
  • 503 Service Temporarily Unavailable
  • HTTP Error 503
  • HTTP Status 503 - Service Unavailable
  • "The server is temporarily unable to service your request due to maintenance downtime or capacity problems"
  • "503 Service Unavailable - DNS failure" (oudere IIS-melding, eigenlijk DNS-probleem)
  • Cloudflare-pagina met "Error 503" en Ray ID

Wat betekent een 503?

Op HTTP-niveau zegt een 503: "De service draait, maar is op dit moment niet bereikbaar — probeer 't later." De server is dus niet "kapot" — 'ie weigert bewust. Drie hoofdcategorieën:

  1. Resource-uitputting: te veel requests, niet genoeg CPU/memory/workers om ze allemaal af te handelen
  2. Bewuste protectie: hosting, WAF of Cloudflare beperkt je verkeer omdat het te veel of te verdacht is
  3. Onderhoud: minder vaak, maar soms zet beheer een 503-pagina neer tijdens gepland werk

Onderscheid met buurman-codes:

De zes meest voorkomende oorzaken

1. CloudLinux LVE / hosting resource-limit bereikt

Veel NL-hosters draaien CloudLinux dat per shared-account de resources begrenzt: CPU%, geheugen, "entry processes" (gelijktijdige PHP-requests). Bereik je een limiet, dan worden nieuwe requests geweigerd met 503 totdat je weer onder de limiet zit.

Symptomen:

  • 503's verschijnen op piek-momenten en verdwijnen even later
  • Hosting paneel toont "Resource Usage" met pieken die de limiet raken
  • Vaak op kleinere shared pakketten — 20 entry processes is niet veel

Diagnose: in cPanel onder "Resource Usage" zie je grafieken. Plesk heeft "Resource Usage" onder Statistics. Welke metric raakt de limiet? CPU, geheugen, of EP (entry processes)?

Fix:

  • Caching activeren: gecachte pagina kost ~5% van de resources van een dynamisch gegenereerde. Plugin als WP Rocket, W3 Total Cache of LiteSpeed Cache (bij LiteSpeed-hosters) maken een groot verschil
  • Database optimaliseren: trage queries verbruiken CPU. Zie trage WordPress site versnellen
  • Plugin-stack opschonen: 30 plugins = 30 kandidaten voor inefficiëntie
  • Hosting-plan upgraden: bij regelmatig raken van limieten is shared niet langer passend, naar VPS of een hoger pakket

2. PHP-FPM workers uitgeput

Net als bij 502 kan PHP-FPM-saturatie een 503 veroorzaken (afhankelijk van Nginx-config). Alle workers bezet, nieuwe request krijgt geweigerd → 503.

Symptoom: 503 vooral op piek-momenten, vaak gecombineerd met algemene traagheid op de site.

Fix: zelfde als bij 502 — workers verhogen, caching activeren, trage requests onderzoeken.

3. Bot- of crawler-aanval

Een bot bezoekt je site duizenden keren per minuut, vreet alle resources op, legitime bezoekers krijgen 503.

Diagnose: top-IP en User-Agent uit access_log:

awk '{print $1}' ~/logs/access_log | sort | uniq -c | sort -rn | head -10
awk -F'"' '{print $6}' ~/logs/access_log | sort | uniq -c | sort -rn | head -10

Eén IP met 10.000+ requests in een uur, of een verdachte User-Agent (vreemde naam, "bot" / "spider" zonder bekende crawler-naam, AhrefsBot/SemrushBot in agressieve mode) → daar zit je load.

Fix:

  • IP-blokkade in .htaccess of via fail2ban
  • Cloudflare WAF-rule of "I'm under attack"-mode (drempelt drastisch in tot manueel uitgezet)
  • Robots.txt-regels voor SEO-crawlers (helpen niet tegen kwaadwillende bots, wel voor legitime maar agressieve)

4. ModSecurity / WAF blokkeert te streng

Sommige hosters draaien ModSecurity met agressieve regelsets. Een legitime POST-request (formulier, file-upload, custom REST API-call) lijkt op een aanval-patroon → wordt geweigerd → 503.

Symptoom: 503 alleen op specifieke acties (formulier insturen, bepaalde URL bezoeken), error_log toont ModSecurity: Access denied.

Fix: hosting support contacten en vragen om die specifieke rule uit te schakelen voor jouw site of die URL. Niet zelf in code workarounds proberen — zit op server-niveau.

5. Cloudflare bot-fight / rate-limiting

Bij Cloudflare actief kan de "Bot Fight Mode" of een Rate Limiting Rule legit bezoekers afkappen. Vaak zien bezoekers dan een Cloudflare-503 met Ray ID.

Fix: in Cloudflare dashboard → Security → Bots → check welke modus aan staat. Bij false positives: Bot Fight Mode tijdelijk uitschakelen of de specifieke detected User-Agents whitelisten. Rate Limit-regels: in Security → WAF → Rate Limiting checken.

6. Gepland onderhoud (zeldzaam)

Soms zet een beheerder bewust een 503 neer tijdens onderhoud. Karakteristiek: een eigen onderhoudspagina met "we zijn zo terug"-tekst en HTTP-status 503. Dit is correct gedrag — Google Search Console accepteert 503's tijdens onderhoud zonder rankings te schaden.

Bij WordPress: niet hetzelfde als "Briefly unavailable for scheduled maintenance" — die geeft 503 tijdens een echte update, en is een vastzittend bestand-probleem.

Stap-voor-stap diagnose

  1. Hosting status-pagina checken: actief incident? Vrijwel elke NL-hoster heeft er één
  2. Resource-graphs bekijken: zie je pieken die je limit raken op het tijdstip van de 503?
  3. Open server error_log: zoek meldingen als limit reached, resource limit hit, ModSecurity, worker_connections
  4. access_log analyseren: piekt verkeer? Eén IP met enorm volume?
  5. Cloudflare check: Security events in dashboard tonen wie/wat gerate-limit wordt
  6. Komt 503 op specifieke acties? ModSecurity-regel waarschijnlijk
  7. Komt 503 in patronen? (Elke ochtend om 9u) — vaak een cron-job die resources opslokt

Specifieke scenario's

503 alleen tijdens marketing-piek of TV-uitzending

Capacity-issue. Site kan niet voldoen aan plotselinge vraag. Voor herhaling:

  • Caching-laag opzetten (Cloudflare, Varnish, page cache plugin)
  • Hosting tijdelijk upgraden voor de piek-periode
  • Statische versie van high-traffic pagina's serveren

503 op WP-cron of scheduled tasks

Dagelijkse cron-task vreet resources. wp-cron.php in WordPress draait standaard bij elke pageload als er werk is — op grote sites is dat ongunstig.

Fix: schakel WP_CRON uit en zet een echte server-cron op:

// In wp-config.php
define('DISABLE_WP_CRON', true);

# Server cron, draait elke 5 minuten
*/5 * * * * /usr/bin/php /home/site/public_html/wp-cron.php

503 na PHP-versie wisseling

PHP-versie heeft andere geheugen-/CPU-profile. Oude PHP gebruikt soms meer dan nieuwere — of andersom als bepaalde plugins op nieuwere PHP slecht presteren. Test op staging eerst, en monitor resource-graphs na switch. Zie PHP-versie veilig upgraden.

503 na hosting-migratie

Nieuwe hoster heeft strakkere limieten dan oude. Of WAF-config strenger. Eerste 1-2 weken na migratie: monitor resource-usage, vraag hosting wat de limieten zijn, optimaliseer waar nodig.

"503 Service Unavailable - DNS failure"

Specifieke IIS-melding (Microsoft Windows Server). Niet echt een 503-resource-issue maar een DNS-resolutie-probleem op de server zelf. Vraagt hosting-side debugging.

Preventie

  • Caching activeren: enkele factor die resources met 80-90% reduceert. Vrijwel iedere site die geen cache draait verbruikt onnodig veel
  • Resource-monitoring opzetten: weet wanneer je dichtbij limits zit voordat 't klant raakt. Hosting paneel-graphs of externe tools
  • Bot-mitigatie van begin af aan: Cloudflare met "Under attack" als noodknop, of fail2ban-rules voor agressieve crawlers
  • Hosting-pakket op huidige verkeer afgestemd: een budgetshared van €3/maand met 100 entry processes is niet geschikt voor een WooCommerce-shop met 1000 bezoekers per dag
  • WAF/Cloudflare-config periodiek reviewen: false positives sluipen erin, valide bezoekers worden onbedoeld geblokkeerd
  • WP_CRON op echte server-cron zetten bij sites met hoog verkeer
Tip: een 503 is meestal een symptoom van "te krap gehuurd" — of in resources, of in middelen. Caching aanzetten lost in 70% van de gevallen het probleem op zonder hosting-upgrade. Begin daar voor je een duurder pakket overweegt.

Wanneer schakel je hulp in?

  • 503 keert intermittent terug en je weet niet welke piek-bron de oorzaak is
  • Hosting wijst naar "te veel verkeer", maar bij analyse blijkt 't één bot-IP — kan met een WAF-rule afgevangen worden
  • WooCommerce-shop met live klanten, betaal-callback geeft 503 → orders gaan stuk
  • Cloudflare-config conflicteert met je hosting en je weet niet welk knopje het is
  • Caching aanzetten werkt niet meteen perfect (cache-issues met dynamische content, login-state, WooCommerce-cart)
  • WP-cron verbruikt te veel resources en je weet niet welke task het is
  • Hosting zegt "upgrade je pakket", jij wilt eerst weten of optimalisatie volstaat — onafhankelijke advies

Een 503 is in 70% van de gevallen op te lossen met caching plus een gerichte fix voor de specifieke piek-veroorzaker (bot, cron, query, WAF). De resterende 30% vraagt om upgrade of structurele aanpak. Met de stappen hierboven weet je in een halfuur welk van de twee voor jouw site geldt — en dat scheelt vaak zes maanden te kleine hosting kopen voordat duidelijk is dat 't niet gaat.