Original en inglés: https://argusic.com/best/uptime-monitoring

Monitores de tiempo de actividad y páginas de estado de código abierto, probados

Monitores y páginas de estado que puedes ejecutar tú mismo. La lista está ordenada según si cada proyecto funcionó cuando Argusic lo instaló desde cero, con la grabación de ese intento a un clic de distancia.

Probado entre el 17 de septiembre de 2026 y el 30 de octubre de 2026. Cada fila muestra su propia fecha de prueba; un proyecto puede cambiar después de ese día.

17 de 17 proyectos probados funcionan.

En resumen: 15 de los 17 proyectos probados arrancaron tal cual en una máquina limpia: gatus, hertzbeat, kener, tinystatus, jump, maintenant, Uptimer, PongHub y 7 más. 2 más arrancaron cuando un sustituto reemplazó un servicio que esperan, como una base de datos: tianji y UptimeKit-CLI.

Medido por Argusic en una máquina limpia cada vez. Cada cifra enlaza a su evidencia.

#	proyecto	veredicto	Puntuación Argusic	lenguaje	estrellas	probado el
1	gatus	Funciona	100 / 100	Go	12,501	23 de septiembre de 2026
	Página de estado automatizada orientada a desarrolladores con alertas y soporte de incidentes Lo que encontró la prueba: 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	Funciona	100 / 100	Java	7,453	23 de septiembre de 2026
	Un sistema de observabilidad en tiempo real de próxima generación, de código abierto e impulsado por IA. Lo que encontró la prueba: 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	Funciona	100 / 100	TypeScript	5,237	24 de septiembre de 2026
	¡Páginas de estado impresionantes, con todo incluido! Lo que encontró la prueba: 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	Funciona	100 / 100	Python	1,588	6 de octubre de 2026
	Pequeña página de estado generada por un script de Python. Lo que encontró la prueba: 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	Funciona	100 / 100	PHP	605	30 de octubre de 2026
	Jump es una página de inicio y página de estado en tiempo real self-hosted para tu servidor, diseñada para ser simple, elegante, rápida y segura. Lo que encontró la prueba: 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	Funciona	100 / 100	Go	532	18 de octubre de 2026
	Monitoreo self-hosted para Docker, Kubernetes y tiempo de actividad. Un único binario de Go, sin configuración de agent, alertas en vivo. Coloca un contenedor... Lo que encontró la prueba: maintenant binary builds and runs, serving HTTP 200 on health API and root endpoint, with 42 test suites passing. 6 minutos.
7	Uptimer	Funciona	100 / 100	TypeScript	483	19 de septiembre de 2026
	Una poderosa página de monitoreo de tiempo de actividad y estado serverless en la Edge Network de Cloudflare. Lo que encontró la prueba: 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	Funciona	100 / 100	Go	224	20 de septiembre de 2026
	Monitoreo de endpoints gratuito. Despliegue con un clic. Lo que encontró la prueba: 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	Funciona	100 / 100	TypeScript	200	20 de septiembre de 2026
	una herramienta simple de monitoreo de estado, de código abierto y self-hosted Lo que encontró la prueba: 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	Funciona	96 / 100	Go	1,213	18 de septiembre de 2026
	Mejor alternativa a Uptime Kuma Lo que encontró la prueba: 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	Funciona	96 / 100	JavaScript	768	19 de septiembre de 2026
	Una página de estado simple, pura js/html, con cero dependencias, basada en GitHub Pages y Actions. Lo que encontró la prueba: 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	Funciona	96 / 100	TypeScript	430	19 de septiembre de 2026
	Una página de estado flexible, moderna y rapidísima. Lo que encontró la prueba: 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	Funciona	96 / 100	PHP	407	19 de septiembre de 2026
	Página de estado de servidor simple y moderna, con administración y algunas funciones interesantes, que puede ejecutarse incluso en hosting compartido. Lo que encontró la prueba: 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	Funciona	91 / 100	TypeScript	282	20 de septiembre de 2026
	Página de estado gratuita impulsada por GitHub que utiliza GitHub Pages, Actions e Issues para actualizaciones en tiempo real y gestión de incidentes... Lo que encontró la prueba: 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	Funciona	64 / 100	JavaScript	93,261	20 de septiembre de 2026
	Una elegante herramienta de monitoreo self-hosted. Lo que encontró la prueba: 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	Funciona con mocks	92 / 100	TypeScript	3,118	17 de septiembre de 2026
	Tianji: información sobre todo, analítica web + monitor de tiempo de actividad + estado del servidor. No solo otra alternativa a GA. Lo que encontró la prueba: 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	Funciona con mocks	92 / 100	JavaScript	277	20 de septiembre de 2026
	Un CLI moderno y multiplataforma para monitorear sitios web y APIs. Lo que encontró la prueba: 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.

Funciona se instaló y arrancó con sus dependencias reales. Funciona con mocks arrancó después de que unos sustitutos reemplazaran servicios externos, como una base de datos o una API de terceros. No se pudo verificar ni el agent estándar ni el más potente consiguieron que funcionara dentro del límite de tiempo; el log muestra dónde se detuvo.

Antes de elegir

Decide si quieres ejecutar una base de datos. Cinco proyectos empezaron tal cual con un almacén integrado o SQLite (gatus, PongHub, upstat, hertzbeat y kener, que también inició un Redis real); tres esperaban un Redis, MySQL o PostgreSQL que el agente tuvo que sustituir (peekaping, server-status, tianji). La columna de veredicto y el hallazgo debajo de cada nombre te indican en qué grupo está un proyecto antes de que leas su README.

