Original em inglês: https://argusic.com/best/uptime-monitoring

Monitores de uptime e páginas de status de código aberto, testados

Monitores e páginas de status que você pode executar por conta própria. A lista é ordenada por se cada projeto foi iniciado quando o Argusic o instalou do zero, com a gravação dessa tentativa a um clique de distância.

Testado entre 17 de setembro de 2026 e 30 de outubro de 2026. Cada linha mostra a sua própria data de teste; um projeto pode mudar depois desse dia.

17 de 17 projetos testados executam.

Em resumo: 15 dos 17 projetos testados iniciaram sem alterações em uma máquina nova: gatus, hertzbeat, kener, tinystatus, jump, maintenant, Uptimer e PongHub, e mais 7. Mais 2 iniciaram depois que um substituto tomou o lugar de um serviço de que eles dependem, como um banco de dados: tianji e UptimeKit-CLI.

Medido pela Argusic em uma máquina nova, todas as vezes. Cada número tem link para as suas evidências.

#	projeto	veredito	Pontuação Argusic	linguagem	estrelas	testado em
1	gatus	Executa	100 / 100	Go	12,501	23 de setembro de 2026
	Página de status automatizada voltada para desenvolvedores, com alertas e suporte a incidentes. O que o teste encontrou: Gatus builds from source, launches on port 8080, serves the health API returning 200, monitors all configured HTTP and DNS endpoints, and 74 of 76 Go test packages pass with only ICMP tests failing due to missing CAP_NET_RAW in the unprivileged container. 6 minutos.
2	hertzbeat	Executa	100 / 100	Java	7,453	23 de setembro de 2026
	Um sistema de observabilidade em tempo real, de código aberto, de próxima geração, com tecnologia de IA. O que o teste encontrou: HertzBeat server builds, its full Maven test suite passes except one Docker-only integration test, and the assembled server runs with working JWT login and authenticated API on port 1157 in this container. 37 minutos.
3	kener	Executa	100 / 100	TypeScript	5,237	24 de setembro de 2026
	Páginas de status impressionantes, com tudo incluído! O que o teste encontrou: Kener v4.1.3 is built, serves a status page on port 3000 with SQLite and Redis, all 136 tests pass, health endpoint confirms database and Redis connectivity. 14 minutos.
4	tinystatus	Executa	100 / 100	Python	1,588	6 de outubro de 2026
	Pequena página de status gerada por um script Python O que o teste encontrou: TinyStatus installs and runs cleanly out of the box: all 17 unit tests pass, and the app generates a valid status page with proper HTTP/ping/port check results, incident rendering, and history tracking. 2 minutos.
