Een healthcheck-pad stelt het platform in staat om periodiek te controleren of uw applicatie draait en correct functioneert.
Standaard voert het platform, als er geen healthcheck is ingeschakeld, alleen een basiscontrole uit na de deployment: het controleert of de container van de applicatie succesvol is gestart. In dit geval wordt de werkelijke gezondheid van de applicatie niet geëvalueerd – de app kan onjuist reageren of helemaal niet reageren, en toch wordt de deployment als succesvol gemarkeerd.
Om dit te voorkomen, kunt u een healthcheck-pad configureren. Uw applicatie moet een endpoint aanbieden dat niet afhankelijk is van externe systemen (zoals een database of externe diensten) en dat de interne status van de applicatie nauwkeurig weergeeft.
U kunt dit endpoint tijdens de configuratie opgeven: bijvoorbeeld /health, /status of /ping.
Standaard controleert het systeem tijdens de deployment alleen de root-URL (/). Het stuurt een verzoek naar de hoofdpagina en als de responsstatus niet binnen het 2xx-bereik valt, wordt de deployment als mislukt beschouwd.
Healthcheck-verzoeken worden altijd vanaf localhost uitgevoerd.
De enige vereiste is dat het endpoint een 2xx-statuscode retourneert. De inhoud van de respons maakt niet uit; alleen de statuscode is relevant.
Als een healthcheck-pad is geconfigureerd, stuurt het systeem maximaal drie opeenvolgende GET-verzoeken naar de nieuwe applicatie-instantie.
Als ten minste één verzoek een 2xx-statuscode retourneert, wordt de deployment als succesvol beschouwd en wordt de nieuwe versie actief.
Als alle drie de pogingen mislukken (elke statuscode anders dan 2xx), wordt de deployment als mislukt gemarkeerd en blijft de vorige versie actief.
Healthchecks gaan door totdat aan een van de volgende voorwaarden is voldaan:
één succesvolle respons,
drie opeenvolgende mislukte responsen, waarbij de laatste 40 seconden na het opstarten plaatsvindt,
of er verstrijken 180 seconden; als geen van bovenstaande binnen deze tijd optreedt, wordt de deployment als mislukt beschouwd.
Als de controle mislukt, verschijnt er een healthcheck-foutmelding in de deployment-logs.
Zodra een deployment succesvol is, blijft het systeem de gezondheid van de applicatie controleren met één verzoek elke 30 seconden.
Als drie opeenvolgende controles mislukken, wordt de applicatie automatisch opnieuw gestart. Deze gebeurtenis verschijnt in de applicatielogs.

U kunt een healthcheck-pad configureren bij het aanmaken van een nieuwe applicatie of later voor een bestaande applicatie.
Voer in de sectie App settings het gewenste pad in het veld Health Check path in.
Als uw applicatie bijvoorbeeld een /health-endpoint aanbiedt dat toegankelijk is via https://domain/health, stel dan in:
/health

Open de applicatie in het controlepaneel.
Ga naar het tabblad Settings.
Klik in de sectie Deploy settings op Edit.
Voer het healthcheck-pad in.
Klik op Save Data.
Er wordt automatisch een nieuwe deployment gestart met de bijgewerkte instelling.

Als uw applicatie via een Dockerfile wordt gedeployed, kunt u het healthcheck-pad nog steeds configureren in het controlepaneel.
Als het Dockerfile echter een HEALTHCHECK-instructie bevat, heeft deze voorrang en wordt de instelling in het controlepaneel genegeerd.
Voorbeeld:
HEALTHCHECK --interval=30s --timeout=10s --retries=3 \
CMD curl -f http://localhost/health || exit 1
Raadpleeg voor meer details de officiële Docker-documentatie.
Voor Docker Compose-deployments wordt het configureren van het healthcheck-pad in het controlepaneel niet ondersteund.
Als uw services een Dockerfile gebruiken, kunt u HEALTHCHECK rechtstreeks daarin configureren; het zal zich gedragen zoals hierboven beschreven.