Los mejores monitores de disponibilidad autoalojados (2026)

Si buscó un monitor de disponibilidad autoalojado, o una alternativa a la herramienta que se le está quedando pequeña, ya tomó la decisión importante. Quiere los datos en sus propios servidores, ninguna factura por monitor y ningún proveedor que pueda cambiar el plan gratuito cuando quiera. Lo demás es elegir la herramienta que encaje con la forma de trabajar de su equipo.

Nosotros desarrollamos una de las herramientas de esta lista, Uptimepage, así que téngalo en cuenta. Hemos intentado limitar la descripción de todas las demás a hechos que siguen siendo ciertos, en lugar de afirmaciones sobre funciones que se quedan anticuadas en un mes, porque toda esta categoría avanza rápido. Consulte la documentación actual antes de decidirse. Dicho esto, aquí tiene una guía honesta para 2026.

Lo esencial

• Uptime Kuma es la opción por defecto para un homelab: un contenedor, 31 tipos de monitor y 94 integraciones de notificación, pero un único inicio de sesión compartido, ninguna API REST oficial para gestionar monitores y páginas de estado básicas.
• Gatus es la elección cuando el monitoreo debe vivir en Git como YAML, para su propio equipo.
• Checkmate es la opción más reciente al estilo de Kuma, con una interfaz moderna y páginas de estado con temas, si puede ejecutar un stack de Node y MongoDB.
• OneUptime y Apache HertzBeat son plataformas completas para todo el ciclo de vida del incidente, o para bases de datos y equipos de red, cuando puede cargar con su peso.
• Zabbix y Nagios Core vigilan sus servidores desde dentro; pueden sondear una URL, pero ninguno ofrece a los clientes una página de estado.
• Cachet y Statping son ante todo páginas de estado; los equipos que ya usan Prometheus pueden añadir el Blackbox exporter.
• OpenStatus es la alternativa AGPL más cercana que hace los dos trabajos con monitoreo como código, aunque autoalojarlo implica ejecutar varios servicios en lugar de uno.
• Uptimepage (la nuestra) reúne monitoreo, una página de estado para clientes y guardias en un solo binario AGPL, con API REST, Terraform, roles y suscriptores, para cuando un único inicio de sesión compartido se le quede pequeño.

Lo que de verdad importa al autoalojar

Tres preguntas ordenan esta categoría más rápido que cualquier tabla de funciones.

Primero, ¿quiere una página de estado que vean sus clientes, o solo alertas internas? Algunas herramientas hacen bien una cosa y añaden la otra como un parche. Segundo, ¿configura con clics, o quiere la configuración en Git? Esa sola preferencia descarta media lista para la mayoría de la gente. Tercero, ¿cuánto quiere operar? Un solo binario en un VPS pequeño es un compromiso distinto de una plataforma que espera Kubernetes. Y elija la que elija, compruebe que su página de estado muestre la disponibilidad que ha medido, no solo los incidentes que usted publicó, que es una página de estado que no se puede falsear.

Con esas tres en mente, la elección se vuelve obvia. Esta es la lista completa frente a ellas, de un vistazo, antes del detalle de cada una.

El sitio o la API que quiere vigilar > monitorear

Uptime Kuma

La opción por defecto, y con razón. Uptime Kuma es la herramienta en la que piensa la mayoría cuando dice «monitor de disponibilidad autoalojado». Un contenedor de Docker, un panel limpio, una larga lista de tipos de monitor, notificaciones a casi cualquier cosa. Si tiene un homelab o un puñado de proyectos personales, puede dejar de leer aquí e ir a instalarlo.

Su límite aparece con los equipos. A fecha de 2026, sigue usando un único inicio de sesión compartido (el pull request de multiusuario sigue abierto), así que cualquiera que pueda ver el panel puede cambiar cualquier cosa. No hay ninguna API REST oficial para gestionar monitores, la configuración vive en la base de datos y no en un archivo que pueda versionar, y las páginas de estado son básicas comparadas con una herramienta pensada para clientes. Nada de eso importa para una Raspberry Pi que vigila su blog. Todo empieza a importar en cuanto una segunda persona necesita acceso.

Si está chocando con esos límites, ese es el momento en que el resto de esta lista se vuelve interesante. Escribimos una comparativa con Uptime Kuma más extensa, si quiere los detalles.

Gatus

Gatus es la herramienta para quien quiere su monitoreo en YAML y en ningún otro lugar. Usted describe cada endpoint en un archivo de configuración, hace commit y Gatus lo vigila. Es diminuto, habla muchos protocolos y encaja perfectamente en un flujo de trabajo GitOps.

