Melhores monitores de uptime open source e auto-hospedados (2026)

Se você buscou um monitor de uptime auto-hospedado, ou uma alternativa à ferramenta que está ficando pequena para você, a decisão importante já está tomada. Você quer os dados nos seus próprios servidores, nenhuma fatura por monitor e nenhum fornecedor que possa mudar o plano gratuito quando bem entender. O resto é escolher a ferramenta que combina com o jeito como a sua equipe trabalha.

Nós desenvolvemos uma das ferramentas desta lista, o Uptimepage, então tenha isso em mente. Tentamos limitar a descrição de todas as outras a fatos que continuam verdadeiros, e não a funcionalidades que ficam desatualizadas em um mês, porque esta categoria inteira anda rápido. Confira a documentação atual antes de se comprometer. Dito isso, aqui está um guia honesto para 2026.

Principais conclusões

• O Uptime Kuma é o padrão dos homelabs: um contêiner, 31 tipos de monitor e 94 integrações de notificação, mas um único login compartilhado, nenhuma API REST oficial para gerenciar monitores e páginas de status básicas.
• O Gatus é a escolha quando o monitoramento deve morar no Git, como YAML, para a sua própria equipe.
• O Checkmate é a opção mais recente no estilo do Kuma, com uma interface moderna e páginas de status com temas, se você puder rodar um stack de Node e MongoDB.
• O OneUptime e o Apache HertzBeat são plataformas completas para o ciclo de vida inteiro dos incidentes, ou para bancos de dados e equipamentos de rede, quando você consegue carregar o peso.
• O Zabbix e o Nagios Core monitoram os seus servidores por dentro; eles conseguem consultar uma URL, mas nenhum dos dois oferece aos clientes uma página de status.
• O Cachet e o Statping priorizam a página de status; equipes que já usam Prometheus podem adicionar o Blackbox exporter.
• O OpenStatus é a alternativa AGPL mais próxima que faz os dois trabalhos com monitoramento como código, embora hospedá-lo por conta própria signifique rodar vários serviços em vez de um.
• O Uptimepage (o nosso) junta monitoramento, uma página de status para clientes e plantão num único binário AGPL, com API REST, Terraform, papéis e assinantes, para quando um único login compartilhado já não basta.

O que realmente importa quando você hospeda por conta própria

Três perguntas organizam esta categoria mais rápido do que qualquer tabela de funcionalidades.

Primeiro, você quer uma página de status que os seus clientes veem, ou só alertas internos? Algumas ferramentas fazem uma coisa bem e só acoplam a outra. Segundo, você configura clicando, ou quer a configuração no Git? Essa preferência sozinha elimina metade da lista para a maioria das pessoas. Terceiro, quanto você quer operar? Um único binário num VPS pequeno é um compromisso diferente de uma plataforma que espera Kubernetes. E, seja qual for a sua escolha, confira se a página de status mostra o uptime que ela mediu, e não só os incidentes que você publicou, ou seja, uma página de status que não dá para falsificar.

Tenha essas três perguntas em mente e as escolhas ficam óbvias. Aqui está a lista inteira comparada com elas num relance, antes dos detalhes de cada ferramenta.

O site ou a API que você quer monitorar > monitorar

Uptime Kuma

O padrão, e com razão. O Uptime Kuma é a ferramenta que a maioria das pessoas tem em mente quando fala em “monitor de uptime auto-hospedado”. Um contêiner Docker, um painel limpo, uma longa lista de tipos de monitor, notificações para quase tudo. Se você roda um homelab ou um punhado de projetos paralelos, pode parar de ler aqui e ir instalá-lo.

O limite dele aparece com equipes. Em 2026, ele ainda usa um único login compartilhado (o pull request de multiusuário continua aberto), então todo mundo que consegue ver o painel pode mudar qualquer coisa. Não há API REST oficial para gerenciar monitores, a configuração mora no banco de dados, e não num arquivo que você possa versionar, e as páginas de status são básicas comparadas com as de uma ferramenta voltada para clientes. Nada disso importa para um Raspberry Pi monitorando o seu blog. Tudo isso começa a importar quando uma segunda pessoa precisa de acesso.

Se você está esbarrando nesses limites, é nesse momento que o resto desta lista fica interessante. Escrevemos uma comparação com o Uptime Kuma mais longa, se você quiser os detalhes.

Gatus

O Gatus é a ferramenta para quem quer o monitoramento em YAML e em nenhum outro lugar. Você descreve cada endpoint num arquivo de configuração, faz o commit, e o Gatus o monitora. Ele é minúsculo, fala muitos protocolos e se encaixa perfeitamente num fluxo de GitOps.

