Healthcheck e readiness: duas perguntas diferentes

O processo estar de pé não significa que a aplicação está pronta para atender. Separar essas duas perguntas evita reinícios desnecessários e ajuda a achar o problema real.

Liveness: o processo responde?

O endpoint de liveness, comumente /health, responde apenas se o processo está funcionando. Ele não consulta banco nem serviços externos. Se ele falha, o processo travou e reiniciar o container faz sentido.

Readiness: a aplicação consegue trabalhar?

O endpoint de readiness, comumente /ready, verifica as dependências: conexão com o banco, com o Redis e com o que mais for essencial. Se ele falha, a aplicação está viva mas não consegue atender, e reiniciá-la não resolveria um banco fora do ar.

Por que separar

Se um único endpoint consulta o banco e o banco fica lento, o orquestrador reinicia todos os containers da aplicação em cascata, o que piora a situação. Com dois endpoints, a falha de dependência vira um sinal de alerta, e o reinício fica reservado para quando o processo realmente travou.

Boas práticas

• Timeouts curtos. O check não pode ficar pendurado esperando uma dependência lenta.
• Resposta enxuta. Retorne status e o resultado de cada verificação, sem expor versões, hosts ou credenciais.
• Códigos HTTP claros. 200 quando está tudo certo e 503 quando alguma dependência falhou.
• Healthcheck no Compose. Configure healthcheck nos serviços e use depends_on com condition: service_healthy para ordenar a subida.

Em resumo

Liveness diz se reinicia. Readiness diz se pode receber tráfego. Cada um responde a uma pergunta, e misturar os dois esconde o diagnóstico.

Precisa colocar uma aplicação em produção com monitoramento? Fale com a gente.