Programar tareas en Linux con cron y at: guía práctica y completa

Automatizar tareas en Linux es una de esas cosas que, cuando las incorporas a tu rutina, ya no hay vuelta atrás: backups puntuales, limpiezas periódicas, informes, avisos por correo o programar mensajes en Telegram… todo ocurre solo sin que tengas que estar pendiente. En este artículo te cuento, con detalle y sin rodeos, cómo dominar cron y at para ejecutar tareas recurrentes o únicas en el momento exacto que te interese.

Además de abarcar la práctica esencial, integraremos trucos, seguridad, sintaxis completa, convenciones de tiempo, gestión de colas, logs, control de entorno y alternativas cuando tu máquina no está siempre encendida. También verás herramientas para escribir expresiones cron sin pelearte con la sintaxis y algunos consejos para no saturar tu sistema ni tu red con automatizaciones mal planificadas.

Qué son cron y at, y cuándo usar cada uno

En pocas palabras, cron es el demonio encargado de ejecutar trabajos programados y recurrentes (cada hora, cada día, cada semana, etc.), mientras que at sirve para agendar una sola ejecución en el futuro. Ambos viven en casi cualquier sistema Unix o GNU/Linux y son un pilar de la administración de sistemas.

Bajo el capó, cron monitoriza periódicamente las reglas definidas en crontabs (tablas de cron) y lanza los comandos cuando coincide la fecha/hora; por su parte, at delega la ejecución real en el servicio atd (o atrun según la distro) y preserva el entorno de ejecución del momento en que programas la tarea, lo que viene genial para scripts sensibles a variables.

Programación periódica con cron

En un sistema típico, muchas tareas de mantenimiento ya dependen de cron: rotación de logs, actualización del índice de locate, copias de seguridad, limpiezas de temporales y más. En Debian y derivadas verás, además, directorios estándar pensados para simplificar la vida al administrador: /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/ y /etc/cron.monthly/.

Por defecto, cada usuario puede tener su propio crontab. Para editarlo, ejecuta crontab -e. El contenido se guarda en /var/spool/cron/crontabs/usuario y no deberías editar ese fichero a mano. El usuario root, además de su crontab, puede programar en /etc/crontab o dejar «fragmentos» en /etc/cron.d/; en estos crontab del sistema se añade un campo extra para indicar con qué usuario se ejecuta cada tarea.

La estructura de una línea significativa del crontab de usuario tiene 5 campos de tiempo más el comando. En /etc/crontab y /etc/cron.d/ aparece un sexto campo con el usuario. Los campos son, en orden: minuto (0–59), hora (0–23), día del mes (1–31), mes (1–12) y día de la semana (0–7 donde 0 y 7 son domingo; también se pueden usar abreviaturas en inglés: Sun, Mon, etc.).

# crontab de usuario (5 campos + comando)
# m h dom mon dow   comando
0 3 * * * /ruta/al/script.sh

# /etc/crontab o /etc/cron.d/ (6 campos: incluye usuario)
# m h dom mon dow   usuario   comando
0 3 * * * backup    /usr/local/bin/backup.sh

La sintaxis admite listas separadas por comas (1,15,30), rangos (1-5), e incrementos con la barra (*/10 o 0-50/10). El asterisco representa «todos los valores». Por ejemplo, */15 en el campo de minuto significa «cada 15 minutos», y 0-10/2 equivale a 0,2,4,6,8,10.

# Ejemplos útiles
*/10 * * * * /usr/local/bin/tarea_cada_10_min
0 0 * * 0 /usr/local/bin/mantenimiento_semanal
30 2 1 * * /usr/local/bin/rotacion_mensual
0 6 * * Mon-Fri /usr/local/bin/reporte_laboral

Además de lo anterior, cron soporta cadenas especiales muy prácticas: @reboot, @hourly, @daily (@midnight es equivalente), @weekly, @monthly, @yearly (o @annually). Úsalas para evitar expresiones largas cuando no aportan nada.

@reboot /usr/local/bin/lanzar_al_arranque.sh
@hourly /usr/local/bin/tarea_cada_hora.sh

Un clásico que no falla: cron no hereda el entorno de tu shell interactiva. Si tu script depende de variables o de un PATH extendido, defínelas al principio del crontab, o en el propio script. Puedes usar MAILTO para recibir salidas y errores por correo local o externo.

# Variables de entorno en crontab
env_reset
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAILTO=tu.correo@ejemplo.com
HOME=/home/usuario

Para manejar tu crontab de usuario, estos comandos te hacen la vida fácil: crontab -e (editar), crontab -l (listar), crontab -r (eliminar), y crontab archivo (reponer desde un fichero). Si administras un servidor multiusuario, añade -u usuario para operar sobre crontabs ajenos con permisos de root.

# Copia de seguridad y restauración del crontab de usuario
crontab -l > ~/crontab_backup.txt
crontab ~/crontab_backup.txt

Tareas puntuales con at