O ponto fraco também é o ponto forte. Não há interface web para editar as verificações, então quem não é engenheiro não consegue mexer nele, e a página de status é funcional, mas não algo que você colocaria na frente dos clientes. Se o seu monitoramento deve morar num pull request e o seu público é a sua própria equipe, o Gatus é uma ótima resposta.

Checkmate

O Checkmate é a opção forte mais recente entre as ferramentas parecidas com o Kuma, e está evoluindo rápido. Ele cobre verificações de site e HTTP, ping, portas TCP, certificados SSL, contêineres Docker e até servidores de jogos, e traz páginas de status com uma interface moderna. Os alertas vão para os lugares de sempre: e-mail, webhooks, Slack, Discord, PagerDuty, Telegram, Teams e SMS via Twilio. Se você também quer métricas de hardware, um agente leve separado chamado Capture adiciona CPU, memória, disco e temperatura por host. Ele é AGPL, como o Uptimepage.

O custo operacional é o stack: um backend Node.js mais MongoDB, rodando via Docker Compose ou Helm, em vez de um único binário. E ele é jovem, então vale a mesma ressalva que fazemos sobre nós mesmos: teve menos anos do que o Kuma para encontrar e corrigir bugs raros. Se você gosta do escopo do Kuma, mas quer uma interface mais moderna e páginas de status com temas, vale dar uma olhada.

OneUptime

O OneUptime é a plataforma que faz tudo: monitoramento, páginas de status, plantão, gestão de incidentes e logs num único projeto de código aberto. Se você quer substituir várias ferramentas pagas de uma vez e tem capacidade operacional para rodá-lo, ele faz muita coisa.

Mas fazer tanto também é o problema. Ele é mais pesado do que uma ferramenta de binário único e espera que você esteja à vontade com Docker ou Kubernetes e com uma boa fatia de recursos. Num VPS pequeno, é a ferramenta errada. Para uma equipe de plataforma que já roda Kubernetes e quer um único sistema de código aberto responsável pelo ciclo de vida inteiro dos incidentes, vale o trabalho extra. O OneUptime comparado com o Uptime Kuma analisa essa troca em detalhes.

Apache HertzBeat

O HertzBeat é o que acontece quando o monitoramento de uptime cresce até virar uma plataforma de monitoramento completa, na forma de um projeto Apache. Ele não usa agentes: tudo é descrito em templates YAML que falam HTTP, SSH, SNMP, JMX, JDBC e Prometheus, então a mesma ferramenta que faz ping no seu site também consegue monitorar MySQL, Redis, Kafka, Kubernetes e o switch no seu rack. Ele tem um construtor de páginas de status e alertas por e-mail, Slack, Discord, Telegram, SMS e mais.

O custo é a complexidade. Um deploy de produção é uma aplicação Java mais um banco de dados relacional mais um banco de séries temporais, o que é um compromisso diferente de um único binário Go. Escolha-o quando a cobertura ampla for o objetivo, quando você quiser um único sistema monitorando bancos de dados, middleware e equipamentos de rede, e não só URLs. Para verificações simples de uptime e uma página de status para clientes, é mais plataforma do que o trabalho exige.

Zabbix

O Zabbix aparece na maioria das listas de monitores auto-hospedados, e merece o lugar, mas responde a uma pergunta diferente. Ele é baseado em agentes: um agente em cada host envia CPU, memória, disco, processos, logs e dados internos de bancos de dados para um servidor central, que guarda tudo e avalia os triggers. Então ele consegue dizer por que um servidor não está saudável, coisa que nenhum verificador externo consegue. Ele é AGPL-3.0 desde a 7.0.

Ele também consegue verificar um site. Os cenários web rodam uma sequência de passos HTTP e fazem asserções sobre códigos de status, strings no corpo da resposta e tempo de resposta, e verificações simples como icmpping e net.tcp.service não precisam de agente. Mas você as configura do jeito do Zabbix, como hosts, templates, itens e triggers, em vez de colar uma URL. O que você opera é um servidor, um banco de dados e um frontend PHP, geralmente com um proxy a mais para qualquer coisa do outro lado de uma fronteira de rede. Ele tem painéis operacionais, e não uma página que os seus clientes possam ler, e uma API JSON-RPC completa, mas nenhum provider oficial do Terraform. Escolha-o quando você quiser monitorar o interior dos seus servidores. Só para verificações de fora para dentro, é muita plataforma para rodar. O Uptime Kuma comparado com o Zabbix analisa essa divisão em detalhes.

Cachet e Statping-ng

