Een 500 Internal Server Error betekent dat de applicatie op de server tegen een probleem aanliep dat ze niet kon afhandelen tijdens het opbouwen van het antwoord. Anders dan de meeste andere fouten zegt deze niet wat er misging. Het is de manier van de server om te zeggen: “er is iets kapot, en ik vertel de bezoeker niet wat”.
De echte foutmelding bestaat wel. Die staat in een log. Deze gids laat zien waar je die vindt, wat de oorzaken achter de meeste 500-fouten zijn en hoe je ervoor zorgt dat jij als eerste weet wanneer er een opduikt.
Wat een 500 je vertelt
Een 500 komt van de applicatie zelf, of van de webserver die haar draait. Het betekent dat het verzoek je code bereikte en dat de code faalde: een exception die niemand afving, een fatale fout, een configuratie die de server niet kon lezen. Daarin verschilt het van de gateway-fouten, waarbij het probleem tussen twee servers zit:
500 Internal Server Error: de applicatie faalde tijdens het afhandelen van het verzoek.
502 Bad Gateway: een proxy kreeg een ongeldig antwoord van de applicatie. Zie onze gids over 502.
503 Service Unavailable: de dienst is overbelast of in onderhoud. Zie onze gids over 503.
504 Gateway Timeout: de applicatie was te traag met antwoorden. Zie onze gids over 504.
Een 500 op één pagina betekent meestal een bug in de code van die pagina. Een 500 op elke pagina betekent meestal dat er iets gedeelds kapot is: de configuratie, de databaseverbinding, een bestand dat de hele applicatie laadt.
Begin bij wat er veranderd is
De meeste 500-fouten duiken op vlak na een wijziging. Vraag je, voordat je ook maar één log leest, af wat er het afgelopen uur is gebeurd:
Een deploy of een merge naar de main branch
Een update van een plugin, thema, framework of programmeertaal
Een wijziging in een configuratiebestand, .htaccess of omgevingsvariabelen
Een vervangen wachtwoord of API-sleutel
Een server waarvan de schijf volliep of de rechten zijn gewijzigd
Klopt de timing, dan is de wijziging terugdraaien vaak de snelste manier om de site weer online te krijgen. Zoek de oorzaak daarna, zonder dat klanten meekijken.
Vind de echte foutmelding
De 500-pagina is algemeen, de log is specifiek. Waar je moet kijken, hangt af van je stack:
# nginx and Apache
tail -n 50 /var/log/nginx/error.log
tail -n 50 /var/log/apache2/error.log
# PHP-FPM
tail -n 50 /var/log/php8.3-fpm.log
# Applications run by systemd
journalctl -u myapp –since “15 min ago”
# Docker
docker logs –since 15m myapp
Zoek de tijdstempel van het mislukte verzoek. De regel ernaast noemt meestal het bestand, de regel en de reden: een niet-gedefinieerde functie, een ontbrekende class, een database die het wachtwoord weigerde.
Zet in WordPress de debuglog aan in wp-config.php. Die schrijft fouten naar wp-content/debug.log zonder ze aan bezoekers te tonen:
define( ‘WP_DEBUG’, true );
define( ‘WP_DEBUG_LOG’, true );
define( ‘WP_DEBUG_DISPLAY’, false );
Zet hem weer uit als je klaar bent, want de log kan flink groeien en gevoelige gegevens bevatten.
Veelvoorkomende oorzaken en hoe je ze oplost
Een fout in de code
Een niet-afgevangen exception of een fatale fout in de code die de pagina opbouwt. De log toont het bestand en de regel. Typische boosdoeners zijn een functie die data krijgt die ze niet verwachtte, een waarde die onverwacht leeg is, en code die op de machine van de developer werkt maar een PHP-extensie of bibliotheekversie nodig heeft die de server niet heeft. Repareer de code, of ga terug naar de laatste versie die werkte.
Een update van een plugin of thema
Bij WordPress en andere CMS’en is een update van een plugin of thema de meest voorkomende oorzaak. De log noemt de map van de plugin. Kun je niet bij de beheeromgeving, hernoem die map dan via SSH of SFTP om de plugin uit te schakelen:
mv wp-content/plugins/some-plugin wp-content/plugins/some-plugin.disabled
De site komt terug zonder de plugin. Update hem daarna opnieuw, vervang hem of neem contact op met de ontwikkelaar, met de fout uit de log erbij.
Een kapot .htaccess-bestand
Bij Apache haalt één verkeerde regel in .htaccess de hele site onderuit met een 500. De foutlog zegt Invalid command of noemt de directive die hij niet begreep. Hernoem het bestand om te testen en zet de regels daarna één voor één terug. In WordPress schrijft het opslaan van de permalinkinstellingen een nieuw bestand.
PHP heeft te weinig geheugen
Allowed memory size of 134217728 bytes exhausted betekent dat een verzoek meer geheugen nodig had dan memory_limit toestaat. De limiet verhogen kan helpen, maar een verzoek dat honderden megabytes nodig heeft, laadt meestal te veel data tegelijk. Zoek uit wat het laadt voordat je het meer geeft.
Bestandsrechten en eigenaarschap
Na een deploy, een restore of een handmatige kopie kunnen bestanden bij de verkeerde gebruiker terechtkomen. De webserver kan de code dan niet lezen of niet schrijven naar zijn cache- en uploadmappen, en de log zegt Permission denied. Zet het eigenaarschap terug naar de gebruiker waaronder de webserver of PHP draait. Mappen hebben normaal 755 nodig en bestanden 644; los het nooit op met 777.
Een volle schijf
Als de schijf vol is, kunnen applicaties geen sessies, caches, uploads of logs meer wegschrijven, en falen ze op manieren die eindigen in een 500. Controleer de ruimte en de inodes:
df -h
df -i
Oude logs, back-ups en caches zijn de gebruikelijke boosdoeners. Servermonitoring met een schijfalert bij 80 of 90 procent vangt dit dagen voordat de site eronder bezwijkt.
Fouten in de databaseverbinding
Een gewijzigd wachtwoord, een databaseserver die plat ligt of een verbindingslimiet die bereikt is. De applicatie kan niets laden en faalt op elke pagina. De log noemt de databasefout. Controleer of de database draait, of de inloggegevens in de configuratie actueel zijn en hoeveel verbindingen er openstaan ten opzichte van de limiet.
De 500 die 200 teruggeeft
Niet elke kapotte pagina laat dat merken. Sommige applicaties vangen de fout af en tonen een vriendelijke “Er ging iets mis”-pagina met status 200, en een CMS kan zonder morren een lege productlijst tonen. Voor een monitor die alleen naar de statuscode kijkt, ziet alles er prima uit.
Controleer dus ook de inhoud. Een uptime monitor kan eisen dat een pagina een woord bevat dat er altijd staat als ze werkt, zoals de productnaam of “In winkelwagen”, en het ontbreken ervan als fout behandelen. Onze checklist van wat je moet monitoren laat zien welke pagina’s zo’n controle verdienen.
Hoe monitoring 500-fouten opvangt
Een 500 na een deploy kan urenlang onopgemerkt blijven als hij maar één pagina raakt. De checkout ligt eruit, de homepage werkt nog, en het team hoort het pas via een klantmail of een dip in de omzet.
Controleer de pagina’s die geld opleveren. Voeg uptime monitors toe voor checkout, inloggen, aanmelden en de API, niet alleen voor de homepage, met inhoudscontroles waar een 200 een fout kan verbergen.
Bevestig voordat je alarmeert. Uptimecheck controleert zo vaak als elke minuut vanuit Stockholm, Londen en New York, en bevestigt elke fout vanaf een tweede locatie, zodat één mislukt verzoek niemand uit bed belt.
Zie wat er kapot ging. Het incident bevat het foutieve antwoord, inclusief de statuscode en de foutpagina, en een screenshot van wat een bezoeker zag.
Test complete flows. Een login of checkout die bij stap drie faalt, geeft bij stap één gewoon 200. Flows met meerdere stappen lopen alle stappen door en vertellen je welke faalde.
Checklist voor een 500
Vraag je af wat er het afgelopen uur veranderd is, en draai het terug als de timing klopt.
Zoek de tijdstempel van het mislukte verzoek op in de foutlog.
Lees de fout: bestand, regel en reden.
Sluit de gebruikelijke oorzaken uit: een plugin, .htaccess, geheugen, rechten, schijf, database.
Los de oorzaak op en verwijder daarna de debuginstellingen die je hebt aangezet.
Monitor belangrijke pagina’s elke minuut, met inhoudscontroles waar een 200 een fout kan verbergen.
Test logins en checkouts als flows, niet als losse pagina’s.