Hay situaciones en las que solo necesitas que algo pase una vez: apagar el equipo a una hora, lanzar una copia única, mandar un recordatorio o disparar una actualización en ventana de mantenimiento. Para eso, la pareja at/atd es la adecuada.

La sintaxis de at es flexible con el tiempo y la fecha: acepta formatos europeos y estadounidenses, horas en 24h o 12h (4pm), andamiajes como today o tomorrow y, además, «ahora + incremento». Escribe los comandos por la entrada estándar y termina con Ctrl+D (EOF).

# Ejecutar a las 14:00 de hoy (o mañana si ya pasó)
at 14:00
comando_1
comando_2
<Ctrl+D>

# Ejecutar a las 09:00 el 27 de julio de 2022 (varios formatos válidos)
at 09:00 27.07.22
at 09:00 2022-07-27
at 9am 07/27/2022

# Postergar X unidades desde ahora
at now + 30 minutes
at now + 2 hours
at now + 1 days
at now + 2 weeks

Cuando programas, at te devuelve el número de trabajo y la fecha/hora de ejecución previstas. Ese ID lo usarás para listar, inspeccionar o cancelar. La cola se consulta con atq y los trabajos se eliminan con atrm. Si quieres ver el contenido y el entorno capturado, usa at -c ID.

# Operaciones básicas con la cola de at
atq            # ver trabajos del usuario (root ve todos)
atrm 7         # borrar el trabajo 7
at -c 7        # mostrar script generado con entorno capturado

A diferencia de cron, at preserva variables y directorio del momento de alta, y ejecuta con /bin/sh. Los ficheros de la cola suelen almacenarse en /var/spool/cron/atjobs. Existe además la opción batch, que deja los trabajos para cuando la carga del sistema baje de un umbral configurado en atd.

# Ejecutar cuando la carga lo permita (modo batch)
echo '/ruta/a/script_intensivo.sh' | batch

Si te equivocas al programar algo (pasa más de lo que crees), cancelar es tan simple como atrm ID. Y si ya no recuerdas el ID, atq lo lista en un periquete con usuario y fecha programada.

Ficheros, permisos y control de acceso

Para controlar quién puede programar, cron y at permiten listas de acceso basadas en ficheros en /etc: cron.allow, cron.deny, at.allow y at.deny. Funcionan con lógica sencilla: si existe .allow, solo los usuarios listados pueden usarlo; si no, se mira .deny para excluir. Si no existen ninguno, el comportamiento por defecto suele ser permisivo para todos los usuarios locales.

# Ejemplo: permitir cron solo a dos usuarios
sudo sh -c 'printf "%s\n" admin ops > /etc/cron.allow'

Como administrador, evita editar crontabs bajo /var/spool directamente. Usa siempre crontab -e, crontab -u y los directorios /etc/cron.d/ con ficheros separados por servicio. En Debian, buena parte del mantenimiento de paquetes instala scripts en /etc/cron.daily/ y compañía, lo que reduce fricción en upgrades y purgas.

Respecto a logs, la actividad de cron suele ir a /var/log/syslog (o a /var/log/cron según la distro). Si necesitas consolidar salidas de tus jobs en un archivo aparte, redirígelas en el propio crontab o dentro del script, y considera herramientas de observabilidad si vas en serio con auditoría.

# Ejemplo de redirección a log dedicado
0 * * * * /usr/local/bin/tarea.sh >> /var/log/tarea.log 2>&1

Hora correcta, zona horaria y precisión

Para que los jobs caigan donde deben, es clave tener bien la hora del sistema y la zona horaria. Compruébalo con timedatectl, sincroniza con NTP y corrige la zona si hace falta con timedatectl set-timezone Región/Ciudad.

# Comprobación y ajuste de zona horaria
timedatectl
timedatectl set-timezone Europe/Madrid

Si tu equipo no está 24/7, cron puede perder ventanas de ejecución (por ejemplo, a las 3:00 de la madrugada cuando está apagado). Para esos casos, instala anacron, que ejecutará las tareas diarias, semanales o mensuales pendientes cuando el sistema vuelva a arrancar.

Rendimiento y buenas prácticas

Programar en exceso o a horas conflictivas puede pasar factura: picos de CPU y RAM, sobrecarga de red si hay transferencias, bloqueos por dos jobs peleando por el mismo fichero… Planifica con cabeza, reparte cargas y evita lanzar muchas acciones pesadas a la vez.

Para minimizar impacto, rebaja prioridades con nice o limita CPU con cpulimit en los crons más «glotones». También puedes implementar ventanas de mantenimiento y checks previos de carga antes de arrancar un proceso costoso.

# Bajar prioridad o limitar CPU
0 19 * * * nice -n 19 /ruta/script.sh
0 19 * * * cpulimit -l 50 -- /ruta/script.sh

Otro buen hábito es limpiar cachés y temporales de forma periódica, programar actualizaciones en horas valle y registrar métricas de uso de CPU, memoria y disco con scripts simples que te ayuden a detectar cuellos de botella antes de que sean un incendio.