Estes dois cobrem o canto das páginas de status. O Cachet é uma página de status de longa data, feita em PHP, que está passando por uma reconstrução, e é na reconstrução que moram as ressalvas: a v3 ainda está em desenvolvimento, sem versão estável, a versão com tag mais recente continua sendo a v2.4.1, de 2023, e o branch v3 é distribuído sob uma licença própria do tipo source-available, e não sob a licença BSD que a 2.x tinha. O que ele faz bem é o trabalho de página de status em si, agora incluindo assinantes por e-mail confirmado. Ele é uma página antes de tudo: a v3 adicionou uma verificação HTTP básica, mas você mesmo a agenda, e uma falha muda a cor de um componente em vez de abrir um incidente, então na prática você continua alimentando-o a partir de outro lugar. O Statping-ng é um fork mantido pela comunidade do antigo Statping, um único binário Go que faz tanto o monitoramento quanto uma página de status, com uma comunidade menor por trás.

Escolha estes se uma página de status é o produto de que você realmente precisa e o monitoramento é secundário ou já está resolvido. O Cachet comparado com o Uptime Kuma mostra do que você abre mão no lado das verificações, e a comparação das páginas de status de código aberto analisa todas as opções que priorizam a página.

Uma nota sobre o Beszel

O Beszel aparece em toda discussão sobre “alternativa ao Kuma”, então vamos poupar o seu tempo: ele não é um monitor de uptime. É um painel de servidor muito bom e muito leve. Um agente em cada host envia CPU, memória, disco, rede, temperaturas e estatísticas do Docker por contêiner para um único hub, com alertas para cerca de vinte serviços. O que ele não faz é consultar um endpoint: nada de verificações HTTP, TCP, DNS ou TLS, e nenhuma página de status pública. As pessoas o rodam ao lado de um monitor de uptime, não no lugar de um. Se você quer métricas de host junto com as verificações de uptime numa única ferramenta, é para isso que servem o HertzBeat ou o OneUptime.

Prometheus, Nagios e o stack de infraestrutura

Não é um produto, é um padrão, e vale citá-lo porque muitas equipes já trabalham assim. Se você roda Prometheus, o Blackbox exporter consulta HTTP, TCP, DNS e ICMP, e o Alertmanager cuida dos alertas. Você ganha um poder enorme e constrói a experiência por conta própria, incluindo a página de status e o fluxo de plantão. Para uma equipe que já está mergulhada no Prometheus, adicionar verificações de uptime é um passo pequeno. Para qualquer outra, é muito trabalho para montar. O Blackbox exporter comparado com o Uptime Kuma calcula quanto a versão montada custa de verdade.

O Nagios Core é o membro mais antigo desta família e continua sendo mantido. Ele roda cada verificação como um pequeno plugin que retorna OK, WARNING, CRITICAL ou UNKNOWN, então o check_http ou o check_ping no servidor Nagios oferece consultas de fora para dentro, e o NRPE chega ao interior de um host. Tudo é declarado em arquivos de configuração em texto, o que combina com o Git, e ele é GPL-2.0. O que falta é uma página de status para clientes: a interface web dele é um console de operador. O Icinga começou como um fork do Nagios, e o Checkmk cresceu sobre o núcleo do Nagios, então a mesma troca vale para os dois. Eles são muito bons em monitorar a infraestrutura que é sua, e publicar o uptime para qualquer pessoa de fora da sua equipe é outro trabalho.

OpenStatus

O OpenStatus é a ferramenta desta lista mais próxima do que nós construímos: um projeto AGPL que reúne páginas de status e monitoramento de uptime num só lugar, com uma API REST de verdade, um servidor MCP e um provider do Terraform que agora cobre monitores, páginas de status e notificações, e não só verificações. O serviço hospedado dele verifica a partir de vinte e oito regiões em três nuvens, e o mesmo fluxo de monitoramento como código funciona tanto no plano gerenciado quanto auto-hospedado.

A pegadinha está no formato do stack auto-hospedado. Rodar o OpenStatus por conta própria significa operar vários serviços separados, a API, o painel, o verificador, o processador de workflows e o renderizador da página de status, em vez de um único processo. Para uma equipe que quer o plano gerenciado e hospeda por conta própria de vez em quando, tudo bem. Se ter tudo na sua própria máquina é o objetivo, são mais peças móveis do que numa ferramenta de binário único. Comparamos o OpenStatus e o Uptime Kuma, se você está pesando os dois.

Uptimepage

O nosso, então aqui vão o lado bom e o aviso juntos.