Decide si necesitas monitoreo o solo una página de estado. statuspage y fettle son sitios estáticos que publican un estado que tú les proporcionas; no pueden verificar nada por sí mismos. gatus, uptime-kuma y peekaping ejecutan las comprobaciones y alojan la página. tianji va más allá e incluye análisis web; también está en la lista de análisis self-hosted, con su propia clasificación allí.

Mira los minutos. El tiempo que tomó cada ejecución de verificación es un buen indicador de cuánto te exige una primera instalación: de 7 a 12 minutos para los proyectos de un solo binario y los estáticos, de 23 a 38 para los que construyen una pila completa (hertzbeat, issue-status, server-status, upstat).

Lee el hallazgo antes que el número de estrellas. uptime-kuma tiene, con diferencia, la mayor cantidad de estrellas y aun así ocupa el puesto doce, porque el día de su prueba solo inició después de descargar un front end ya compilado y 46 de sus 240 pruebas de backend fallaron; la fila lo dice, y el log lo muestra.

Cómo lo probamos

Para un monitor o página de estado, funcionar significaba que el proceso del servidor se iniciaba en la máquina limpia y respondía por HTTP: la interfaz de usuario web o un endpoint de salud respondía, y cuando el proyecto incluye un conjunto de pruebas, el conjunto se ejecutaba.

Dos cosas separaron los veredictos en esta lista. Los proyectos con un solo binario o un almacén SQLite empaquetado se iniciaban tal cual; gatus, por ejemplo, pasaba a ejecutar comprobaciones HTTP y DNS reales contra endpoints en vivo. Los proyectos que esperan una base de datos, un caché o una cola de mensajes solo se iniciaban una vez que el agent actuaba en lugar de ese servicio: peekaping necesitaba un Redis en proceso, server-status un MySQL local, y tianji un PostgreSQL compilado a partir de paquetes extraídos. Esos son "funciona con mocks".

Salida de terminal de gatus en la máquina de pruebas de Argusic, 30 de octubre de 2026 — Las últimas líneas de la ejecución de verificación de gatus, el proyecto mejor clasificado. El log completo y la grabación están en su página.

Las comprobaciones que necesitan infraestructura que un contenedor no proporciona, como ICMP ping (raw sockets) o Docker, aparecen como pruebas fallidas en el log y no bloqueaban el veredicto cuando el servidor en sí estaba arriba; uptime-kuma es el caso más claro. Las páginas de estado estáticas se compilaban y servían localmente; statuspage y fettle son ejemplos.

Gráfico de barras: 15 funcionaron tal cual, 2 funcionaron con mocks, 0 no se pudieron verificar, Monitores de tiempo de actividad y páginas de estado de código abierto, probados, 30 de octubre de 2026 — Veredictos de esta lista según la prueba más reciente.

En esta lista, según la prueba más reciente: 15 proyectos funcionaron tal cual, 2 con mocks, 0 no se pudieron verificar. Lenguajes probados: Go, Java, JavaScript, PHP, Python, TypeScript. Cada intento usó una máquina limpia de un solo uso, el proyecto en una versión fijada y un límite de 45 minutos; el procedimiento completo está en la página de metodología.

Preguntas frecuentes (FAQ)

¿Qué significa "runs" para un monitor de uptime?

El servidor se inició en una máquina limpia y respondió por HTTP, con su suite de pruebas ejecutada donde existe. No significa que todos los tipos de verificación funcionen: ping necesita derechos de raw-socket que un contenedor no tiene, y eso aparece como pruebas fallidas en el log, no en el veredicto.

¿Por qué uptime-kuma no está en la cima?

La clasificación es medida, no editorial. En su fecha de prueba, el servidor se inició solo después de que el agent descargó un frontend precompilado y parcheó un shim de timeout, y las pruebas que necesitan Docker o ping fallaron. Eso es "runs with mocks", que se clasifica por debajo de los proyectos que se iniciaron tal cual. El log está a un clic en su fila.

¿Necesitan una base de datos para ser self-hosted?

Depende del proyecto. Varios en esta lista se ejecutaron en SQLite o sin base de datos. Los marcados como "runs with mocks" necesitaron un servicio que el agent tuvo que suplantar, como Redis, MySQL o PostgreSQL; la página de cada proyecto indica cuál.

¿Las páginas de estado estáticas se prueban de la misma manera?

Sí. El agent construyó el sitio y sirvió la salida localmente; statuspage y fettle son ejemplos. Una página estática no puede monitorear nada por sí sola, por lo que responde solo la mitad de la pregunta sobre la página de estado.

¿Qué tan actualizada está esta lista?

Cada fila tiene su propia fecha de prueba y la página indica la ventana. Un proyecto puede cambiar después de su prueba; un nuevo intento reemplaza el veredicto solo cuando finaliza con evidencia completa.

¿Cómo se clasifica esta lista?

Por medición, no por opinión: primero los proyectos que Argusic instaló e inició en una máquina limpia, después los que funcionaron con mocks en lugar de los servicios externos y después los que no pudo verificar. Los empates se deciden por la Puntuación Argusic y después por su popularidad en su propia fuente.

¿Dónde está la evidencia?

Cada fila enlaza a la página de Argusic del proyecto, donde cada ejecución tiene un log completo y una grabación de terminal guardados con una huella sha256. Existen las mismas páginas para cada uno de los proyectos probados, estén o no en esta lista.

Más listas de esta categoría

Todas las listas: Los mejores. Todos los proyectos probados: proyectos.