5	jump	Executa	100 / 100	PHP	605	30 de outubro de 2026
	Jump é uma startpage auto-hospedada e página de status em tempo real para o seu servidor, projetada para ser simples, elegante, rápida e segura. O que o teste encontrou: Jump runs on PHP 8.3 in the sandbox, serving /, /tag/*, static assets and the status API with real JSON, and reported 7 configured sites (4 online, 3 offline). 35 minutos.
6	maintenant	Executa	100 / 100	Go	532	18 de outubro de 2026
	Monitoramento auto-hospedado para Docker, Kubernetes e uptime. Um único binário Go, sem configuração de agent, alertas em tempo real. Adicione um container... O que o teste encontrou: maintenant binary builds and runs, serving HTTP 200 on health API and root endpoint, with 42 test suites passing. 6 minutos.
7	Uptimer	Executa	100 / 100	TypeScript	483	19 de setembro de 2026
	Uma Poderosa Página de Monitoramento de Uptime & Status Serverless na Rede Edge da Cloudflare O que o teste encontrou: Uptimer project installs, builds, passes all 488 unit tests across 50 test files, typechecks, lints, and runs locally with the worker API responding with correct data on public and authenticated admin endpoints. 10 minutos.
8	PongHub	Executa	100 / 100	Go	224	20 de setembro de 2026
	Monitoramento gratuito de endpoints. Deploy com um clique. O que o teste encontrou: PongHub builds, all 4 test packages pass, and the binary runs end-to-end against a real HTTP endpoint, correctly logging success and generating the HTML report. 4 minutos.
9	upstat	Executa	100 / 100	TypeScript	200	20 de setembro de 2026
	uma ferramenta simples de código aberto e auto-hospedada para monitoramento de status O que o teste encontrou: Upstat Go API builds and runs on port 8000 with SQLite, accepting user signup/signin, creating and listing monitors with heartbeat pings, and serving Swagger docs over HTTP. 17 minutos.
10	peekaping	Executa	96 / 100	Go	1,213	18 de setembro de 2026
	Melhor alternativa ao Uptime Kuma O que o teste encontrou: Peekaping API server starts on port 8034 with SQLite, connects to local Redis, and responds HTTP 200 on /api/v1/health. All 16 Go test packages pass. The React web frontend builds without errors. 16 minutos.
11	statuspage	Executa	96 / 100	JavaScript	768	19 de setembro de 2026
	Uma página de status simples, com zero dependências, puro js/html, baseada em GitHub Pages e Actions. O que o teste encontrou: Health check script curls 5 URLs and logs results; static server serves index.html, JS, CSS, SVG, config, and 5 log files with 200 status. 3 minutos.
12	issue-status	Executa	96 / 100	TypeScript	430	19 de setembro de 2026
	Uma página de status flexível, moderna e extremamente rápida. O que o teste encontrou: The issue-status monorepo is fully functional: pnpm install succeeds, tests pass (1 passed, 1 skipped/todo), the issue-status package builds via Vite, both CLIs build via tsdown, the example status page app builds and serves correctly via dev/built modes, and the GitHub provider fetches real data from the public... 37 minutos.
13	server-status	Executa	96 / 100	PHP	407	19 de setembro de 2026
	Página de status do servidor simples e com visual moderno, com administração e alguns recursos interessantes, que pode ser executada até mesmo em hospedagem... O que o teste encontrou: PHP 8.3 and MariaDB 10.11 are running, the server_status database has 11 tables with proper settings, and all pages (index, admin, install, API) respond with HTTP 200 and render correct content without warnings. 27 minutos.
14	fettle	Executa	91 / 100	TypeScript	282	20 de setembro de 2026
	Página de status gratuita e bonita com tecnologia GitHub, utilizando GitHub Pages, Actions e Issues para atualizações em tempo real e gerenciamento de... O que o teste encontrou: Fettle installs, builds, and exports cleanly (next.config.js patched for image optimization); the production server and the exported static site both serve HTTP 200, and a real headless-browser load of the exported page fetched live GitHub data and showed all systems operational with both services and incidents... 12 minutos.
15	uptime-kuma	Executa	64 / 100	JavaScript	93,261	20 de setembro de 2026
	Uma ferramenta de monitoramento auto-hospedada e sofisticada. O que o teste encontrou: Uptime Kuma 2.5.3 starts on Node.js 22, listens on port 3001, serves the setup page over HTTP, and passes 196 of 242 backend tests; 38 tests fail solely due to missing Docker and missing ping binary in the container sandbox. 10 minutos.
16	tianji	Executa com mocks	92 / 100	TypeScript	3,118	17 de setembro de 2026
	Tianji: Visão sobre tudo, Análises do Site + Monitor de Disponibilidade + Estado do Servidor. Não apenas mais uma alternativa ao GA. O que o teste encontrou: Dependencies installed, project builds successfully, shared and most server unit tests pass, client component tests mostly pass; server cannot launch without a PostgreSQL database. 25 minutos.
17	UptimeKit-CLI	Executa com mocks	92 / 100	JavaScript	277	20 de setembro de 2026
	Um CLI moderno e multiplataforma para monitorar sites e APIs. O que o teste encontrou: The project builds, its 246-unit test suite passes 6/6 suites, and the CLI starts a background daemon, adds HTTP/DNS/SSL monitors, and renders a live TUI dashboard with real monitoring data (DNS resolution, SSL certificate validation, HTTP checks). The edit command was fixed to accept 0 retries. Node 22 is required. 18 minutos.

Executa instalou e iniciou com as suas dependências reais. Executa com mocks iniciou depois que substitutos tomaram o lugar de serviços externos, como um banco de dados ou uma API de terceiros. Não foi possível verificar nem o agent padrão nem o mais forte conseguiram fazê-lo executar dentro do limite de tempo; o log mostra onde ele parou.

Antes de escolher

Decida se você quer executar um banco de dados. Cinco projetos iniciaram sem alterações, com um banco de dados embutido ou SQLite (gatus, PongHub, upstat, hertzbeat e kener, que também subiu um Redis real); três esperavam um Redis, MySQL ou PostgreSQL que o agent teve que substituir (peekaping, server-status, tianji). A coluna de veredito e o resultado sob cada nome dizem em qual grupo um projeto está antes de você ler o README.

Decida se você precisa de monitoramento ou apenas de uma página de status. statuspage e fettle são sites estáticos que publicam um status que você fornece a eles; eles não conseguem verificar nada por conta própria. gatus, uptime-kuma e peekaping executam as verificações e hospedam a página. tianji vai além e inclui análise de tráfego web; também está na lista de análise auto-hospedada, com sua própria classificação lá.

Observe os minutos. O tempo que cada execução de verificação levou é uma boa aproximação de quanto uma primeira instalação exige de você: 7 a 12 minutos para os projetos de binário único e estáticos, 23 a 38 para os que constroem uma stack completa (hertzbeat, issue-status, server-status, upstat).

Leia o resultado antes da contagem de estrelas. uptime-kuma tem de longe o maior número de estrelas e ainda assim fica em décimo segundo lugar, porque no dia do teste ele só iniciou depois que um frontend pré-construído foi baixado e 46 dos seus 240 testes de backend falharam; a linha diz isso, e o log mostra isso.

Como testamos

Para um monitor ou página de status, funcionar significava que o processo do servidor subiu na máquina limpa e respondeu via HTTP: a interface web ou um endpoint de health respondeu, e, quando o projeto inclui um conjunto de testes, o conjunto foi executado.

Duas coisas separaram os vereditos nesta lista. Projetos com um único binário ou um armazenamento SQLite embutido iniciaram como estão; gatus, por exemplo, passou a executar verificações HTTP e DNS reais contra endpoints ativos. Projetos que esperam um banco de dados, um cache ou uma fila de mensagens só iniciaram quando o agent substituiu esse serviço: peekaping precisava de um Redis em processo, server-status de um MySQL local e tianji de um PostgreSQL construído a partir de pacotes extraídos. Esses são "executa com mocks".

Saída do terminal de gatus na máquina de teste da Argusic, 30 de outubro de 2026 — As últimas linhas da execução de verificação de gatus, o projeto mais bem classificado. Log completo e gravação na página dele.

Verificações que precisam de infraestrutura que um container não fornece, como ICMP ping (raw sockets) ou Docker, aparecem como testes com falha no log e não bloquearam o veredito quando o servidor em si estava ativo; uptime-kuma é o caso mais claro. Páginas de status estáticas foram construídas e servidas localmente; statuspage e fettle são exemplos.

Gráfico de barras: 15 executaram sem alterações, 2 executaram com mocks, 0 não puderam ser verificados, Monitores de uptime e páginas de status de código aberto, testados, 30 de outubro de 2026 — Vereditos desta lista segundo o teste mais recente.

Nesta lista, segundo o teste mais recente: 15 projetos executaram sem alterações, 2 com mocks, 0 não puderam ser verificados. Linguagens testadas: Go, Java, JavaScript, PHP, Python, TypeScript. Cada tentativa usou uma máquina limpa e descartável, o projeto em uma versão fixada e um limite de 45 minutos; o procedimento completo está na página da metodologia.

Perguntas frequentes (FAQ)

O que significa "executa" para um monitor de uptime?

O servidor foi iniciado em uma máquina limpa e respondeu por HTTP, com sua suíte de testes executada quando existe. Isso não significa que todo tipo de verificação funciona: ping precisa de privilégios de socket bruto que um container não tem, e isso aparece como testes com falha no log, não no veredito.

Por que o uptime-kuma não está no topo?

A classificação é medida, não editorial. Na data do teste, o servidor só iniciou depois que o agent baixou um front-end pré-compilado e aplicou um patch de timeout, e os testes que precisam de Docker ou ping falharam. Isso é "executa com mocks", que fica abaixo de projetos que iniciaram sem modificações. O log está a um clique de distância na linha dele.

Esses projetos precisam de um banco de dados para serem auto-hospedados?

Depende do projeto. Vários nesta lista rodaram com SQLite ou sem banco de dados algum. Os marcados como "executa com mocks" precisavam de um serviço que o agent teve que simular, como Redis, MySQL ou PostgreSQL; a página de cada projeto informa qual.

Páginas de status estáticas são testadas da mesma forma?

Sim. O agent construiu o site e serviu a saída localmente; statuspage e fettle são exemplos. Uma página estática não pode monitorar nada por conta própria, então ela responde apenas à metade da pergunta sobre página de status.

Quão atual é esta lista?

Cada linha tem sua própria data de teste e a página informa a janela. Um projeto pode mudar após seu teste; uma nova tentativa substitui o veredito apenas quando termina com evidências completas.

Como esta lista é classificada?

Por medição, não por opinião: primeiro os projetos que a Argusic instalou e iniciou em uma máquina nova, depois os que executaram com mocks no lugar de serviços externos, depois os que ela não conseguiu verificar. Os empates são decididos pela Pontuação Argusic e depois pela popularidade do projeto na sua própria fonte.

Onde estão as evidências?

Cada linha tem link para a página do projeto na Argusic, onde cada execução tem um log completo e uma gravação do terminal guardados com uma impressão digital sha256. As mesmas páginas existem para todos os projetos testados, estejam nesta lista ou não.

Mais listas nesta categoria

Todas as listas: Melhores. Todos os projetos testados: projetos.