Monitorización Heartbeat

Tus crons están fallando.
En silencio.

Un heartbeat check es un interruptor de hombre muerto para tus tareas programadas. Tu job hace ping a una URL cuando termina. Si el ping nunca llega — proceso caído, servidor reiniciado, job bloqueado — SteadyCron te despierta.

Empezar gratis Leer la documentación

Plan gratuito — sin tarjeta de crédito.

Sin heartbeat check

# /etc/cron.d/backup
0 2 * * * root /usr/bin/backup.sh

# Output: none.
# Exit code: who knows.
# Last successful run: unclear.
# Will anyone notice? No.

Con un heartbeat check

# /etc/cron.d/backup
0 2 * * * root /usr/bin/backup.sh \
  && curl -fsS https://ping.steadycron.com/abc123

✓ 02:04 — ping recibido, job en buen estado
✗ 03:02 — sin ping — alertando #ops-slack

El problema

Fire-and-forget no es una estrategia de monitorización

Cron no tiene ningún concepto incorporado de éxito o fracaso. Un job se ejecuta, produce una salida que nadie lee, y termina — y el planificador considera su trabajo hecho independientemente. Para cuando notas que algo salió mal, los logs están rotados, la ventana se ha cerrado y el daño está hecho.

El backup nocturno falló en silencio. Los datos se han perdido.
El job de facturas no se ejecuta desde hace tres días. El equipo de finanzas lo notó primero.
Un script se quedó bloqueado e impidió el siguiente run — durante seis horas.
El proceso fue terminado por OOM. Los logs ya están rotados.

Una cronología típica de un fallo de cron

02:00

Job programado

02:00

Proceso iniciado

02:03

Disco lleno — script sale con 1

02:03

Salida: ninguna (redirigida)

03:00

Rotación de logs

09:14

El ingeniero abre el dashboard

09:14

Sin errores visibles en ningún sitio

14:30

El cliente reporta pérdida de datos

12 horas entre el fallo y su descubrimiento.

Cómo funciona

El silencio es la señal

No nos envías datos — lo hace tu job. Si se detiene, lo sabemos.

01

Tu job hace ping a una URL

Después de que tu script se ejecuta, llama a una URL de ping única — nada más que un simple HTTP GET. Pasa /start antes, /success después y opcionalmente /fail en caso de error.

curl -fsS https://ping.steadycron.com/{id}

02

Abrimos una ventana de gracia

SteadyCron conoce tu horario y permite un período de gracia configurable para absorber el jitter normal — ventanas de mantenimiento nocturno, picos de carga del servidor y desviación del horario.

grace: 10m # no alert if ping arrives within 10 min

03

El silencio dispara una alerta

Si el ping no llega antes de que expire el período de gracia, se envía una alerta a tu canal configurado — Slack, email, Telegram, Discord o webhook.

→ #ops-slack nightly-backup missed (14 h overdue)

Lo que detectamos

Tres formas en que un job puede fallar

Cada tipo de fallo es distinto, detectable y genera alertas de forma independiente.

nightly-backup MISSED

Run fallido

El job nunca comenzó. El proceso fue terminado, el servidor se reinició, o el planificador lo saltó. Ningún ping llegó — ni siquiera un /fail.

Esperado a las 02:00 UTC

Último ping ayer 02:04

Retraso de 14 h 22 min

Detectado cuando: ningún ping /start o /success llega dentro del período de gracia del horario esperado.

invoice-sender FAILED

Job fallido

El job se ejecutó pero salió con código no cero, o tu código capturó una excepción y llamó explícitamente al endpoint /fail antes de retornar.

...
$ python invoice.py
ConnectionError: DB unreachable
→ /fail ping sent
Alerted: #billing-alerts

Detectado cuando: tu código llama al endpoint /fail, o el job termina sin un ping /success.

report-generator TIMED OUT

Job bloqueado

El job comenzó — se recibió /start — pero nunca envió /success. Sigue ejecutándose, o está en un deadlock silencioso. Un umbral de duración máxima lo detecta.

/start recibido 09:00:12

Duración máxima 30 min

/success recibido nunca

Detectado cuando: se recibió un /start pero /success o /fail nunca llega dentro de la duración máxima configurada.

Integración

Una línea. Cualquier lenguaje.

Sin SDK que instalar, sin agente que desplegar. Un HTTP GET es la integración. Funciona desde un script de shell, una lambda de Python, un binario de Go o un Kubernetes CronJob.

# Minimal — one line at the end of your crontab command
0 2 * * * /usr/bin/backup.sh && curl -fsS https://ping.steadycron.com/abc123

# With start/fail signals (recommended)
0 2 * * * curl -fsS https://ping.steadycron.com/abc123/start \
  && /usr/bin/backup.sh \
  && curl -fsS https://ping.steadycron.com/abc123 \
  || curl -fsS https://ping.steadycron.com/abc123/fail

import requests, subprocess, sys

PING = "https://ping.steadycron.com/abc123"

requests.get(f"{PING}/start", timeout=5)
result = subprocess.run(["/usr/bin/backup.sh"])