Su debilidad es también su fortaleza. No hay interfaz web para editar las comprobaciones, así que alguien que no es ingeniero no puede tocarlo, y la página de estado es funcional, no algo que pondría delante de sus clientes. Si su monitoreo debe vivir en un pull request y su público es su propio equipo, Gatus es una gran respuesta.

Checkmate

Checkmate es la opción sólida más reciente entre las herramientas del estilo de Kuma, y avanza rápido. Cubre comprobaciones de sitios web y HTTP, ping, puertos TCP, certificados SSL, contenedores de Docker e incluso servidores de juegos, e incluye páginas de estado con una interfaz moderna. Las alertas van a los destinos habituales: correo electrónico, webhooks, Slack, Discord, PagerDuty, Telegram, Teams y SMS mediante Twilio. Si también quiere métricas de hardware, un agente ligero aparte llamado Capture añade CPU, memoria, disco y temperatura por host. Es AGPL, como Uptimepage.

El coste operativo es el stack: un backend de Node.js más MongoDB, ejecutados con Docker Compose o Helm, en lugar de un solo binario. Y es joven, así que aquí vale la misma salvedad que hacemos sobre nosotros: menos años que Kuma para encontrar y corregir errores poco frecuentes. Si le gusta el alcance de Kuma pero quiere una interfaz más actual y páginas de estado con temas, merece un vistazo.

OneUptime

OneUptime es la plataforma que lo hace todo: monitoreo, páginas de estado, guardias, gestión de incidentes y logs en un solo proyecto de código abierto. Si quiere sustituir varias herramientas de pago a la vez y tiene la capacidad operativa para ejecutarlo, hace mucho.

Pero hacer tanto también es el problema. Es más pesado que una herramienta de un solo binario y espera que usted se maneje con soltura con Docker o Kubernetes y disponga de una buena cantidad de recursos. En un VPS pequeño es la herramienta equivocada. Para un equipo de plataforma que ya ejecuta Kubernetes y quiere un único sistema de código abierto que se encargue de todo el ciclo de vida del incidente, compensa el trabajo extra. OneUptime frente a Uptime Kuma analiza ese compromiso en detalle.

Apache HertzBeat

HertzBeat es lo que ocurre cuando el monitoreo de disponibilidad crece hasta convertirse en una plataforma de monitoreo completa, como proyecto de Apache. No usa agentes: todo se describe en plantillas YAML que hablan HTTP, SSH, SNMP, JMX, JDBC y Prometheus, así que la misma herramienta que hace ping a su sitio web también puede vigilar MySQL, Redis, Kafka, Kubernetes y el switch de su rack. Tiene un generador de páginas de estado y alertas por correo electrónico, Slack, Discord, Telegram, SMS y más.

El precio es la complejidad. Un despliegue en producción es una aplicación Java más una base de datos relacional más un almacén de series temporales, un compromiso distinto de un solo binario de Go. Elíjalo cuando la amplitud de cobertura sea justo lo que busca, cuando quiera un solo sistema que vigile bases de datos, middleware y equipos de red, no solo URL. Para comprobaciones de disponibilidad sencillas y una página de estado para clientes, es más plataforma de la que el trabajo necesita.

Zabbix

Zabbix aparece en la mayoría de las listas de monitores autoalojados, y se gana el puesto, pero responde a otra pregunta. Se basa en agentes: un agente en cada host envía CPU, memoria, disco, procesos, logs y datos internos de las bases de datos a un servidor central que lo almacena todo y evalúa los disparadores. Así que puede decirle por qué un servidor no está sano, algo que ningún comprobador externo puede hacer. Es AGPL-3.0 desde la 7.0.

También puede comprobar un sitio web. Los escenarios web ejecutan una secuencia de pasos HTTP y verifican códigos de estado, cadenas en el cuerpo y tiempo de respuesta, y las comprobaciones simples como icmpping y net.tcp.service no necesitan agente. Eso sí, se configuran a la manera de Zabbix, con hosts, plantillas, ítems y disparadores, en lugar de pegar una URL. Lo que usted opera es un servidor, una base de datos y un frontend PHP, normalmente más un proxy para todo lo que esté al otro lado de un límite de red. Tiene paneles operativos en lugar de una página que puedan leer sus clientes, y una API JSON-RPC completa pero ningún proveedor de Terraform oficial. Elíjalo cuando quiera vigilar el interior de sus servidores. Solo para comprobaciones desde fuera, es mucha plataforma que ejecutar. Uptime Kuma frente a Zabbix recorre esa división en detalle.

Cachet y Statping-ng

