comparando auto-hospedados
Uptime Kuma vs Zabbix: de fora ou de dentro?
Os dois são gratuitos, os dois são auto-hospedados, e as semelhanças param por aí. O Zabbix coleta métricas de dentro dos seus servidores por meio de agentes. O Uptime Kuma pergunta de fora aos seus serviços se eles ainda respondem. Escolher errado deixa você operando uma plataforma de monitoramento para a qual ninguém tem tempo, ou com um verificador que não consegue dizer por que algo quebrou.
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 | Zabbix | Uptimepage | |
|---|---|---|---|
| licença | MIT | AGPL-3.0 desde a 7.0 | AGPL-3.0 |
| o que monitora | serviços, de fora | hosts, por dentro | serviços, de fora |
| agentes necessários | nenhum | um por host para as partes úteis | nenhum, sonda privada opcional |
| o que você roda | um contêiner | servidor + banco de dados + frontend PHP | um binário + compose |
| verificações de endpoint | 31 tipos, incl. bancos de dados · MQTT · navegador | cenários web + verificações simples | HTTP · TCP · DNS · TLS · domínio · ping · heartbeat · flow · manual |
| métricas de infraestrutura | nenhuma | CPU · memória · disco · logs · bancos de dados | nenhuma |
| verificações de outros lugares | via add-on Globalping | proxies que você hospeda | 13 regiões hospedadas |
| página de status para clientes | sim, só RSS | nenhuma, painéis no lugar | com sua marca, assinantes por e-mail + webhook |
| incidentes | publicados à mão | triggers + eventos, internos | abertos automaticamente pelas verificações |
| configuração como código | só pela interface, sem API de gerenciamento | API JSON-RPC, Terraform da comunidade | Terraform · REST · MCP, oficiais |
| equipes e papéis | um único login | usuários · grupos · papéis | organizações + papéis |
O Zabbix exige MySQL 8.0.30+, MariaDB 10.5+ ou PostgreSQL 13-18 (opcionalmente com TimescaleDB), além de PHP 8.0-8.5 sobre Apache 2.4 ou Nginx 1.20.
Os cenários web do Zabbix fazem asserções sobre códigos de status, strings obrigatórias e tempo de resposta. O servidor precisa ser compilado com suporte a cURL, e os redirecionamentos são limitados a dez.
Não existe provider oficial do Terraform para o Zabbix. O registry tem pelo menos cinco providers da comunidade, mantidos de forma independente do projeto.
Verificado em julho de 2026 com a documentação do Zabbix, a página de licença e a política de ciclo de vida dele, e com o repositório do Uptime Kuma. O Zabbix 7.4 chega ao fim da vida útil em 30 de setembro de 2026, então confira esta tabela de novo perto do lançamento da 8.0.
A divisão que decide
O Zabbix é baseado em agentes. Você instala um agente em cada host, e ele envia CPU, memória, disco, processos, linhas de log e dados internos de bancos de dados para um servidor central, que guarda tudo e avalia os triggers. O Uptime Kuma não usa agentes. Ele fica em algum lugar fazendo requisições e, se a resposta volta correta dentro do timeout, o serviço está no ar. Essa é a diferença inteira, e tudo o que vem abaixo decorre dela. O Zabbix responde por que um servidor não está saudável. O Uptime Kuma responde se um cliente consegue alcançá-lo. São perguntas diferentes, e nenhuma das duas ferramentas responde bem à pergunta da outra.
O que o Zabbix realmente exige para rodar
Mais do que se imagina. Uma instalação funcional é um servidor Zabbix, um banco de dados e um frontend PHP atrás de um servidor web. O Zabbix aceita MySQL 8.0.30 ou superior, MariaDB 10.5 ou superior, ou PostgreSQL 13 a 18, opcionalmente com a extensão TimescaleDB. O frontend pede PHP 8.0 a 8.5 com cerca de uma dúzia de extensões, sobre Apache 2.4 ou Nginx 1.20. Monitorar qualquer coisa do outro lado de uma fronteira de rede geralmente acrescenta um proxy Zabbix. Nada disso é difícil para quem vive de operar infraestrutura, e tudo isso é trabalho real que você continua fazendo: upgrades, crescimento do banco de dados e um schema que é, sozinho, a maior coisa a manter. A própria página de ciclo de vida do Zabbix lista a 7.4 como a versão padrão atual e a 7.0 como a LTS com suporte. Tudo até a 6.4 era GPL-2.0; da 7.0 em diante, o Zabbix é AGPL-3.0.
O Zabbix consegue verificar um site, mas é uma função secundária
Consegue de verdade. Os cenários web do Zabbix rodam uma sequência de passos HTTP e fazem asserções sobre códigos de status, strings obrigatórias no corpo da resposta e tempo de resposta, o que cobre um fluxo de login ou um caminho de cliques. Há também verificações simples, como icmpping e net.tcp.service, que não precisam de agente nenhum. O que você deve saber antes de apostar nisso: o servidor precisa ser compilado com suporte a cURL, os redirecionamentos são limitados a dez, e macros secretas não podem ser usadas em URLs porque são resolvidas mascaradas. Funciona. E é configurado como todo o resto no Zabbix, ou seja, com hosts, templates, itens e triggers, em vez de colar uma URL.
Do que o Uptime Kuma abre mão
Profundidade, e qualquer coisa parecida com uma equipe. O Kuma tem 31 tipos de monitor e 94 integrações de notificação, instala como um único contêiner em cinco minutos, e alguém que não é engenheiro consegue adicionar uma verificação. Mas ele tem um único login compartilhado, então todo mundo que vê o painel pode mudar qualquer coisa, e não há papéis. Não há API oficial para gerenciar monitores. E ele não sabe nada sobre o interior das suas máquinas: um host com 95% do disco ocupado fica invisível para o Kuma até o momento em que o serviço cai. O Zabbix teria avisado você uma semana antes.
Nenhum dos dois guarda a sua configuração no Git
Essa é a parte que pega as equipes mais tarde. O Uptime Kuma funciona só pela interface, sem API de gerenciamento, então os monitores existem onde quer que alguém os tenha criado com cliques. O Zabbix é melhor, com uma API JSON-RPC completa e templates que você pode exportar como YAML ou XML, mas não há provider oficial do Terraform. O registry tem pelo menos cinco da comunidade, de nzolot, claranet, elastic-infra, fe80 e tpretz, mantidos no ritmo que os autores escolherem. Se a sua infraestrutura é declarada no Terraform e revisada em pull requests, ter o monitoramento como uma pilha de estado manual na interface é uma lacuna real, e adotar um provider não oficial para isso é apostar num voluntário.
O ponto cego que os dois compartilham
Os dois rodam dentro do mesmo ambiente que monitoram. Se o host que roda o seu servidor Zabbix morre, nada coleta e nada alerta. Se o seu único contêiner do Kuma está na máquina que acabou de cair, a mesma coisa. Um monitoramento auto-hospedado que vive ao lado do que monitora sempre vai perder a queda que derruba os dois, e essa é justamente a queda que os seus clientes percebem. Esse é todo o argumento a favor de uma sonda em outro lugar.
Onde o Uptimepage se encaixa
O Uptimepage faz o trabalho de fora para dentro, de várias regiões por padrão, e você pode rodar o seu próprio agente de sonda dentro da rede para os alvos privados que um verificador externo não enxerga. Ele verifica HTTP, TCP, DNS e ping em intervalos a partir de 60 segundos no plano Founding gratuito e de 10 segundos auto-hospedado, além de heartbeat, TLS, vencimento de domínio e fluxos de navegador. A configuração fica no Git por meio de um provider do Terraform que nós publicamos e mantemos, de uma API REST e de um servidor MCP, então o monitoramento é revisado como o resto da sua infraestrutura. Além disso: uma página de status com a sua marca e assinantes por e-mail confirmado e webhook, incidentes abertos automaticamente a partir de verificações que falham e organizações com papéis em vez de uma senha compartilhada. É um único binário Rust. E é AGPL-3.0, a mesma licença que o Zabbix usa, então hospedar por conta própria é uma saída de verdade, não uma versão de teste. Ele não substitui o Zabbix para gráficos de CPU e planejamento de capacidade, nem tenta. Muitas equipes rodam o Zabbix por dentro e o Uptimepage por fora.
- 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