Un chemin de healthcheck permet à la plateforme de vérifier périodiquement que votre application est en cours d’exécution et fonctionne correctement.
Par défaut, si aucun health check n’est activé, la plateforme effectue uniquement une vérification de base après le déploiement : elle s’assure que le conteneur de l’application a démarré avec succès. Dans ce cas, l’état réel de l’application n’est pas évalué — l’application peut répondre incorrectement ou ne pas répondre du tout, et pourtant le déploiement sera marqué comme réussi.
Pour éviter cela, vous pouvez configurer un chemin de health check. Votre application doit exposer un endpoint qui ne dépend pas de systèmes externes (tels qu’une base de données ou des services tiers) et qui reflète fidèlement l’état interne de l’application.
Vous pouvez spécifier cet endpoint lors de la configuration : par exemple, /health, /status ou /ping.
Par défaut, lors du déploiement, le système vérifie uniquement l’URL racine (/). Il envoie une requête à la page principale, et si le statut de la réponse n’est pas dans la plage 2xx, le déploiement est considéré comme échoué.
Les requêtes de healthcheck sont toujours effectuées depuis localhost.
La seule exigence est que l’endpoint retourne un code de statut 2xx. Le corps de la réponse n’a pas d’importance ; seul le code de statut compte.
Si un chemin de healthcheck est configuré, le système envoie jusqu’à trois requêtes GET consécutives à la nouvelle instance de l’application.
Si au moins une requête retourne un code de statut 2xx, le déploiement est considéré comme réussi et la nouvelle version devient active.
Si les trois tentatives échouent (tout code autre que 2xx), le déploiement est marqué comme échoué et la version précédente reste active.
Les vérifications continuent jusqu’à ce que l’une des conditions suivantes soit remplie :
une seule réponse réussie,
trois réponses échouées consécutives, la dernière survenant 40 secondes après le démarrage,
ou 180 secondes s’écoulent ; si aucune des conditions ci-dessus ne se produit dans ce délai, le déploiement est considéré comme échoué.
Si la vérification échoue, un message d’échec du healthcheck apparaîtra dans les logs de déploiement.
Une fois qu’un déploiement réussit, le système continue de vérifier l’état de l’application avec une requête toutes les 30 secondes.
Si trois vérifications consécutives échouent, l’application est automatiquement redémarrée. Cet événement apparaîtra dans les logs de l’application.

Vous pouvez configurer un chemin de healthcheck lors de la création d’une nouvelle application ou ultérieurement pour une application existante.
Dans la section App settings, saisissez le chemin souhaité dans le champ Health Check path.
Par exemple, si votre application fournit un endpoint /health accessible à l’adresse https://domain/health, définissez :
/health

Ouvrez l’application dans le panneau de contrôle.
Accédez à l’onglet Settings.
Dans la section Deploy settings, cliquez sur Edit.
Saisissez le chemin de healthcheck.
Cliquez sur Save Data.
Un nouveau déploiement sera automatiquement déclenché avec le paramètre mis à jour.

Si votre application est déployée via un Dockerfile, vous pouvez toujours configurer le chemin de healthcheck dans le panneau de contrôle.
Cependant, si le Dockerfile inclut une instruction HEALTHCHECK, celle-ci prévaut et le paramètre du panneau de contrôle est ignoré.
Exemple :
HEALTHCHECK --interval=30s --timeout=10s --retries=3 \
CMD curl -f http://localhost/health || exit 1
Pour plus de détails, consultez la documentation officielle de Docker.
Pour les déploiements Docker Compose, la configuration du chemin de healthcheck dans le panneau de contrôle n’est pas prise en charge.
Si vos services utilisent un Dockerfile, vous pouvez configurer HEALTHCHECK directement à l’intérieur ; il se comportera comme décrit ci-dessus.