Estas dos cubren el rincón de las páginas de estado. Cachet es una página de estado en PHP con muchos años a sus espaldas que está pasando por una reescritura, y es en la reescritura donde están las salvedades: la v3 sigue en desarrollo sin ninguna versión estable, la versión etiquetada más reciente sigue siendo la v2.4.1, de 2023, y la rama v3 se distribuye bajo una licencia propia de código disponible (source-available) en lugar de la BSD que tenía la 2.x. Lo que hace bien es el trabajo de la página de estado en sí, que ahora incluye suscriptores por correo electrónico confirmado. Es ante todo una página: la v3 añadió una comprobación HTTP básica, pero la programa usted y un fallo cambia el color de un componente en lugar de abrir un incidente, así que en la práctica sigue alimentándolo desde otro lugar. Statping-ng es un fork del antiguo Statping que mantiene la comunidad, un solo binario de Go que hace tanto monitoreo como página de estado, con una comunidad más pequeña detrás.

Elija estas si lo que de verdad necesita es una página de estado y el monitoreo es secundario o ya está resuelto. Cachet frente a Uptime Kuma expone a qué renuncia en el lado de las comprobaciones, y el repaso de páginas de estado de código abierto compara todas las opciones centradas en la página.

Una nota sobre Beszel

Beszel sale en todos los hilos de «alternativas a Kuma», así que le ahorramos tiempo: no es un monitor de disponibilidad. Es un panel de servidores muy bueno y muy ligero. Un agente en cada host envía CPU, memoria, disco, red, temperaturas y estadísticas de Docker por contenedor a un único hub, con alertas a unos veinte servicios. Lo que no hace es sondear un endpoint: ni comprobaciones HTTP, TCP, DNS o TLS, ni página de estado pública. La gente lo ejecuta junto a un monitor de disponibilidad, no en su lugar. Si quiere métricas de host junto con sus comprobaciones de disponibilidad en una sola herramienta, para eso están HertzBeat o OneUptime.

Prometheus, Nagios y el stack de infraestructura

No es un producto, es un patrón, y merece la pena nombrarlo porque muchos equipos ya trabajan así. Si ejecuta Prometheus, el Blackbox exporter sondea HTTP, TCP, DNS e ICMP, y Alertmanager se encarga de las alertas. Obtiene una potencia enorme y construye usted mismo la experiencia, incluidos la página de estado y el flujo de guardias. Para un equipo que ya está metido de lleno en Prometheus, añadir comprobaciones de disponibilidad es un paso pequeño. Para cualquier otro, es mucho trabajo de montaje. El Blackbox exporter frente a Uptime Kuma suma lo que cuesta de verdad la versión ensamblada.

Nagios Core es el miembro más antiguo de esta familia y todavía se mantiene. Ejecuta cada comprobación como un pequeño plugin que devuelve OK, WARNING, CRITICAL o UNKNOWN, así que check_http o check_ping en el servidor de Nagios le dan sondeo desde fuera, y NRPE llega al interior de un host. Todo se declara en archivos de configuración de texto, lo que encaja con Git, y es GPL-2.0. Lo que le falta es una página de estado para clientes: su interfaz web es una consola de operador. Icinga nació como fork de Nagios y Checkmk creció sobre el núcleo de Nagios, así que el mismo compromiso vale para ambos. Son muy buenos vigilando la infraestructura que es suya, y publicar la disponibilidad para cualquiera fuera de su equipo es otro trabajo.

OpenStatus

OpenStatus es la herramienta de esta lista más cercana a lo que construimos nosotros: un proyecto AGPL que reúne páginas de estado y monitoreo de disponibilidad en un solo lugar, con una API REST de verdad, un servidor MCP y un proveedor de Terraform que ahora cubre monitores, páginas de estado y notificaciones, no solo comprobaciones. Su servicio alojado sondea desde veintiocho regiones de tres nubes, y el mismo flujo de trabajo de monitoreo como código funciona tanto si usa el plan gestionado como si lo autoaloja.

La pega es la forma del stack autoalojado. Ejecutar OpenStatus usted mismo significa operar varios servicios separados (la API, el panel, el comprobador, el procesador de flujos de trabajo y el renderizador de páginas de estado) en lugar de un solo proceso. Para un equipo que quiere el plan gestionado y autoaloja de vez en cuando, no hay problema. Si lo que busca es tenerlo todo en su propia máquina, son más piezas móviles que una herramienta de un solo binario. Comparamos OpenStatus y Uptime Kuma, por si está sopesando esas dos.

Uptimepage

La nuestra, así que aquí van juntos lo bueno y la advertencia.