if result.returncode == 0:
    requests.get(PING, timeout=5)
else:
    requests.get(f"{PING}/fail", timeout=5)
    sys.exit(result.returncode)

const PING = "https://ping.steadycron.com/abc123";

await fetch(`${PING}/start`);
try {
  await runMyJob();
  await fetch(PING);             // success
} catch (err) {
  await fetch(`${PING}/fail`);   // explicit failure
  throw err;
}

const ping = "https://ping.steadycron.com/abc123"

http.Get(ping + "/start")

if err := runMyJob(); err != nil {
    http.Get(ping + "/fail")
    log.Fatal(err)
}

http.Get(ping) // success

require "net/http"
PING = "https://ping.steadycron.com/abc123"

Net::HTTP.get(URI("#{PING}/start"))
begin
  run_my_job
  Net::HTTP.get(URI(PING))          # success
rescue => e
  Net::HTTP.get(URI("#{PING}/fail"))
  raise
end

https://ping.steadycron.com/abc123";

file_get_contents(PING . "/start");
try {
    run_my_job();
    file_get_contents(PING);          // success
} catch (\Throwable $e) {
    file_get_contents(PING . "/fail");
    throw $e;
}

La URL de ping se genera cuando creas el check — cópiala en tu script. ¿Prefieres definir los monitores como código? Decláralos en YAML o Terraform.

Alertas inteligentes · Períodos de gracia

No todo retraso es un fallo

Los horarios son aspiracionales. La carga del servidor, las ventanas de mantenimiento nocturno y el manejo de segundos intercalares empujan los jobs unos minutos más allá de su hora programada. Un período de gracia absorbe este jitter normal para que solo te avisen cuando algo está genuinamente mal.

Configúralo por check — un ping de salud rápido de 5 minutos podría usar una gracia de 2 minutos; un ETL nocturno pesado que a veces tarda 20 minutos podría usar 30.

Período de gracia en acción

02:00

Ping esperado

02:06

Ping recibido (6 min tarde)

dentro del período de gracia de 10 min — sin alerta

03:00

Ping esperado

03:11

Sin ping (11 min tarde)

período de gracia expirado — alertando

grace: 600 # seconds — 10 minutes

Alertas inteligentes · Reducción de ruido

Diseñado para reducir el ruido, no añadirlo

La fatiga por alertas es real. SteadyCron tiene múltiples mecanismos para mantener tu pager silencioso a menos que algo necesite genuinamente tu atención.

Umbral de fallos consecutivos

Un simple fallo puntual — un breve corte de red, un OOM kill aislado — no debería despertar a tu equipo a las 3 AM. Establece un umbral de N fallos consecutivos antes de que se dispare una alerta. El primer fallo se registra; el tercero dispara la alerta.


alert_after: 3 # alertar solo después de 3 fallos consecutivos

Guard de flapping

Un job que alterna rápidamente entre sano y fallido genera una tormenta de alertas sin señal útil. El guard de flapping detecta esta oscilación y suprime las notificaciones repetidas hasta que el job se estabiliza — una alerta, no veinte.

 # fail → ok → fail → ok → fail
 ⚠ flapping detectado — alerta retenida

Horas de silencio

Marca una ventana de tiempo por check donde los fallos no críticos se suprimen — la alerta se registra pero no se entrega. Cuando tu equipo vuelva a estar en línea, todo lo que ocurrió está en el registro de entrega con su motivo de supresión.


quiet_hours: "22:00–07:00 Europe/Berlin"

Ciclo de vida de una alerta

🔴

nightly-backup fallido

02:14 — alerta enviada a #ops-slack

📋

Alerta suprimida (horas de silencio)

03:00 — fallo siguiente registrado, no enviado

✅

nightly-backup recuperado

02:07 al día siguiente — resuelto automáticamente

🔕

#ops-slack notificado: resuelto

No se necesita confirmación manual

Alertas inteligentes · Resolución automática

Las alertas se resuelven solas

Cuando un job se recupera — el siguiente ping llega con éxito — SteadyCron resuelve automáticamente la alerta abierta y envía una notificación de resolución al mismo canal. Nunca necesitas cerrar manualmente un incidente que ya se ha resuelto solo.

Cada evento de alerta se registra con su disparador, canal de entrega, estado y motivo de supresión si aplica — para que siempre tengas un registro completo de qué se disparó, qué se retuvo y por qué.

Una plataforma, tres trabajos

Ejecución HTTP

Llama a tus endpoints según el horario — reintentos, tiempos de espera y logs completos.

Monitorización heartbeat

Estás aquí

Vigila los jobs que ejecutas donde sea; recibe alerta en cuanto uno se silencia.

Cron as code

Define cada job, monitor y alerta en YAML o Terraform.

Tus jobs deberían decirte que se ejecutaron.

Añade un heartbeat check en dos minutos. Sin agente, sin SDK, sin cambio de infraestructura — solo una URL al final de tu script.

Empezar gratis Leer la documentación

Plan gratuito — sin tarjeta de crédito
Alojado en la UE, RGPD nativo
Cualquier lenguaje, cualquier plataforma