Cron vs systemd timers: cómo programar tareas en un servidor Linux
Publicado el 2026-10-26 por frfrand
Diferencias entre cron y systemd timers para backups y automatización
Necesitás generar un resumen todas las noches o limpiar archivos temporales una vez por semana. Podés usar cron, pero en Ubuntu moderno también existen los timers de systemd. No es tanto una pelea: importa cuál integra mejor logs, permisos y ejecución de tu servicio.
Te muestro dónde está el problema, cómo comprobarlo sin adivinar y qué haría en una aplicación que de verdad tiene usuarios. No necesitás memorizar un manual entero para resolver un fallo concreto.
Qué significa cron vs systemd timers en la práctica
Cron usa expresiones horarias y corre programas bajo un usuario. Los timers de systemd activan unidades de servicio y ofrecen integración con el journal, dependencias y políticas como Persistent=true para determinadas tareas de calendario que se perdieron mientras el sistema estaba apagado.
Una aclaración antes de tocar el servidor: si el proyecto ya está en producción, guardá el estado que encontraste y comprobá en qué usuario y máquina vas a ejecutar los comandos. Trabajar como root sin necesidad y cambiar varias cosas a la vez dificulta encontrar la causa de un error.
Comandos útiles para empezar
# Ver timers activos
systemctl list-timers --all
# Ver una unidad concreta
systemctl status mi-tarea.timer
journalctl -u mi-tarea.service
# Cron del usuario actual
crontab -l
# Ejemplo de calendar en un timer
# OnCalendar=dailyLas rutas, nombres de unidades y dominios son ejemplos. Adaptalos a tu servicio. Si un comando requiere permisos de administrador, revisá qué cambia y por qué. Las consultas de diagnóstico deberían venir antes de las modificaciones.
Paso a paso, con comprobaciones
- Escribí primero un comando que funcione manualmente y tenga código de salida correcto.
- Si usás cron, definí rutas absolutas: el entorno no es igual al shell interactivo.
- Si usás systemd, separá
mi-tarea.servicedel timer y configurá usuario no privilegiado. - Probá el servicio manualmente antes de activar su timer.
- Verificá hora, zona horaria, logs, política de reintento y riesgo de ejecuciones superpuestas.
Después de cada paso, verificá un resultado observable: un estado, un archivo, una respuesta HTTP o una entrada de log. Si encontrás un mensaje inesperado, guardalo para investigar en lugar de ocultarlo con reinicios repetidos.
Ejemplo real: una aplicación que hay que mantener
Un backend de tours necesita generar un informe diario sin bloquear la API. Un servicio systemd separado con timer permite ver cada ejecución en journalctl y conceder sólo las credenciales que necesita.
Al final, probá el camino completo: entrar por dominio, llamar a la API, escribir un dato de prueba y verificar que la información sigue ahí tras un reinicio controlado. Un servidor que «arranca» no siempre es una aplicación que funciona.
Errores que vale la pena evitar
Un timer no convierte automáticamente una tarea en idempotente. Si corrés dos veces un cargo o un email masivo, necesitás proteger la lógica de negocio.
También es importante que las credenciales no terminen en el historial de la terminal, logs, archivos compartidos o capturas. Para usuarios y servicios, usá permisos mínimos y documentá quién puede revocar el acceso.
Cómo entra ArduMaker en este escenario
ArduMaker permite administrar tareas programadas en VPS. Registrar el comando, responsable, horario y resultado ayuda a saber si un informe realmente se ejecutó.
ArduMaker puede ayudarte a administrar los VPS, desplegar repositorios y trabajar con servicios, bases y dominios desde la misma plataforma. No reemplaza lo que acabamos de explicar sobre Linux: precisamente por eso conviene entender el diagnóstico y tener una forma de repetirlo.
Cuándo conviene automatizarlo
Si la tarea se repite, documentá primero el procedimiento manual y sus comprobaciones. Después considerá un script o una tarea programada con errores visibles, logs y permisos limitados. No automatices un comando que todavía no sabés recuperar cuando sale mal.
Preguntas habituales
¿Puedo probarlo sin afectar clientes? En muchos casos sí: un VPS de staging o un servicio de prueba separado permite validar la configuración antes de cambiar producción.
¿Cómo sé si quedó bien? Mirá logs y una operación funcional, no solamente que el comando terminó con código cero.
¿Cuándo necesito más recursos? Cuando las métricas indiquen saturación de CPU, RAM, disco o conexiones. Un fallo de configuración rara vez se arregla contratando más memoria.
Referencias
En una frase: primero entendé el error, después cambiá una cosa concreta y comprobá su efecto. Esa disciplina te ahorra muchas horas de soporte.