Uptimepage es un solo binario de Rust que hace a la vez monitoreo de disponibilidad y una página de estado para clientes, con las piezas que suelen pedir los usuarios de Uptime Kuma: una API REST de verdad, un proveedor de Terraform, organizaciones con roles, agentes de sondeo multirregión que ejecuta usted mismo y páginas de estado a las que sus clientes pueden suscribirse por correo electrónico o webhook. También cubre las guardias: los calendarios de turnos y las políticas de escalado deciden a quién se avisa cuando falla una comprobación. Es AGPL, así que basta con docker compose up y es suyo, o puede usar el monitor de disponibilidad alojado y ahorrarse ejecutarlo. El mismo modelo de datos, la misma API y el mismo proveedor de Terraform funcionan en ambos casos, así que esa elección no le ata. Hay más sobre cómo ejecutarlo como monitor de disponibilidad de código abierto, sobre la instalación autoalojada y sobre manejarlo desde código.

La salvedad: es más joven que Uptime Kuma y tiene una comunidad más pequeña, así que ha tenido menos años para encontrar y corregir errores poco frecuentes. Si quiere la opción más probada y contrastada y no necesita una API ni acceso multiinquilino, Uptime Kuma es hoy la elección más segura. Si un único inicio de sesión compartido se le ha quedado pequeño y quiere su monitoreo en Git, ese hueco es exactamente para lo que lo construimos.

Cómo elegir sin darle demasiadas vueltas

Para un homelab o unos pocos proyectos personales, instale Uptime Kuma y siga adelante, o pruebe Checkmate si quiere una interfaz más actual. Para un equipo que quiere la configuración en Git y solo necesita alertas internas, use Gatus; escribimos un análisis más detallado de en qué se diferencian Kuma y Gatus por si duda entre esos dos. Si lo que importa es una página de estado para clientes cuidada, con suscriptores y una API, mire una página de estado de código abierto con monitoreo integrado, que es la parte en la que nos centramos. Si quiere encargarse de todo el ciclo de vida del incidente y ya ejecuta Kubernetes, OneUptime es la opción amplia. Y si ya vive en Prometheus, el Blackbox exporter es un añadido pequeño. Si necesita saber por qué un servidor está enfermo, no solo si responde, eso es terreno de Zabbix o Nagios, y muchos equipos ejecutan uno de ellos junto a un comprobador externo.

Aquí no hay una única herramienta mejor, solo la que encaja con sus tres respuestas. La buena noticia es que todas son gratis de probar y gratis de abandonar, que es justo la razón de quedarse en el código abierto.

Preguntas frecuentes

¿Cuál es la mejor alternativa a Uptime Kuma?

Depende del límite con el que se tope. Si es el único inicio de sesión compartido y la falta de una API REST, Uptimepage y OpenStatus le dan equipos y monitoreo como código; la comparativa entre OpenStatus y Kuma cubre esa elección. Si quiere la configuración en Git, Gatus. Si quiere una interfaz más actual que haga el mismo trabajo, Checkmate. Si quiere métricas de host y middleware en la misma herramienta, HertzBeat.

¿Qué monitor de disponibilidad de código abierto es mejor para desarrolladores?

Si quiere todo en Git y revisado en un pull request, Gatus y Uptimepage encajan en el flujo de trabajo de desarrollo, Gatus con un archivo YAML y Uptimepage con un proveedor de Terraform y una API REST. Uptime Kuma es más fácil de manejar con clics, pero su API es la interfaz interna de Socket.io y no una API REST con soporte para gestionar monitores, así que es la opción más débil cuando quiere monitoreo como código.

¿Qué es el monitoreo de disponibilidad externo?

Significa comprobar su servicio desde fuera de su propia red, como llega a él un usuario real, y no desde un proceso en la misma máquina. Las comprobaciones externas detectan fallos de DNS, de TLS y en el borde de la red que una comprobación de salud interna nunca ve. Todas las herramientas de esta lista hacen monitoreo externo; las que tienen sondas multirregión, como Uptimepage, le permiten comprobar desde más de un lugar a la vez.

¿Son Zabbix o Nagios buenos monitores de disponibilidad?

Son monitores de infraestructura que también pueden comprobar la disponibilidad. Los dos sondean URL desde el servidor, Zabbix con escenarios web y Nagios con plugins como check_http, pero ninguno ofrece a sus clientes una página de estado, y los dos exigen más para funcionar que una herramienta dedicada a la disponibilidad. Muchos equipos ejecutan uno por dentro y un comprobador aparte por fuera.

¿Puedo tener la página de estado en marca blanca?

Algunas herramientas lo permiten. Si dirige una agencia o revende monitoreo y necesita su propio logotipo, sus colores y su dominio frente a los clientes, busque una herramienta hecha para eso. Esa es la parte que cubrimos en monitoreo de disponibilidad de marca blanca, donde cada cliente recibe una página con su marca sin que aparezca el nombre de ningún proveedor.