comparativa de herramientas autoalojadas
Uptime Kuma vs. Healthchecks: no hacen el mismo trabajo
Estos dos se comparan constantemente, y la comparación suele partir de una suposición equivocada. Uptime Kuma llama a su servicio para ver si responde. Healthchecks nunca llama a nada: se queda esperando a que su tarea cron lo llame, y se queja cuando la llamada no llega. Todo lo demás se deriva de esa dirección.
La tabla de abajo es la comparación completa, sin editar. Léala primero si lo prefiere: es la misma que le enviaríamos.
AGPL-3.0 · un solo binario · plan gratuito · sin tarjeta
Los datos, frente a frente
| Uptime Kuma | Healthchecks | Uptimepage | |
|---|---|---|---|
| licencia | MIT | BSD-3-Clause | AGPL-3.0 |
| cómo funciona una comprobación | llama a su servicio | su tarea lo llama | en las dos direcciones |
| vigila una URL | sí | nunca | sí |
| tipos de comprobación | 31, incl. BD · MQTT · navegador | solo pings entrantes | HTTP · TCP · DNS · TLS · dominio · ping · heartbeat · flow · manual |
| cron y tareas programadas | monitor push, solo intervalo | cron + OnCalendar de systemd, zonas horarias | heartbeat con periodo + margen, sin calendarios cron |
| duración, código de salida y salida de la tarea | no | sí | sí |
| granularidad más fina | 1 s | periodo de ping de 60 s | 60 s gratis · 30 s Team · 10 s autoalojado |
| página de estado | básica | solo insignias | con su marca, dominio propio en Pro |
| suscriptores de la página | solo RSS | ninguno | correo · webhook |
| integraciones de alerta | 94 servicios | ~28, incl. Signal · Apprise | 14 nativas |
| configuración como código | API de sockets, sin REST | API REST, Terraform de la comunidad | Terraform · REST · MCP |
| equipos y roles | un solo inicio de sesión | proyectos + 4 roles | organizaciones + roles |
| ejecutarlo usted mismo | un contenedor (Node) | un contenedor (Django, SQLite) | un binario + compose |
| opción alojada | no | sí, 20 comprobaciones gratis | sí, plan gratuito |
| comunidad (estrellas en GitHub) | ~89k | ~10k | joven |
Healthchecks nunca hace una petición a su servicio; es su servicio el que tiene que hacerle una petición a él. No puede decirle que un sitio web está caído, por diseño.
El monitor push de Uptime Kuma cubre el caso sencillo del dispositivo de hombre muerto. Healthchecks es el único aquí con calendarios cron y OnCalendar de systemd con zonas horarias; un heartbeat que solo conoce un periodo no puede saber que una tarea nocturna se ejecutó a la hora equivocada.
El proveedor de Terraform de Healthchecks lo mantiene la comunidad; no es oficial.
Verificado en julio de 2026 con Uptime Kuma 2.4.0 y Healthchecks v4.2. Los dos proyectos avanzan rápido, así que consulte su código fuente actual antes de decidir.
Uno lo llama a usted, el otro espera su llamada
Uptime Kuma es un monitor activo. Envía la petición, lee la respuesta y decide. Healthchecks es un dispositivo de hombre muerto: su script de copia de seguridad, su tarea cron o su informe nocturno hace ping a una URL cuando termina, y Healthchecks alerta cuando un ping llega tarde o no llega. Eso significa que Healthchecks nunca podrá decirle que su sitio web está caído, y es así por diseño, no por descuido. Si su tarea cron sigue enviando pings tan tranquila mientras su sitio devuelve errores 500, Healthchecks sigue en verde.
En qué Healthchecks es de verdad el mejor
En saber si una tarea programada se ejecutó, y si lo hizo correctamente. Acepta expresiones cron y calendarios OnCalendar de systemd con zonas horarias, así que alerta cuando una tarea no se ejecutó a la hora correcta, y no solo cuando ha pasado un intervalo. Señale un inicio y un final y obtiene la duración; haga ping al endpoint de fallo y obtiene el código de salida; envíe un cuerpo y guarda la salida de la tarea junto al ping. Nada en la categoría del monitoreo de disponibilidad hace eso bien. Tiene licencia BSD, se ejecuta como un solo contenedor sobre SQLite y su plan alojado gratuito ofrece 20 comprobaciones para siempre.
En qué Uptime Kuma es de verdad el mejor
Amplitud e inmediatez. La línea 2.x cubre 31 tipos de monitor, incluidas bases de datos, MQTT, SNMP, gRPC y una comprobación con un navegador Chromium real, envía notificaciones a 94 servicios distintos y baja su intervalo mínimo a un segundo. Es un solo contenedor y se instala en cinco minutos. También tiene un monitor push, que es un dispositivo de hombre muerto sencillo, y ese solapamiento es la razón por la que la gente se hace esta pregunta.
El solapamiento, y dónde deja de servir
El monitor push de Kuma resuelve el caso fácil: algo debe reportarse cada N minutos; avíseme cuando deje de hacerlo. Recurra a Healthchecks cuando lo que le importa es el propio horario, porque un monitor push entiende un intervalo y nada más. No sabe que su tarea debe ejecutarse a las 03:00 en Europe/Helsinki, no le dirá que la ejecución tardó nueve minutos cuando suele tardar dos y no le guardará el stack trace de la tarea que falló. En sentido contrario, Healthchecks nunca vigilará una URL. Muchos equipos usan los dos, y es una respuesta razonable, no una evasiva.
Dónde encaja Uptimepage
Uptimepage cubre las dos direcciones. Sondea por HTTP, TCP, DNS, TLS, caducidad de dominio, ping y flujos de navegador, y recibe heartbeats de tareas que no tienen nada que sondear, con un periodo, un margen, un tiempo máximo de ejecución, y el código de salida y la salida de la ejecución que falló. Lo que no lee es una expresión cron, así que, si la pregunta es si la tarea de anoche se ejecutó a la hora correcta en la zona horaria correcta, Healthchecks lo hace mejor que nosotros. Lo que Uptimepage añade a ambos es la parte que ninguno de los dos cubre: los clientes. Una página de estado con su marca en su propio subdominio, suscriptores por correo confirmado y webhook, incidentes que se abren automáticamente a partir de comprobaciones fallidas, organizaciones con roles en lugar de un único inicio de sesión compartido, y un proveedor de Terraform, una API REST y un servidor MCP. Alojado gratis sin tarjeta, o autoalojado bajo AGPL.
- 01Inicie sesión con GitHub o Google. Sin tarjeta, sin llamada comercial.
- 02Pegue una URL. La primera comprobación se ejecuta antes de que termine de leer esto.
- 03Publique la página de estado, o expórtela a Terraform y guárdela en Git.
api99,98 %
p95 142 ms · un incidente en 45 días
dashboard99,91 %
p95 318 ms · dos días degradados
webhooks99,99 %
p95 88 ms · sin incidentes
RESUELTO14 min
Latencia elevada en la API del panel
14:22 resuelto, latencia de nuevo por debajo de 300 ms
14:08 abierto automáticamente por la comprobación del panel
activo degradado caído 45 días · suscriptores por correo y webhook