Una tarea cron que falla silenciosamente es peor que una tarea cron que no existe.
Si tu respaldo nocturno de base de datos dejo de ejecutarse hace tres dias y nadie lo noto, no tienes un sistema de respaldo. Tienes una responsabilidad. Toda la propuesta de valor de un servicio cron gestionado colapsa si los fallos pasan desapercibidos, lo que significa que las notificaciones no son una funcionalidad -- son el producto.
Cuando disenamos 0cron.dev, hicimos una pregunta simple: donde reciben realmente los desarrolladores las alertas? La respuesta, en 2026, es en todas partes. Algunos equipos viven en Slack. Otros usan Discord. Desarrolladores independientes revisan Telegram en sus telefonos. Equipos empresariales tienen PagerDuty u Opsgenie conectados a endpoints webhook. Y el email, a pesar de anos de predicciones sobre su muerte, sigue siendo el respaldo universal.
Asi que construimos cinco canales de notificacion. Y hicimos cada canal independientemente configurable con filtros por evento, porque recibir un mensaje de Slack por cada verificacion de salud exitosa es la forma mas rapida de hacer que alguien desactive las notificaciones por completo.
Este articulo cubre el servicio de notificaciones de 296 lineas, el sistema de despacho por canal, y las decisiones de diseno detras de cada integracion.
El NotificationService: una estructura, cinco canales
El sistema de notificaciones esta centrado en una unica estructura que contiene la configuracion SMTP y expone metodos para cada canal:
rustpub struct NotificationService {
smtp_host: String,
smtp_port: u16,
smtp_username: String,
smtp_password: String,
smtp_from: String,
}El bucle de despacho: como se envian las notificaciones
Cuando una ejecucion de tarea se completa -- ya sea que tenga exito o falle -- el ejecutor llama a send_job_notifications(). Tres cosas destacan en este bucle de despacho:
Filtrado por canal. Cada canal tiene sus propios flags enabled, on_success y on_failure. Un usuario puede querer notificaciones por email solo en fallos, notificaciones Slack en exito y fallo, y webhook en todo.
Fallo gracil. El bucle de despacho no cortocircuita en errores. Si el webhook de Slack esta mal configurado pero el email SMTP funciona bien, el usuario igual recibe su notificacion por email.
Sin fan-out asincrono. Enviamos notificaciones secuencialmente, no en paralelo. El despacho secuencial con timeouts cortos (5 segundos por canal) es mas simple y predecible.
Slack: Block Kit para mensajes enriquecidos
Usamos el formato Block Kit de Slack, que estructura mensajes en bloques visuales con encabezados, secciones y elementos de contexto. La barra de color vertical (verde para exito, rojo para fallo) es lo que produce el triaje visual instantaneo.
Telegram: el canal movil-primero
Telegram es particularmente popular entre desarrolladores independientes y equipos pequenos, especialmente en nuestro mercado objetivo de desarrolladores en Africa y Sudeste Asiatico. Usamos parse_mode: "HTML" en lugar de Markdown porque el renderizado HTML de Telegram es consistente entre versiones.
Webhooks: la via de escape
Los webhooks son el canal mas poderoso y menos opinionado. Mientras los otros cuatro canales envian mensajes legibles por humanos, el canal webhook envia JSON estructurado con el payload completo de ejecucion. El encabezado User-Agent: 0cron-webhook/1.0 permite a los receptores identificar solicitudes de 0cron.
La configuracion de notificaciones: por canal, por evento
json{
"email": {
"enabled": true,
"target": "[email protected]",
"on_success": false,
"on_failure": true
},
"slack": {
"enabled": true,
"target": "https://hooks.slack.com/services/T00/B00/xxxxx",
"on_success": true,
"on_failure": true
},
"discord": {
"enabled": false,
"target": "",
"on_success": false,
"on_failure": false
},
"telegram": {
"enabled": true,
"target": "123456789:AAF...:987654321",
"on_success": false,
"on_failure": true
},
"webhook": {
"enabled": true,
"target": "https://api.example.com/0cron-events",
"on_success": true,
"on_failure": true
}
}Los flags on_success y on_failure son la perspicacia de diseno clave. La mayoria de los sistemas de notificacion son binarios: activado o desactivado. Pero las tareas cron son diferentes de los errores de aplicacion. Una tarea que se ejecuta 1,440 veces al dia y tiene exito cada vez generaria 1,440 notificaciones de exito. Nadie quiere eso.
El filtrado por evento resuelve esto elegantemente. La configuracion comun es on_success: false, on_failure: true -- silencio en exito, alerta en fallo.
Las notificaciones son fire-and-forget por diseno. Si un webhook de Slack devuelve un error 500, lo registramos y seguimos adelante. El registro autoritativo de una ejecucion de tarea es el log de ejecucion en la base de datos, no el mensaje de Slack.
Esta es la Parte 5 de una serie de 10 partes sobre la construccion de 0cron.dev.