Een 503 Service Unavailable-fout betekent dat de webserver het verzoek ontving maar het op dit moment niet kan afhandelen. De server is bereikbaar, dus DNS en het netwerk werken, maar de applicatie erachter is overbelast, in onderhoud of kan een dienst waarvan ze afhankelijk is niet bereiken. Een 503 is bedoeld als tijdelijk. Duurt hij langer dan een paar minuten, dan moet er iets worden opgelost: meestal te veel verkeer, te weinig workers, een gestopt applicatieproces of een backend die plat ligt.
Deze gids legt uit wat een 503 veroorzaakt, hoe je de oorzaak op je eigen server vindt, hoe je elke oorzaak oplost en hoe je ervoor zorgt dat je de volgende eerder ziet dan je klanten.
Wat een 503 je echt vertelt
HTTP-statuscodes in de 5xx-reeks betekenen dat de server faalde, niet de bezoeker. Binnen die familie heeft 503 een specifieke betekenis: de dienst is voorlopig niet beschikbaar en de client mag het later opnieuw proberen. Vergelijk hem met zijn buren:
500 Internal Server Error: de applicatie crashte tijdens het afhandelen van het verzoek.
502 Bad Gateway: een proxy of load balancer kreeg een ongeldig antwoord van de server erachter.
503 Service Unavailable: de server, of iets ervoor, weigert het verzoek te verwerken omdat hij overbelast of in onderhoud is, of niets gezonds heeft om het naartoe te sturen.
504 Gateway Timeout: een proxy wachtte op de server erachter en gaf het op.
Het onderscheid is belangrijk, want het wijst je waar je moet zoeken. Een 503 is zelden een bug op één pagina. Het gaat bijna altijd om de capaciteit of beschikbaarheid van een hele dienst. Een volledig overzicht van de codes, en welke een monitor als down moet behandelen, vind je in ons overzicht van HTTP-statuscodes voor monitoring.
Veelvoorkomende oorzaken van een 503
Verkeerspieken en overbelasting
Elke server kan een beperkt aantal verzoeken tegelijk aan. Een campagnemail, een vermelding op social media of een bot die duizenden pagina’s crawlt, kan hem over die grens duwen. Als de wachtrij vol is, begint de webserver of de applicatie nieuwe verzoeken met een 503 te weigeren. Vaak werkt de site een paar minuten later weer, om bij de volgende piek opnieuw te falen.
Gepland onderhoud
Veel systemen geven tijdens onderhoud bewust een 503. WordPress doet dat terwijl het updates installeert: het schrijft een .maintenance-bestand en toont een korte pagina “Briefly unavailable for scheduled maintenance” met status 503. Wordt een update onderbroken, dan kan dat bestand achterblijven en blijft de site 503 geven tot iemand het verwijdert.
Gestopt applicatieproces of app pool
Op Windows-servers met IIS levert een gestopte of gecrashte application pool de klassieke melding “HTTP Error 503. The service is unavailable.” op. De pool kan stoppen door herhaalde crashes, een verkeerd wachtwoord voor de identiteit of een configuratiewijziging. Op Linux is het equivalent een Node-, Python- of Java-proces dat is beëindigd, waardoor de reverse proxy niets heeft om naar door te sturen.
PHP-FPM heeft geen workers meer
PHP-sites achter nginx of Apache draaien meestal PHP-FPM met een vast aantal workerprocessen, ingesteld met pm.max_children. Is elke worker bezet, bijvoorbeeld omdat elk verzoek wacht op een trage databasequery of een externe API, dan komen nieuwe verzoeken in de wachtrij. Afhankelijk van de opzet krijgt de bezoeker een 503, een 502 of een 504. De PHP-FPM-log vertelt je of dit gebeurt:
WARNING: [pool www] server reached pm.max_children setting (10), consider raising it
Rate limiting
Rate limits beschermen een server tegen misbruik, maar staan ze te strak, dan krijgen ook echte gebruikers fouten. nginx geeft standaard een 503 wanneer een verzoek een limit_req-zone overschrijdt. Web application firewalls en sommige hostingplatforms doen hetzelfde. Deelt één kantoor, één API-client of één monitoringdienst een IP-adres met veel gebruikers, dan kunnen ze samen de limiet raken.
Upstream of backend plat
Load balancers en reverse proxies geven een 503 als ze geen gezonde server hebben om verkeer naartoe te sturen. Markeren de health checks elke backend als ongezond, na een mislukte deploy of omdat de database plat ligt en het health endpoint dat meldt, dan antwoordt de proxy op elk verzoek met een 503.
Problemen met CDN en origin
Staat je site achter een CDN, dan kan de 503 van het CDN komen in plaats van van je server. Het CDN kan hem teruggeven als je origin overbelast of onbereikbaar is, of als het CDN zelf in één regio problemen heeft. De response headers vertellen meestal wie er antwoordde: zoek naar de eigen server-header of request-ID van het CDN, en vergelijk met een verzoek dat rechtstreeks naar de origin gaat.
Zo vind je de oorzaak
Begin bij het antwoord zelf. Vraag de falende URL op en bekijk de headers:
curl -sS -o /dev/null -D – https://northwind.shop/checkout
De Server-header en eventuele CDN-specifieke headers laten zien welke laag antwoordde. Een Retry-After-header wijst op bewust onderhoud. Werk daarna van buiten naar binnen:
Controleer of het overal speelt. Faalt de homepage ook, of alleen één pad? Eén pad wijst naar één route of worker-pool van de applicatie; als alles faalt, wijst dat naar de server of de proxy.
Lees de foutlog van de webserver. nginx en Apache loggen upstream-fouten, door rate limits geweigerde verzoeken en verbindingsfouten met tijdstempels.
Lees de log van de applicatie of PHP-FPM. Zoek naar max_children-waarschuwingen, crashes, processen die wegens geheugengebrek zijn gestopt en traces van trage verzoeken.
Controleer de serverbronnen. CPU, load, geheugen en swap op het moment van de fout. Een server die swapt, antwoordt traag, en trage antwoorden vullen worker-pools.
Controleer afhankelijkheden. Antwoordt de database? Draait de cache? Reageert een externe API die je synchroon aanroept traag?
Controleer recente wijzigingen. Een deploy, een plugin-update, een configuratiewijziging of een nieuwe rate limit rond het moment dat de fouten begonnen, is de meest waarschijnlijke oorzaak.
Zo los je een 503 op
De oplossing volgt uit de oorzaak. Hier zijn de gebruikelijke, in de volgorde waarin de meeste teams ze tegenkomen.
Vastgelopen onderhoudsmodus: verwijder het .maintenance-bestand in de hoofdmap van WordPress, of zet de onderhoudsvlag van je framework uit, en rond de update daarna af of probeer hem opnieuw.
Overbelasting door echt verkeer: cache wat je kunt aan de edge en in de applicatie, zodat de meeste verzoeken PHP of de database nooit bereiken. Voeg daarna capaciteit toe: meer workers als het geheugen het toelaat, een grotere server of meer servers achter de load balancer.
Overbelasting door bots: zoek de user agents en IP-ranges op in je access log en beperk of blokkeer ze bij het CDN of de firewall, voordat ze de applicatie bereiken.
PHP-FPM-workers: verhoog pm.max_children alleen zo ver als het geheugen toelaat. Bereken het gemiddelde geheugengebruik van één worker en deel het geheugen dat je kunt missen daardoor. Zijn workers bezet door trage queries, los dan eerst de queries op, anders verplaats je alleen het knelpunt.
Gestopte app pool of gestopt proces: start het opnieuw en zoek daarna uit waarom het stopte. Kijk in de event log of het systeemjournaal naar crashes, en zet een procesmanager op die de service automatisch herstart.
Te strenge rate limits: verhoog de limiet of de burst, zonder bekende IP-adressen uit, zoals die van je kantoor of je monitoringdienst, en geef 429 in plaats van 503 terug aan clients die tegen de rate limit aanlopen, zodat de oorzaak meteen duidelijk is in de logs.
Ongezonde backends: controleer wat de health check van de load balancer opvraagt en waarom die faalt. Draai een mislukte deploy eerst terug en onderzoek het daarna.
Hier zie je een typische wijziging in een PHP-FPM-pool voor een server met ruimte voor meer workers. De getallen zijn een voorbeeld, geen aanbeveling voor jouw server:
; /etc/php/8.2/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 24
pm.start_servers = 6
pm.min_spare_servers = 4
pm.max_spare_servers = 10
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/www-slow.log
De slow log is het nuttige deel: die laat zien welke scripts workers het langst bezet houden, en daar kijk je vervolgens naar.
Gebruik Retry-After bij gepland onderhoud
Haal je een site bewust offline, geef dan een 503 terug met een Retry-After-header. Die vertelt browsers, API-clients en crawlers van zoekmachines dat de storing tijdelijk is en wanneer ze terug kunnen komen. De waarde is een aantal seconden of een HTTP-datum:
HTTP/1.1 503 Service Unavailable
Retry-After: 1800
Content-Type: text/html; charset=utf-8
In nginx kan een eenvoudige onderhoudsschakelaar er zo uitzien:
if (-f /var/www/maintenance.flag) {
return 503;
}
error_page 503 @maintenance;
location @maintenance {
add_header Retry-After 1800 always;
root /var/www/maintenance;
rewrite ^ /index.html break;
}
Twee regels maken gepland onderhoud pijnloos. Geef een 503 terug, nooit een 200 met een “zo terug”-pagina, want een 200 vertelt crawlers en monitors dat de onderhoudspagina je echte content is. En houd het kort: een 503 van een uur is prima, een 503 van dagen loopt het risico dat pagina’s uit de zoekresultaten verdwijnen.
Laat het klanten ook vooraf weten. Een melding op je statuspagina beantwoordt “ligt het aan mij?” voordat iemand het vraagt.
Hoe monitoring 503-fouten opvangt
Een 503 komt en gaat vaak. De site faalt twee minuten op het hoogtepunt van een campagne, herstelt zich en faalt een uur later opnieuw. Niemand in het team ziet het, want tegen de tijd dat iemand de site opent, werkt ze. Klanten zagen het wel.
Een HTTP-monitor vraagt je pagina’s volgens een schema op en legt bij elke check de statuscode en de responstijd vast. Een 503 is een mislukte check. Goede monitoring doet dan drie dingen:
De fout bevestigen. Een tweede check sluit een eenmalige blip uit, en een check vanaf een andere locatie sluit ook een probleem op één netwerkpad uit. Uptimecheck controleert vanuit Stockholm, Londen en New York, en bevestigt elke fout vanaf een tweede locatie voordat er een incident opent.
De juiste mensen alarmeren. De alert bevat de statuscode, de URL en het moment waarop het begon, zodat wie hem oppakt weet dat het om een 503 gaat en niet om een DNS-fout. In Uptimecheck bevat het incident ook het foutieve antwoord en een screenshot, zodat je de foutpagina ziet die je bezoekers zagen, of een traceroute als de server helemaal niet antwoordde. Zie alerts en notificaties voor de kanalen.
Het patroon vastleggen. De incidentgeschiedenis laat zien of 503-fouten zich ophopen rond verkeerspieken, deploys of nachtelijke jobs, en dat vertelt je welke oplossing je het eerst moet proberen.
Monitor meer dan de homepage. Die is vaak gecachet en blijft werken terwijl checkout, inloggen of de API falen. Voeg uptime monitors toe voor de pagina’s die geld opleveren, en houd de trend van de responstijd in de gaten: een pagina die elke dag op hetzelfde uur trager wordt, is vaak een 503 die op het punt staat te gebeuren. Onze gids over wat een goede responstijd voor een website is legt uit waar je op moet letten.
Servermetrics maken het plaatje compleet. Komt er een 503-alert binnen, dan is de eerste vraag of de server door zijn CPU, geheugen of schijfruimte heen was. Met servermonitoring naast je uptime checks zie je oorzaak en symptoom naast elkaar.
Checklist voor een 503
Bekijk de response headers om te zien welke laag de 503 teruggaf.
Controleer de logs van de webserver, de applicatie en PHP-FPM voor dezelfde tijdstempel.
Controleer CPU, geheugen, swap en schijf op de server.
Zoek naar deploys, updates en configuratiewijzigingen vlak voordat de fouten begonnen.
Los de oorzaak op: caching, meer workers, een herstart proces, een ruimere rate limit of een gezonde backend.
Gebruik 503 met Retry-After voor gepland onderhoud, nooit 200.
Monitor belangrijke pagina’s elke minuut en bevestig elke fout met een tweede check voordat je alarmeert.
Samenvatting
Een 503 betekent dat de server er wel is, maar je op dit moment niet kan bedienen. Het is een probleem van capaciteit of beschikbaarheid, geen kapotte pagina, en de logs van hetzelfde tijdstip wijzen meestal direct naar de oorzaak. Los de oorzaak op in plaats van het symptoom, gebruik Retry-After als de downtime gepland is, en laat monitoring je vertellen over korte 503-fouten die je anders nooit zou zien.
Uptimecheck monitort websites, API’s en servers in één account en waarschuwt je wanneer een pagina 503 begint terug te geven. Start je gratis proefperiode van 14 dagen, geen creditcard nodig.