Healthcheck e heartbeat: como escolher o sinal de vida certo para cada componente

Autor: Pedro Tebaldi PM do KeepGreen

Publicado ago/2026

Um dashboard inteiramente verde não prova que o sistema funciona. Ele prova apenas que alguma verificação respondeu. Quando essa verificação pergunta a coisa errada, a equipe descobre a falha pelo telefone do cliente, nunca pelo alerta.

Healthcheck e heartbeat são os dois mecanismos que sustentam essa verificação. Ambos respondem à pergunta “isso ainda está vivo?”, porém em direções opostas. Um deles vai até o serviço e pergunta. O outro fica em silêncio esperando o serviço avisar.

Na prática, essa escolha não é estética. Ela define quanto tempo passa até alguém perceber a falha, quantos alertas falsos o plantão recebe e quais componentes seguem invisíveis.

Esse custo aparece nos números do setor. Segundo a análise anual de indisponibilidades do Uptime Institute, 57% das organizações dizem que a última parada relevante custou mais de US$ 100 mil.

O que é healthcheck

O healthcheck é uma verificação ativa na qual um agente externo consulta o serviço em intervalos regulares para saber se ele está saudável. Funciona no modelo pull. O balanceador, o orquestrador ou a sonda de monitoramento chama um endpoint, avalia a resposta e decide o que fazer com aquela instância.

Na prática, três atores diferentes fazem essa pergunta. O orquestrador quer saber se deve reiniciar o processo. O balanceador de carga quer saber se pode mandar tráfego. A sonda externa quer saber se o usuário final consegue usar o sistema.

Por isso, cada ator merece uma resposta própria. Um monitoramento de load balancer bem configurado tira o backend do rodízio assim que ele para de responder, sem derrubar o processo. Já a sonda externa nem sempre depende de endpoint: a monitoração sintética simula a jornada real do usuário.

Tecnicamente, o healthcheck aceita vários formatos. HTTP com código de status é o formato mais comum. Ainda assim, TCP, gRPC e execução de comando dentro do container cumprem o mesmo papel quando o serviço não expõe uma rota web.

O que é heartbeat

O heartbeat é o sinal periódico que um componente envia para avisar que continua vivo. Funciona no modelo push: em vez de alguém perguntar, o próprio serviço bate na porta do monitor dentro de uma janela combinada. A ausência do sinal vira o alerta, o que inverte por completo a lógica do monitoramento tradicional.

Esse desenho resolve um problema que o healthcheck simplesmente não alcança. Rotinas de backup, cargas noturnas de ERP, pipelines de ETL e workers de fila não têm URL para chamar. Eles nascem, trabalham e morrem. Ninguém consegue perguntar nada a um processo que roda às 3h da manhã e termina em oito minutos.

Por isso o heartbeat funciona como um dead man’s switch. O job avisa que começou, depois avisa que terminou. Em seguida, o monitor cobra o sinal que não chegou. Se a rotina falha em silêncio, o alerta dispara mesmo assim.

Outro ponto prático pesa em ambiente corporativo. Como o sinal sai de dentro para fora, o heartbeat atravessa firewall e NAT sem regra de entrada, sem VPN e sem porta exposta. Clusters usam a mesma ideia entre nós: quando o batimento de um nó some, os processos de failover assumem a carga.

Healthcheck e heartbeat: as diferenças na prática

A diferença central está na direção do sinal. No healthcheck, o monitor pergunta e o serviço responde: silêncio significa que a instância caiu ou que a rede falhou. No heartbeat, o serviço avisa e o monitor apenas escuta: silêncio significa que a execução não aconteceu.

Vale destacar um ponto que o comparativo deixa claro: os dois não competem. Quase toda operação madura usa os dois ao mesmo tempo, em camadas diferentes do mesmo ambiente.

Liveness, readiness e startup: as três perguntas do Kubernetes

No Kubernetes, o conceito de healthcheck se divide em três probes com consequências bem distintas. A livenessProbe decide se o container deve reiniciar. A readinessProbe decide se o Pod recebe tráfego. Já a startupProbe segura as outras duas enquanto a aplicação termina de subir.

Confundir as duas primeiras custa caro. Quando a liveness falha acima do limite configurado, o kubelet mata o container.

Já a readiness age de outro jeito: o controlador apenas remove o IP do Pod dos Services, conforme a documentação oficial de probes. Uma ação é destrutiva, a outra é reversível.

# Tres probes, tres perguntas diferentes
livenessProbe:
  httpGet:
    path: /live
    port: 8080
  periodSeconds: 10
  failureThreshold: 3
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 5
  failureThreshold: 2