O Uptimepage é um único binário Rust que faz monitoramento de uptime e uma página de status para clientes ao mesmo tempo, com as partes que os usuários do Uptime Kuma costumam pedir: uma API REST de verdade, um provider do Terraform, organizações com papéis, agentes de sonda multirregião que você mesmo roda e páginas de status que os seus clientes podem assinar por e-mail ou webhook. Ele também cobre o plantão: escalas de plantão e políticas de escalonamento decidem quem é acionado quando uma verificação falha. Ele é AGPL, então é só rodar docker compose up e ele é seu, ou você pode usar o monitor de uptime hospedado e pular a parte de rodá-lo. O mesmo modelo de dados, a mesma API e o mesmo provider do Terraform funcionam dos dois jeitos, então você não fica preso a essa escolha. Há mais sobre rodá-lo como monitor de uptime de código aberto, sobre o setup auto-hospedado e sobre controlá-lo por código.

A ressalva: ele é mais novo que o Uptime Kuma e tem uma comunidade menor, então teve menos anos para encontrar e corrigir bugs raros. Se você quer a opção mais testada e comprovada e não precisa de API nem de acesso multi-tenant, o Uptime Kuma é a escolha mais segura hoje. Se você já não cabe num único login compartilhado e quer o monitoramento no Git, é exatamente para essa lacuna que nós o construímos.

Como escolher sem pensar demais

Para um homelab ou alguns projetos pessoais, instale o Uptime Kuma e siga em frente, ou experimente o Checkmate se quiser a interface mais moderna. Para uma equipe que quer a configuração no Git e só precisa de alertas internos, use o Gatus; escrevemos uma análise mais detalhada de como o Kuma e o Gatus diferem, se você está dividido entre os dois. Se o objetivo é uma página de status caprichada para clientes, com assinantes e API, veja uma página de status de código aberto com monitoramento embutido, que é a fatia em que nos concentramos. Se você quer ser dono do ciclo de vida inteiro dos incidentes e já roda Kubernetes, o OneUptime é a opção ampla. E se você já vive no Prometheus, o Blackbox exporter é um pequeno acréscimo. Se você precisa saber por que um servidor está doente, e não só se ele responde, isso é território do Zabbix ou do Nagios, e muitas equipes rodam um deles ao lado de um verificador externo.

Não existe uma única melhor ferramenta aqui, só a que bate com as suas três respostas. A boa notícia é que todas são grátis para experimentar e grátis para abandonar, e esse é justamente o sentido de continuar no código aberto.

Perguntas frequentes

Qual é a melhor alternativa ao Uptime Kuma?

Depende de qual limite você encontrou. Se for o único login compartilhado e a falta de uma API REST, o Uptimepage e o OpenStatus oferecem equipes e monitoramento como código; a comparação entre o OpenStatus e o Kuma trata dessa escolha. Se você quer a configuração no Git, o Gatus. Se quer uma interface mais moderna fazendo o mesmo trabalho, o Checkmate. Se quer métricas de host e de middleware na mesma ferramenta, o HertzBeat.

Qual monitor de uptime de código aberto é o melhor para desenvolvedores?

Se você quer tudo no Git e revisado num pull request, o Gatus e o Uptimepage se encaixam no fluxo de trabalho de quem desenvolve, o Gatus com um arquivo YAML e o Uptimepage com um provider do Terraform e uma API REST. O Uptime Kuma é mais amigável para quem prefere clicar, mas a API dele é a interface interna via Socket.io, e não uma API REST com suporte para gerenciar monitores, então ele é a escolha mais fraca quando você quer monitoramento como código.

O que é monitoramento de uptime externo?

Significa verificar o seu serviço de fora da sua própria rede, do jeito que um usuário real chega até ele, e não a partir de um processo na mesma máquina. Verificações externas pegam falhas de DNS, de TLS e na borda que um healthcheck interno nunca vê. Todas as ferramentas desta lista fazem monitoramento externo; as que têm sondas multirregião, como o Uptimepage, permitem verificar de mais de um lugar ao mesmo tempo.

O Zabbix ou o Nagios são bons monitores de uptime?

São monitores de infraestrutura que também conseguem verificar uptime. Os dois consultam URLs a partir do servidor, o Zabbix com cenários web e o Nagios com plugins como o check_http, mas nenhum dos dois oferece uma página de status aos seus clientes, e ambos dão mais trabalho para rodar do que uma ferramenta dedicada a uptime. Muitas equipes rodam um deles por dentro e um verificador separado por fora.

Posso ter a página de status em white label?

Algumas ferramentas permitem. Se você tem uma agência ou revende monitoramento e precisa do seu próprio logo, das suas cores e do seu domínio diante dos clientes, procure uma ferramenta feita para isso. Essa é a fatia que cobrimos em monitoramento de uptime white label, em que cada cliente recebe uma página com marca própria, sem nenhum nome de fornecedor à vista.