Un percorso di healthcheck consente alla piattaforma di verificare periodicamente che la tua applicazione sia in esecuzione e funzioni correttamente.
Per impostazione predefinita, se non è abilitato alcun health check, la piattaforma esegue solo un controllo di base dopo il deploy: si assicura che il container dell’applicazione sia stato avviato correttamente. In questo caso, lo stato reale dell’applicazione non viene valutato: l’app potrebbe rispondere in modo errato o non rispondere affatto, ma il deploy verrà comunque contrassegnato come riuscito.
Per evitare ciò, puoi configurare un percorso di health check. La tua applicazione deve esporre un endpoint che non dipenda da sistemi esterni (come un database o servizi di terze parti) e che rifletta accuratamente lo stato interno dell’applicazione.
Puoi specificare questo endpoint durante la configurazione: ad esempio, /health, /status o /ping.
Per impostazione predefinita, durante il deploy il sistema controlla solo l’URL root (/). Invia una richiesta alla pagina principale e, se lo stato della risposta non rientra nell’intervallo 2xx, il deploy viene considerato non riuscito.
Le richieste di healthcheck vengono sempre effettuate da localhost.
L’unico requisito è che l’endpoint restituisca un codice di stato 2xx. Il corpo della risposta non è rilevante; conta solo il codice di stato.
Se è configurato un percorso di healthcheck, il sistema invia fino a tre richieste GET consecutive alla nuova istanza dell’applicazione.
Se almeno una richiesta restituisce un codice di stato 2xx, il deploy viene considerato riuscito e la nuova versione diventa attiva.
Se tutti e tre i tentativi falliscono (qualsiasi codice diverso da 2xx), il deploy viene contrassegnato come non riuscito e la versione precedente rimane attiva.
I controlli continuano finché non si verifica una delle seguenti condizioni:
una singola risposta riuscita,
tre risposte consecutive non riuscite, con l’ultima che si verifica 40 secondi dopo l’avvio,
oppure trascorrono 180 secondi; se nessuna delle condizioni precedenti si verifica entro questo tempo, il deploy viene considerato non riuscito.
Se il controllo fallisce, nei log del deploy apparirà un messaggio di errore relativo all’healthcheck.
Una volta che un deploy ha successo, il sistema continua a verificare lo stato dell’applicazione con una richiesta ogni 30 secondi.
Se tre controlli consecutivi falliscono, l’applicazione viene riavviata automaticamente. Questo evento apparirà nei log dell’applicazione.

Puoi configurare un percorso di healthcheck durante la creazione di una nuova applicazione o successivamente per una già esistente.
Nella sezione App settings, inserisci il percorso desiderato nel campo Health Check path.
Ad esempio, se la tua applicazione fornisce un endpoint /health accessibile all’indirizzo https://domain/health, imposta:
/health

Apri l’applicazione nel pannello di controllo.
Vai alla scheda Settings.
Nella sezione Deploy settings, fai clic su Edit.
Inserisci il percorso di healthcheck.
Fai clic su Save Data.
Un nuovo deploy verrà automaticamente avviato con l’impostazione aggiornata.

Se la tua applicazione viene distribuita tramite un Dockerfile, puoi comunque configurare il percorso di healthcheck nel pannello di controllo.
Tuttavia, se il Dockerfile include un’istruzione HEALTHCHECK, questa ha la priorità e l’impostazione del pannello di controllo viene ignorata.
Esempio:
HEALTHCHECK --interval=30s --timeout=10s --retries=3 \
CMD curl -f http://localhost/health || exit 1
Per maggiori dettagli, consulta la documentazione ufficiale di Docker.
Per i deploy con Docker Compose, la configurazione del percorso di healthcheck nel pannello di controllo non è supportata.
Se i tuoi servizi utilizzano un Dockerfile, puoi configurare HEALTHCHECK direttamente al suo interno; si comporterà come descritto sopra.