startupProbe:
  httpGet:
    path: /live
    port: 8080
  periodSeconds: 5
  failureThreshold: 30

O erro mais comum aparece justamente aqui: apontar as duas probes para o mesmo /health. Nesse cenário, uma lentidão no banco reprova a liveness, o kubelet reinicia containers saudáveis e o incidente cresce sozinho. Quem precisa monitorar clusters Kubernetes em produção separa as rotas desde o primeiro deploy.

Quando o healthcheck mente: checagem rasa e checagem profunda

Existem dois estilos de verificação, com riscos opostos. A checagem rasa responde 200 se o processo consegue processar a requisição. Ela é honesta sobre o processo, porém ignora o mundo em volta.

Uma checagem profunda faz o contrário: consulta o banco, testa a fila, valida o cache e só então responde. O diagnóstico fica muito mais rico, mas surge um efeito cascata perigoso. Se o banco compartilhado oscila por vinte segundos, todas as instâncias reprovam ao mesmo tempo.

Esse cenário produz um comportamento contraintuitivo.

Conforme a documentação da AWS sobre grupos de destino, o balanceador faz fail open quando todos os alvos ficam unhealthy ao mesmo tempo. Ou seja, ele volta a rotear tráfego para todos, saudáveis ou não.

Em resumo, a regra prática é simples. Use checagem rasa onde a falha provoca restart. Use checagem profunda onde a falha apenas tira a instância do rodízio ou gera alerta, nunca onde ela mata o processo.

Como calibrar intervalo, timeout e threshold

Antes de tudo, calibrar significa escolher quanto tempo você aceita ficar no escuro. A conta é direta: tempo de detecção ≈ intervalo × falhas consecutivas + timeout. Cada parâmetro empurra esse número para cima ou para baixo.

Aplique a conta nos números padrão e o resultado surpreende. No Kubernetes, dez segundos vezes três falhas dão até 30 segundos até o restart. No ALB, trinta segundos vezes duas falhas passam de um minuto até o alvo sair do rodízio.

Por outro lado, apertar tudo tem custo. Verificação a cada segundo em cem instâncias gera tráfego constante, ruído no log e uma enxurrada de eventos transitórios. Esse é o caminho mais curto para a fadiga de alertas, quando o time passa a ignorar justamente o alerta que importava.

Qual sinal usar em cada componente

A decisão fica objetiva quando você olha para o componente, não para a ferramenta. A pergunta é sempre a mesma: esse componente tem endereço fixo para receber uma consulta?

Do sinal ao alerta: o que muda na operação

Um sinal só vira valor quando chega à pessoa certa com contexto suficiente. Do contrário, ele apenas engorda o volume de eventos que ninguém lê.

Antes de tudo, separe o que reinicia do que notifica. Falha de readiness costuma se resolver sozinha em segundos e não merece telefonema. Já um heartbeat perdido de rotina de faturamento merece, porque nada vai se autocorrigir na madrugada.

Além disso, trate a própria verificação como um dado observável. Quantas vezes a probe reprovou nas últimas 24 horas? Essa métrica antecipa degradação antes do incidente e sustenta uma rotina de monitoramento em tempo real com números, não com percepção.

Por fim, escreva a regra de tolerância junto com o time que atende o plantão. Quem responde ao alerta às 4h da manhã sabe melhor do que ninguém quantos minutos de silêncio realmente significam um problema.

Conclusão

Healthcheck e heartbeat resolvem o mesmo medo por caminhos opostos. O primeiro pergunta ao serviço e serve muito bem a tudo que tem endereço fixo: APIs, sites, bancos e instâncias atrás de um balanceador.

O segundo escuta o silêncio. Além disso, cobre justamente a parte do ambiente que costuma ficar sem monitoramento nenhum: rotinas noturnas, backups, workers e dispositivos em campo.

A maturidade aparece na calibração, não na escolha da ferramenta. Intervalo, timeout e número de falhas consecutivas definem o tempo real de detecção. Portanto, vale documentar esses números do mesmo jeito que você documenta um SLA. Verificação rasa onde a falha reinicia, verificação profunda onde a falha só alerta: essa separação evita que o próprio monitoramento derrube o ambiente.

Se a sua operação ainda descobre incidente pelo cliente, o problema raramente está na falta de ferramenta. Está no sinal errado, no lugar errado, com a tolerância errada. Fale com um especialista da OpServices para desenhar essa camada de verificação junto com quem monitora ambientes críticos todos os dias.