Definición
Una tarea programada es un proceso que el servidor ejecuta solo, a una hora fija y sin que nadie lo lance: sincronizar con el banco a las 7:00, mandar recordatorios los lunes, hacer la copia cada noche.
En sistemas tipo Unix, la herramienta clásica se llama cron, y su nombre se usa como sinónimo.
Programarlas es fácil. Lo difícil es enterarte el día que dejan de ejecutarse, que es de lo que va la mitad de este artículo.
Cómo se lee un cron
Cinco campos, siempre en el mismo orden:
┌─── minuto (0-59)
│ ┌─── hora (0-23)
│ │ ┌─── día del mes (1-31)
│ │ │ ┌─── mes (1-12)
│ │ │ │ ┌─── día de la semana (0-6, domingo = 0)
│ │ │ │ │
0 7 * * * → todos los días a las 7:00
*/15 * * * * → cada 15 minutos
0 3 * * 1 → los lunes a las 3:00
0 0 1 * * → el día 1 de cada mes
El asterisco significa «cualquiera». La barra, «cada tantos».
El problema de verdad: el fallo silencioso
Una tarea programada que funciona no dice nada. Una que falla, tampoco.
Esa simetría es lo que la hace peligrosa: el sistema parece estar bien durante semanas mientras la sincronización no se ejecuta, las copias no se hacen o los avisos no salen. Nadie lo nota hasta que alguien busca un dato que debería estar y no está.
La solución no es mirar los logs de vez en cuando —nadie lo hace— sino darle la vuelta a la señal:
Aviso por ausencia (dead man's switch). En vez de avisar cuando falla, la tarea avisa cada vez que termina bien, y hay un vigilante que salta si ese aviso no llega a su hora. Así el silencio deja de ser tranquilizador y pasa a ser la alarma.
Marca de última ejecución. Guardar en base de datos la fecha del último éxito y mostrarla en el panel. Si pone «hace 9 días», salta a la vista sin buscarlo.
Es la diferencia entre «¿me habrá avisado si fallaba?» y «sé cuándo funcionó por última vez».
Las reglas que evitan la mayoría de disgustos
Que sea idempotente. Si se ejecuta dos veces, no debe duplicar nada. Los solapamientos pasan. Ver idempotencia.
Que no se solape consigo misma. Una tarea cada 5 minutos que tarda 7 acaba con varias corriendo a la vez. Se resuelve con un fichero de bloqueo que la segunda instancia respeta.
Rutas absolutas siempre. El cron no arranca en el directorio que crees.
Su propio entorno. Cron no hereda tus variables de entorno ni tu PATH. Es la causa número uno de «funciona a mano y falla programado».
Cuidado con la zona horaria. Un servidor en UTC ejecuta a las 7:00 UTC, que en España son las 8:00 o las 9:00 según la época del año.
Escalonar las horas. Si todo se lanza a las 0:00, todo compite por los mismos recursos.
Ejemplo práctico
En un sistema de gestión, las tareas programadas sostienen media operativa: sincronizar el banco, avisar de pedidos pendientes, recalcular indicadores, mandar recordatorios.
Lo que aprendí, por las malas: la que más daño hace al fallar no es la que da error, es la que se ejecuta y no hace nada. Una sincronización cuyo token caducó puede seguir corriendo puntualmente cada día, devolver cero registros y terminar «con éxito». El cron está verde, el log no dice nada raro y los datos llevan un mes congelados.
De ahí la regla que aplico: la tarea no informa de que se ejecutó, informa de qué hizo. «Sincronización OK» no vale; «Sincronización OK · 0 movimientos nuevos» sí, porque un cero repetido durante días es visible.
Y la segunda lección: si al programarla nadie anota qué hace y cada cuánto, dentro de un año habrá una tarea corriendo que nadie se atreve a tocar. Un fichero con la lista —qué, cuándo, por qué y qué pasa si no corre— vale más de lo que parece.
Errores comunes
- Programarla y no vigilarla.
- Confiar en que avise si falla. El silencio es indistinguible del éxito.
- Rutas relativas.
- Suponer que hereda tu entorno.
- Ignorar la zona horaria del servidor.
- Que no sea idempotente y duplique al solaparse.
- Meter la lógica dentro del cron en vez de en un script que también se pueda lanzar a mano. Si no puedes ejecutarla manualmente, no puedes depurarla.
- No registrar la última ejecución con éxito en un sitio visible.
Cuándo usarlas
Para todo lo que deba ocurrir a una hora concreta sin que nadie esté delante: sincronizaciones, copias, avisos, informes, limpiezas.
Y una advertencia de diseño: si algo tiene que ocurrir en respuesta a un evento, un cron es la herramienta equivocada. Para eso están los webhooks y las colas. El cron es para el reloj, no para las reacciones.
