Voor uptime monitoring is het korte antwoord: 2xx-responses betekenen up, 5xx-responses betekenen down, en alles daartussen hangt af van wat je van die URL verwacht. Een 301 is prima als de pagina bewust is verhuisd, een 401 is prima op een API-endpoint dat een sleutel vereist, en een 404 op je afrekenpagina is een storing. Een goede monitor controleert op de statuscode die je verwacht, niet alleen op “alles behalve een fout”.
Dit spiekbriefje loopt de families van statuscodes door vanuit monitoringoogpunt: wat elke code betekent, of die als down moet tellen en hoe je checks zo instelt dat ze alleen bij echte problemen alarm slaan.
De vijf families in één oogopslag
BereikBetekenisVoor een monitor1xxInformatief, het verzoek loopt doorZelden gezien; geen definitief antwoord2xxSuccesMeestal up3xxRedirect, kijk ergens andersUp of down, afhankelijk van de bedoeling4xxClientfout, het verzoek was verkeerdHangt af van het endpoint5xxServerfout, de server faaldeDown
Het eerste cijfer vertelt je wie verantwoordelijk is. 4xx betekent dat de server vindt dat het verzoek verkeerd was. 5xx betekent dat de server toegeeft dat hij faalde. Voor een monitor die elke minuut hetzelfde verzoek stuurt, betekent een plotselinge 4xx meestal toch dat er aan de serverkant iets is veranderd: een pagina is verwijderd, een recht is aangepast of een firewall is begonnen met blokkeren.
1xx: informatief
Codes zoals 100 Continue, 101 Switching Protocols en 103 Early Hints zijn tussentijdse responses. Een client ziet ze vóór het definitieve antwoord, of helemaal niet. Een monitoringcheck wacht op de definitieve statuscode, dus deze familie kun je negeren. Eindigt een check ooit op een 1xx, dan is de verbinding halverwege de response verbroken, en dat is een fout.
2xx: succes
CodeNaamOpmerkingen voor monitoring200OKDe standaard succesresponse201CreatedVerwacht na een POST die iets aanmaakt202AcceptedVerzoek in de wachtrij; het werk gebeurt later204No ContentSucces met een lege body; gebruikelijk bij DELETE en sommige health checks
Een 200 is geen garantie dat de pagina werkt. Veel applicaties vangen hun eigen fouten af en tonen een foutpagina met status 200: “Database connection failed”, een lege template, een onderhoudsmelding. Voeg contentvalidatie toe aan belangrijke checks: verwacht een woord of een JSON-veld dat alleen verschijnt als de pagina echt werkt. Bij 204 is er geen body om te valideren, dus controleer dan alleen de statuscode.
3xx: redirects
CodeNaamTypisch gebruik301Moved PermanentlyOude URL naar nieuwe URL, HTTP naar HTTPS302FoundTijdelijke redirect, vaak naar een inlogpagina303See OtherRedirect na een formulier-POST304Not ModifiedGecachte kopie is nog geldig; alleen na conditionele verzoeken307Temporary RedirectZoals 302, maar behoudt de methode en de body308Permanent RedirectZoals 301, maar behoudt de methode en de body
Redirects en monitors
Monitoringtools gaan op een van twee manieren met redirects om: ze volgen ze en rapporteren de status van de uiteindelijke pagina, of ze stoppen bij de eerste response en rapporteren de 3xx. Weet per check wat je tool doet, want beide kunnen problemen verbergen:
Als de monitor redirects volgt, kan een pagina die opeens doorverwijst naar de homepage of een inlogscherm toch op een 200 eindigen. Contentvalidatie vangt dit op: de homepage bevat niet de woorden van je afrekenpagina.
Als de monitor redirects niet volgt, stel je de verwachte status in op de redirectcode en controleer je de uiteindelijke URL met een eigen monitor.
Het veiligste patroon is de uiteindelijke URL direct monitoren. Verwijst northwind.shop door naar www.northwind.shop, monitor dan de www-versie, en voeg alleen een aparte check voor de redirect toe als die voor jou belangrijk is, bijvoorbeeld voor oude campagnelinks. Een redirect-loop, waarbij twee URL’s naar elkaar verwijzen, verschijnt als een time-out of een “too many redirects”-fout en moet altijd als down tellen.
4xx: clientfouten
CodeNaamDown?400Bad RequestMeestal een kapotte check of een gewijzigde API401UnauthorizedVerwacht op beveiligde endpoints zonder inloggegevens403ForbiddenVerwacht voor geblokkeerde paden; een probleem als hij plotseling verschijnt404Not FoundDown voor elke URL die zou moeten bestaan405Method Not AllowedDe check gebruikt de verkeerde methode, of de route is veranderd408Request TimeoutDe server gaf het wachten op het verzoek op410GoneBewust verwijderd429Too Many RequestsRate limit bereikt
401 en 403 op beveiligde endpoints
Sommige endpoints horen anonieme verzoeken te weigeren. Een admin-API die zonder token een 401 teruggeeft, werkt correct. Je kunt hem op twee manieren monitoren:
Verwacht de weigering. Stel de verwachte status in op 401. De check bevestigt dat de server up is en dat de authenticatielaag er staat. Geeft hij ooit een 200 zonder inloggegevens, dan is dat een beveiligingsprobleem dat een alarm waard is.
Stuur inloggegevens mee. Voeg een API-key-header of basic auth toe aan de check en verwacht een 200 plus de juiste content. Zo test je het volledige pad, inclusief de database achter het endpoint.
De tweede optie test meer, dus gebruik die voor alles waar klanten op vertrouwen. Gebruik voor monitoring een aparte read-only key, nooit een persoonlijke of admin-key.
Een plotselinge 403 op een openbare pagina is een ander verhaal. Meestal betekent het dat een firewall, een beveiligingsplugin of een CDN-regel verzoeken is gaan blokkeren, soms alleen uit bepaalde landen of IP-reeksen. Krijgt de ene monitoringlocatie een 403 en de andere een 200, dan is een geo- of IP-regel de waarschijnlijke oorzaak.
429 Too Many Requests
Een 429 betekent dat de server de client afremt met een rate limit. Voor monitoring betekent dat een van twee dingen: je limieten zijn te streng voor normaal verkeer, of de monitor zelf loopt tegen een limiet aan omdat hij een adres deelt met andere clients. Controleer de Retry-After-header en je rate-limitconfiguratie. Krijgen echte gebruikers bij normale belasting 429’s, behandel het dan als een storing.
5xx: serverfouten
CodeNaamWat het meestal betekent500Internal Server ErrorDe applicatie crashte bij dit verzoek501Not ImplementedDe server ondersteunt de methode niet502Bad GatewayDe proxy kreeg een ongeldige response van de app erachter503Service UnavailableOverbelast, in onderhoud of geen gezonde backend504Gateway TimeoutDe proxy wachtte te lang op de app
Behandel elke 5xx als down. De codes verschillen in waar je eerst moet kijken: een 500 wijst naar de applicatielogs, een 502 naar een gecrasht of herstartend applicatieproces, een 504 naar trage queries of externe calls, en een 503 naar capaciteit of onderhoud. Onze gids over de 503 Service Unavailable-fout behandelt de oorzaken en oplossingen uitgebreid.
Sommige CDN’s en proxy’s gebruiken hun eigen codes in het 5xx-bereik, zoals 520 tot 530, voor problemen tussen het CDN en je originserver. Ze maken geen deel uit van de HTTP-standaard, maar voor een bezoeker betekenen ze hetzelfde: de site ligt plat.
Niet elke fout heeft een statuscode
Sommige van de meest voorkomende storingen leveren helemaal geen statuscode op:
DNS-fout: het domein resolvet niet, bijvoorbeeld na een verlopen registratie of een verwijderd record.
Verbinding geweigerd of gereset: er luistert niets op de poort, of een firewall verbreekt de verbinding.
TLS-fouten: een verlopen of niet-overeenkomend certificaat stopt het verzoek voordat er ook maar iets van HTTP gebeurt.
Time-outs: de server accepteert de verbinding, maar antwoordt nooit op tijd.
Een goede monitor rapporteert deze als fouten met de werkelijke foutmelding, zodat het alarm “certificate expired” zegt in plaats van alleen “down”. Daarom is het ook de moeite waard om naast je HTTP-monitors checks op het verlopen van certificaten en domeinen toe te voegen.
De verwachte status instellen in een monitor
Bepaal voor elke URL die je monitort hoe een gezonde response eruitziet en leg dat vast als de configuratie van de check:
Kies de URL die ertoe doet. De uiteindelijke URL na redirects, niet de korte link.
Stel de methode in. GET voor pagina’s, en wat het endpoint vereist voor API’s.
Stel de verwachte status in. Meestal 200. Gebruik 201, 204, 301 of 401 als dat het bedoelde antwoord is.
Voeg zo nodig inloggegevens toe. Headers of basic auth voor beveiligde endpoints.
Voeg contentvalidatie toe. Een woord op de pagina of een veld in de JSON-response dat alleen verschijnt als alles werkt.
Stel een time-out in. Een response die 30 seconden duurt, is voor een bezoeker een fout, ook als hij op een 200 eindigt.
Zo ziet dat eruit voor een health-endpoint op lumenanalytics.io, eerst met de hand getest met curl:
curl -sS -o /dev/null -w “%{http_code} %{time_total}s\n” \
-H “Authorization: Bearer $MONITOR_TOKEN” \
https://api.lumenanalytics.io/v1/health
Print dat 200 en een redelijke tijd, dan gaan dezelfde methode, header en verwachte status de monitor in. In Uptimecheck accepteren uptime monitors en API-monitors een eigen methode, headers (bijvoorbeeld basic auth of een bearer-token), body, keyword- en JSON-checks, en laten ze de check falen als de statuscode of de response niet is wat je verwacht. Meer over het ontwerpen van het endpoint zelf lees je in een health-check-endpoint bouwen, en in de checklist voor API-monitoring zie je welke endpoints je moet afdekken.
Snel overzicht: is het down?
Down: elke 5xx, een 404 op een URL die zou moeten bestaan, time-outs, DNS- en TLS-fouten, geweigerde verbindingen.
Waarschijnlijk down: een plotselinge 403 of 429 op een openbare pagina, een 400 of 405 op een check die eerder slaagde.
Up: de statuscode die je als verwacht hebt ingesteld, met de content waarop je valideert, binnen een redelijke tijd.
Samenvatting
Statuscodes zijn het eerste waar een monitor naar kijkt en de snelste manier om te zien waar een probleem zit. 5xx betekent dat de server faalde, 4xx dat er iets is veranderd in wat de server accepteert, en bij 3xx moet je beslissen waar de check moet eindigen. Configureer elke monitor met de status die hij hoort te krijgen, valideer de content van belangrijke pagina’s en laat de code meekomen in het alarm, zodat wie het oppakt weet waar te beginnen.
Uptimecheck controleert je websites en API’s tot elke minuut en waarschuwt je als de statuscode of de response niet is wat je verwacht. Probeer het 14 dagen gratis, geen creditcard nodig.