Una comprobación de uptime tira: un servicio de monitorización envía una petición a tu web o API según un calendario y te avisa cuando la respuesta es incorrecta o no llega. Un heartbeat empuja: tu tarea o servicio envía una petición al servicio de monitorización cada vez que se ejecuta, y la alerta salta cuando esa petición no llega. Usa comprobaciones de uptime para todo lo que la gente alcanza por la red, y heartbeats para el trabajo que se ejecuta de forma programada o que no tiene dirección pública. La mayoría de los entornos necesitan ambos.
Es fácil confundirlos porque los dos acaban en «avisar cuando algo va mal». Pero ven fallos distintos, y usar uno donde necesitas el otro deja un punto ciego que solo aparece cuando algo se rompe.
Cómo funciona una comprobación de uptime
El servicio de monitorización es el cliente. Cada minuto, o con el intervalo que elijas, solicita una URL, hace ping a un host o abre un puerto, y evalúa la respuesta: el código de estado, el tiempo de respuesta, una palabra clave en la página, el certificado. Si la comprobación falla y una segunda comprobación lo confirma, recibes una alerta. Es una forma de monitorización sintética: un robot hace lo que haría un visitante.
Detecta: una web o API caída, lenta, que responde con errores, que muestra el contenido equivocado o que ha dejado de funcionar por un certificado caducado o un cambio de DNS. Todo aquello con lo que se toparía un visitante.
Se le escapa: todo lo que no responde a peticiones. Una copia de seguridad que no se ejecutó, un worker de cola que se quedó colgado, una importación que falló a las 02:00. La web sigue activa, así que todas las comprobaciones pasan.
Cómo funciona un heartbeat
Tu tarea es el cliente. Indicas al servicio de monitorización cuándo debe ejecutarse la tarea, y la tarea llama a una URL de ping única al terminar. Si el ping se retrasa más allá del periodo de gracia que elijas, recibes una alerta. La idea es la de un interruptor de hombre muerto: el silencio es la señal. Por eso la monitorización heartbeat también se llama monitorización push o monitorización de hombre muerto (dead man’s switch).
0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 –retry 3 -o /dev/null https://app.uptimecheck.com/api/hb/your-token
Detecta: tareas que no arrancaron, que fallaron antes de terminar, que se ejecutaron con el calendario equivocado o, con un ping de inicio, que tardaron demasiado. Si el ping incluye el código de salida, también detecta tareas que se ejecutaron y fallaron.
Se le escapa: si alguien puede acceder a tu servicio. Una tarea en un servidor puede seguir enviando pings tan tranquila mientras la web de ese mismo servidor responde 502 a todos los visitantes.
Comparativa
Comprobación de uptimeHeartbeatQuién envía la peticiónEl servicio de monitorizaciónTu tarea o servicioAlerta cuandoLa respuesta es incorrecta, lenta o no llegaEl ping se retrasa o informa de un falloNecesita dirección públicaSíNo, solo HTTPS salienteConfiguraciónUna URL, un host o un puertoUn calendario, un periodo de gracia y una petición en la tareaVeLo que experimentan los visitantes y los clientes de la APISi el trabajo en segundo plano se ejecutó y cómo terminóNo veEl trabajo que no responde a peticionesSi alguien puede acceder al servicio
Cuándo usar una comprobación de uptime
Tu página de inicio y las páginas que generan ingresos: pago, registro, inicio de sesión.
API públicas y receptores de webhooks, comprobando el código de estado y el JSON que devuelven.
Un endpoint de health check que pruebe la base de datos y otras dependencias en cada petición.
Servicios en otros puertos, como un servidor de correo, con una comprobación de puerto.
La regla general: si lo llama una persona u otro sistema, compruébalo desde fuera, igual que lo hacen ellos.
Cuándo usar un heartbeat
Cron jobs: copias de seguridad de bases de datos y archivos, importaciones y exportaciones nocturnas, generación de informes, procesos de facturación.
Tareas programadas en otros formatos: una tarea programada de Windows, un CronJob de Kubernetes, un workflow de GitHub Actions con calendario, una función serverless con temporizador.
Scripts de renovación de certificados y sincronizaciones de datos entre sistemas.
Cualquier cosa detrás de un firewall o NAT a la que no se pueda acceder desde fuera, pero que pueda hacer una petición HTTPS saliente.
Workers de larga duración
Un worker de cola o un daemon no se ejecuta según un calendario, pero también puede enviar un heartbeat. Envía un ping desde el bucle principal cada pocos minutos y configura el monitor con un intervalo en lugar de una expresión cron. Si el bucle se cuelga, el proceso muere o el servidor se reinicia sin volver a lanzarlo, los pings se detienen y te enteras. Envía el ping desde el bucle que hace el trabajo, no desde un hilo aparte, o un worker atascado seguirá diciendo que todo va bien.
Cuándo necesitas ambos
La mayoría de los servicios reales tienen una puerta de entrada y una trastienda. Monitoriza cada una con la herramienta que la ve:
Una tienda online: comprobaciones de uptime en la página de inicio y en el pago, y heartbeats en la exportación nocturna de pedidos y en la copia de seguridad de la base de datos.
Un producto SaaS: una comprobación de uptime en el endpoint de salud de la API, y heartbeats en el worker de cola y en la tarea que envía las facturas.
Un servicio interno: sin dirección pública, así que un heartbeat desde el propio servicio, más comprobaciones de uptime en las páginas públicas que dependen de sus datos.
Una alternativa es exponer el estado de las tareas a través del endpoint de salud, por ejemplo haciendo fallar la comprobación cuando la última copia de seguridad tiene más de 25 horas. Funciona, pero ata el uptime de tu web a tus copias de seguridad, de modo que una copia retrasada aparece como caída de la web en tus informes. Un heartbeat independiente mantiene separadas las dos señales, y a las personas que reciben cada alerta.
Cómo ajustar los tiempos
Intervalo de la comprobación de uptime: cada minuto para las páginas que generan ingresos, ya que el intervalo es el tiempo máximo que puedes pasar sin enterarte de una caída. Las páginas menos críticas pueden usar un intervalo más largo.
Periodo de gracia del heartbeat: más largo que la variación normal de la hora a la que termina la tarea. Una copia de seguridad que empieza a las 03:00, tarda entre 5 y 20 minutos y envía el ping al final necesita al menos 20 minutos de gracia; con 30 queda margen para una noche lenta.
Tiempo máximo de ejecución: con un ping de inicio, avisa cuando una ejecución tarda mucho más de lo habitual. Una tarea colgada tampoco envía nunca su ping final, pero esta alerta llega en cuanto se supera el límite.
Zona horaria: un calendario cron se ejecuta en la zona horaria del servidor, a menudo UTC. Configura el monitor con la misma, o el cambio de horario hará que espere la tarea una hora antes o después dos veces al año. La herramienta de expresiones cron muestra cuándo se ejecuta realmente un calendario.
Errores habituales
Enviar el ping solo al principio. Una tarea que arranca y falla sigue dando señales de vida. Envía el ping al final, o ambos.
Enviar el ping aunque la tarea falle. backup.sh; curl … envía el ping pase lo que pase. Usa &&, o envía el código de salida para que un fallo se notifique como tal.
Un ping que puede colgar la tarea. Dale a curl un tiempo de espera y reintentos (-m 10 –retry 3), para que una red lenta ni bloquee la tarea ni haga perder el ping.
Usar un heartbeat para una web pública. Un servidor que envía pings hacia fuera solo demuestra que puede llegar a internet, no que los visitantes puedan llegar a él.
Monitorizar el daemon de cron en lugar de la tarea. El daemon puede funcionar sin problemas mientras una tarea falla cada noche. Cada tarea importante necesita su propio heartbeat.
Más sobre la parte de los heartbeats en cómo monitorizar cron jobs y cómo evitar tareas cron que no se ejecutan.
Ambos en un solo lugar con Uptimecheck
Uptimecheck ejecuta los dos tipos de monitor en la misma cuenta, con los mismos canales de alerta y el mismo historial de incidencias.
Monitorización de uptime: comprobaciones HTTP(S), de ping y de puerto hasta cada minuto desde Estocolmo, Londres y Nueva York, con cada fallo confirmado desde una segunda ubicación antes de avisar. Las comprobaciones HTTP pueden verificar el código de estado, una palabra clave, campos JSON y cabeceras.
Monitorización de cron jobs: una expresión crontab en tu zona horaria, cambio de horario incluido, o un intervalo simple; un periodo de gracia de 1 minuto a 6 horas; pings /start con un tiempo máximo de ejecución de 1 minuto a 24 horas; /fail o el código de salida para indicar cómo terminó una ejecución; y la salida de la tarea, enviada con el ping, mostrada en la alerta.
Límites: Start incluye 15 monitores de uptime y 10 cron jobs, Professional 100 y 50, Business 250 y 150. Consulta los precios.
Para configurarlo, consulta cómo monitorizar un cron job con un heartbeat y los ejemplos de ping para cron jobs para Laravel, Kubernetes, GitHub Actions, systemd y Windows. Para el disco y la memoria del servidor que hay debajo, añade la monitorización de servidores.
Vigila la puerta de entrada y la trastienda. Prueba Uptimecheck gratis durante 14 días, sin tarjeta de crédito.