comparando auto-hospedados
Uptime Kuma vs Healthchecks: eles não fazem o mesmo trabalho
Os dois são comparados o tempo todo, e a comparação costuma partir de uma premissa errada. O Uptime Kuma chama o seu serviço para ver se ele responde. O Healthchecks nunca chama nada: ele fica esperando o seu cron job chamá-lo e reclama quando a chamada não chega. Todo o resto decorre dessa direção.
A tabela abaixo é a comparação completa, sem edição. Leia primeiro, se preferir: é a mesma que enviaríamos para você.
AGPL-3.0 · um único binário · plano gratuito · sem cartão
Os fatos, lado a lado
| Uptime Kuma | Healthchecks | Uptimepage | |
|---|---|---|---|
| licença | MIT | BSD-3-Clause | AGPL-3.0 |
| como uma verificação funciona | ele chama o seu serviço | o seu job faz a chamada | nas duas direções |
| vigia uma URL | sim | nunca | sim |
| tipos de verificação | 31, incl. bancos de dados · MQTT · navegador | só pings de entrada | HTTP · TCP · DNS · TLS · domínio · ping · heartbeat · flow · manual |
| cron e jobs agendados | monitor push, só intervalo | cron + OnCalendar do systemd, fusos horários | heartbeat com período + tolerância, sem agendas cron |
| duração, código de saída e saída do job | não | sim | sim |
| granularidade mínima | 1 s | período de ping de 60 s | 60 s grátis · 30 s no Team · 10 s auto-hospedado |
| página de status | básica | só badges | com sua marca, domínio próprio no Pro |
| assinantes da página | só RSS | nenhum | e-mail · webhook |
| integrações de alerta | 94 serviços | ~28, incl. Signal · Apprise | 14 nativas |
| configuração como código | API via socket, sem REST | API REST, Terraform da comunidade | Terraform · REST · MCP |
| equipes e papéis | um único login | projetos + 4 papéis | organizações + papéis |
| rodar por conta própria | um contêiner (Node) | um contêiner (Django, SQLite) | um binário + compose |
| opção hospedada | não | sim, 20 verificações grátis | sim, plano gratuito |
| comunidade (estrelas no GitHub) | ~89 mil | ~10 mil | jovem |
O Healthchecks nunca faz uma requisição ao seu serviço; é o seu serviço que precisa fazer uma requisição a ele. Ele não consegue dizer que um site está fora do ar, e isso é proposital.
O monitor push do Uptime Kuma cobre o caso simples de dead man's switch. Aqui, só o Healthchecks entende agendas cron e OnCalendar do systemd com fuso horário; um heartbeat que só conhece um período não consegue perceber que um job noturno rodou na hora errada.
O provider do Terraform do Healthchecks é mantido pela comunidade, não é oficial.
Verificado em julho de 2026 com o Uptime Kuma 2.4.0 e o Healthchecks v4.2. Os dois projetos mudam rápido, então confira o código atual de cada um antes de decidir.
Um chama você, o outro espera a sua chamada
O Uptime Kuma é uma sonda ativa. Ele envia a requisição, lê a resposta e decide. O Healthchecks é um dead man's switch: o seu script de backup, o seu cron job, o seu relatório noturno manda um ping para uma URL quando termina, e o Healthchecks alerta quando um ping atrasa ou não chega. Isso significa que o Healthchecks não consegue dizer que o seu site está fora do ar, nunca, e isso é de propósito, não uma omissão. Se o seu cron job continua mandando pings todo contente enquanto o seu site retorna 500, o Healthchecks continua verde.
No que o Healthchecks é realmente o melhor
Saber se um job agendado rodou, e se rodou direito. Ele aceita expressões cron e agendas OnCalendar do systemd com fuso horário, então alerta quando um job não rodou na hora certa, e não apenas quando um intervalo passou. Sinalize o início e o fim e você ganha a duração; mande um ping para o endpoint de falha e você ganha o código de saída; envie um corpo e ele guarda a saída do job ao lado do ping. Nada na categoria de monitoramento de uptime faz isso direito. Ele tem licença BSD, roda como um único contêiner com SQLite, e o plano hospedado gratuito tem 20 verificações para sempre.
No que o Uptime Kuma é realmente o melhor
Alcance e imediatismo. A linha 2.x cobre 31 tipos de monitor, incluindo bancos de dados, MQTT, SNMP, gRPC e uma verificação com um navegador Chromium de verdade, notifica 94 serviços diferentes e reduz o intervalo mínimo para um segundo. É um único contêiner e uma instalação de cinco minutos. Ele também tem um monitor push, que é um dead man's switch simples, e essa sobreposição é o motivo de as pessoas fazerem essa pergunta.
A sobreposição, e onde ela falha
O monitor push do Kuma resolve o caso fácil: algo precisa dar sinal a cada N minutos, e você quer um aviso quando parar. Recorra ao Healthchecks quando o que importa é a própria agenda, porque um monitor push entende um intervalo e mais nada. Ele não sabe que o seu job deveria rodar às 03:00 em Europe/Helsinki, não vai avisar que a execução levou nove minutos quando costuma levar dois, e não vai guardar para você o stack trace do job que falhou. No sentido contrário, o Healthchecks nunca vai vigiar uma URL. Muitas equipes rodam os dois, e essa é uma resposta razoável, não uma saída pela tangente.
Onde o Uptimepage se encaixa
O Uptimepage faz as duas direções. Ele sonda por HTTP, TCP, DNS, TLS, vencimento de domínio, ping e fluxos de navegador, e recebe heartbeats de jobs que não têm nada para sondar, com período, tolerância, tempo máximo de execução e o código de saída e a saída da execução que falhou. O que ele não lê é uma expressão cron, então, se a pergunta é se o job de ontem à noite rodou na hora certa e no fuso horário certo, o Healthchecks faz isso melhor do que nós. O que o Uptimepage acrescenta aos dois é a parte que nenhum deles cobre: os clientes. Uma página de status com a sua marca no seu próprio subdomínio, assinantes por e-mail confirmado e webhook, incidentes abertos automaticamente a partir de verificações que falham, organizações com papéis em vez de um único login compartilhado, e um provider do Terraform, uma API REST e um servidor MCP. Grátis na versão hospedada, sem cartão, ou auto-hospedado sob AGPL.
- 01Entre com GitHub ou Google. Sem cartão, sem ligação de vendas.
- 02Cole uma URL. A primeira verificação roda antes de você terminar de ler isto.
- 03Publique a página de status, ou exporte-a para o Terraform e mantenha no Git.
api99,98%
p95 142 ms · um incidente em 45 dias
dashboard99,91%
p95 318 ms · dois dias com degradação
webhooks99,99%
p95 88 ms · nenhum incidente
RESOLVIDO14 min
Latência elevada na API do painel
14:22 resolvido, latência de volta abaixo de 300 ms
14:08 aberto automaticamente pela verificação do painel
no ar degradado fora do ar 45 dias · assinantes por e-mail e webhook