Alternativas y complementos: anacron, fcron, hcron, mcron

Si tu máquina no está siempre encendida, anacron es el compañero de cron: garantiza que las tareas diarias/semanales/mensuales se ejecuten cuando el equipo se encienda de nuevo. En Debian y derivadas, su convivencia con cron viene bien resuelta de serie.

Hay otros planificadores con matices interesantes: fcron permite programar sin requerir equipos 24/7 y soporta combinaciones finas de hora y minuto; hcron incorpora etiquetas para organizar trabajos y facilita administración multiusuario; mcron propone su propia aproximación con reconstrucción de tareas desde un punto inicial.

Herramientas GUI y servicios externos

Si prefieres algo visual u online, tienes opciones para crear expresiones cron a golpe de clic: Crontab Guru (valida y explica), Cron Job Generator (plantillas preconfiguradas), EasyCron (programa llamadas a URLs, logs y alertas), Cron Maker (basado en Quartz). En escritorio KDE, KCron te permite gestionar tareas sin tocar la línea de comandos.

Para quien necesita automatizar URLs o webhooks, servicios como EasyCron simplifican el orquestado con panel, logs, alertas por email y ejecución condicionada. Ten presente los aspectos de privacidad y cumplimiento si procesas datos sensibles desde o hacia terceros.

macOS y Windows: alternativas nativas

En macOS, launchd es el sistema recomendado frente a cron. Define tareas en ficheros .plist con StartCalendarInterval y opciones avanzadas como reintentos, dependencias y reinicio en fallo. La integración con el sistema es superior y la gestión de errores más robusta.

En Windows, si buscas algo similar, tienes programadores como WinCron, VisualCron o Advanced Task Scheduler, con interfaz gráfica, flujos y notificaciones. No son cron, pero resuelven la misma necesidad de automatización periódica en ese entorno.

Diferencias clave entre crontab y at

Aunque ambos programan tareas, su filosofía es distinta: crontab sirve para ejecuciones periódicas y no mantiene tu entorno; at está pensado para una única ejecución y sí conserva variables y directorio actual, reproduciendo condiciones de la sesión en la que lo programaste.

A nivel de servicios, cron es el demonio continuo que comprueba reglas cada minuto; atd (o atrun) gestiona las ejecuciones puntuales y el modo batch condicionado por la carga del sistema.

Listas de acceso y seguridad

Para restringir usos, configura /etc/cron.allow, /etc/cron.deny, /etc/at.allow y /etc/at.deny. Introduce usuarios, uno por línea. En entornos multiusuario conviene limitar quién puede programar, auditar los cambios y proteger bien /etc y /var/spool para evitar manipulaciones maliciosas.

Recuerda que cron puede enviar por correo local la salida de los jobs. Ajusta MAILTO o redirecciona a ficheros de log. Si externalizas notificaciones o recoges métricas en servicios de terceros, revisa implicaciones de privacidad y el cumplimiento normativo.

Ejemplos que vas a usar de verdad

Para ejecutar un script a diario a las 03:00, la regla típica en el crontab de tu usuario sería:

0 3 * * * /ruta/al/script.sh

Si lo quieres en el crontab del sistema con usuario explícito, añade el campo de usuario:

0 3 * * * backup /usr/local/bin/backup.sh

Para programar una tarea única mañana a las 11:00, usa at con un formato natural:

at 11:00 tomorrow
echo 'Hola desde at' | mail usuario@ejemplo.com
<Ctrl+D>

Si te interesa ejecutar un fichero de comandos en una fecha exacta, alimenta at desde un archivo:

at 17:25 28.02.2026 < /home/usuario/tareas

Y para inspeccionar o eliminar, no hay misterio:

atq
at -c 9
atrm 9

Para tareas repetitivas por día, semana o mes sin complicarte, coloca scripts ejecutables en los directorios /etc/cron.daily/, /etc/cron.weekly/ y /etc/cron.monthly/. El sistema se encargará de lanzarlos con la periodicidad adecuada.

Cuando el sistema no está siempre encendido, instala anacron para que al arrancar ejecute lo que quedó pendiente en /etc/cron.daily, /etc/cron.weekly y /etc/cron.monthly. Mano de santo en portátiles.

Si necesitas escribir expresiones cron complejas, apóyate en Crontab Guru o Cron Job Generator. Validan al vuelo y te evitan errores tontos. Para programar llamadas HTTP, EasyCron te da panel, logs y alertas.

Todo lo referente a formato y opciones está documentado en crontab(5). Un ratito con man crontab y te llevas trucos muy jugosos que no salen en ejemplos sueltos.

La automatización con cron y at te ahorra tiempo, reduce errores humanos y permite ejecutar procesos fuera del horario laboral sin molestar a nadie. Con una buena planificación del calendario, control de entorno, logs decentes y un ojo puesto en la carga, es fácil mantener sistemas limpios y fiables incluso con muchas tareas en marcha.