Woordenlijst · Soorten monitoring
Een health check endpoint is een URL, zoals /health of /healthz, die een dienst beschikbaar stelt zodat load balancers, orchestrators en monitoring kunnen vragen of hij werkt. Hij antwoordt met 200 als de dienst gezond is en met een foutstatus, meestal 503, als dat niet zo is.
Een goede health check test wat de dienst nodig heeft om gebruikers te bedienen: een snelle query op de database, de cache, de queue. Hij antwoordt snel, heeft geen bijwerkingen, vraagt geen login of alleen een sleutel zonder andere rechten, en geeft een kleine JSON-body terug die zegt welke controle mislukte.
Er zijn meestal twee soorten. Een liveness check zegt dat het proces draait en niet herstart hoeft te worden; die blijft eenvoudig. Een readiness check zegt dat de instantie nu verkeer aankan, afhankelijkheden inbegrepen, zodat een load balancer of Kubernetes eromheen kan routeren. Externe monitoring wil de readiness-variant.
Wees voorzichtig met afhankelijkheden die je niet zelf beheert. Als de health check faalt zodra een externe API traag is, kan elke instantie tegelijk uit de roulatie gaan. Meld die als degraded in de body, en bewaar de statuscode voor storingen die de dienst echt stilleggen.
GET /health
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{"status":"ok","checks":{"database":"ok","cache":"ok"}}
Een monitor controleert de statuscode en of $.status gelijk is aan ok. Een 503, een time-out of elke andere waarde laat de controle mislukken.
API-monitors van Uptimecheck kunnen elke minuut een health-endpoint controleren: de statuscode (standaard 200 tot 399, of de codes die je instelt), tot 10 JSON- en headervoorwaarden zoals $.status is gelijk aan ok, een trefwoord en tot 20 requestheaders voor een sleutel. De standaardtimeout is 10 seconden, en antwoorden die trager zijn dan je limiet sturen een alert voor traagheid.
14 dagen gratis proberen · Daarna gratis met 5 monitors · Geen creditcard
Guides 7 min. leestijd
Een healthcheck-endpoint vertelt monitors en load balancers of je app verzoeken kan verwerken. Wat je controleert, hoe je het snel en veilig houdt, code voor Laravel, Express en Flask, en hoe je het monitort.
LezenGuides 5 min. leestijd
Een API kan 200 teruggeven en toch kapot zijn. Een praktische checklist voor API monitoring: methodes, headers, request bodies, authenticatie, verwachte responses en drempels voor de responstijd.
LezenAgencies 7 min. leestijd
Wie alleen de homepage monitort, mist de meeste storingen. Een checklist van de URL’s en checks die ertoe doen, van login en checkout tot webhooks, cronjobs, SSL, DNS en servers, met voorbeeldopzetten.
Lezen200 met een kleine JSON-body als de dienst en zijn kritieke afhankelijkheden werken, en 503 als dat niet zo is. Voeg Cache-Control: no-store toe, zodat een cache er nooit voor antwoordt.
Dat kan, als het niets gevoeligs prijsgeeft: geen versies, hostnamen of foutmeldingen. Bescherm het anders met een token in een header, en geef de monitor een eigen sleutel.
Liveness zegt dat het proces draait; faalt die, dan wordt het proces herstart. Readiness zegt dat de instantie nu verkeer kan verwerken; faalt die, dan gaat de instantie uit de rotatie tot ze herstelt.
Stel je eerste monitor in binnen een minuut, of kijk eerst rond in de live demo.
14 dagen gratis proberen · Daarna gratis met 5 monitors · Geen creditcard
Met jouw toestemming laten Google Analytics en Microsoft Clarity ons zien welke pagina’s helpen en waar bezoekers vastlopen. Ze plaatsen cookies voor maximaal 13 maanden. Zonder jouw toestemming draait geen van beide. Je kunt je keuze altijd wijzigen via Cookie-instellingen onderaan de pagina. Privacybeleid