Programar tareas automáticas con cron y crontab en Linux

Si trabajas con Linux tarde o temprano necesitas automatizar tareas repetitivas: copias de seguridad, limpiezas, actualizaciones, generación de informes, reinicio de servicios… Para todo eso el aliado clásico es el demonio cron y los archivos crontab, que permiten decirle al sistema qué ejecutar y cuándo hacerlo, sin que tengas que estar pendiente.

Aunque el concepto es sencillo, la realidad es que cron tiene mucha miga: tipos de crontab, sintaxis llena de símbolos, permisos, logs, impacto en el rendimiento, errores típicos, alternativas como systemd timers, diferencias entre cron y anacron o incluso soluciones específicas para Windows y macOS. En esta guía vas a encontrar una explicación amplia y ordenada de todo lo que aparece disperso en la documentación y en distintas páginas, pero contado con otras palabras y en un tono más cercano.

Qué es cron y por qué es tan importante tener bien la hora

En los sistemas tipo Unix, cron es un demonio que se ejecuta en segundo plano desde que arranca la máquina. Su trabajo es muy simple en apariencia: cada minuto revisa sus tablas de programación y comprueba si coincide alguna instrucción con la fecha y la hora actuales; si encaja, lanza el comando o script indicado.

Esto implica que cron confía totalmente en la hora del propio sistema. Si el reloj o la zona horaria están mal configurados, las tareas saltarán en momentos distintos a los que tú crees. Para evitarlo es fundamental usar sincronización con NTP (Network Time Protocol), que mantiene la hora correcta consultando servidores de tiempo en Internet.

En la mayoría de distribuciones modernas puedes comprobar el estado de la hora con:

timedatectl

Este comando muestra si la fecha es correcta, qué zona horaria está activa y si el sistema está sincronizado con NTP. Si ves que el huso horario no es el correcto, puedes ajustarlo con algo como:

timedatectl set-timezone Europe/Madrid

Además, los servicios NTP se configuran en ficheros como /etc/ntp.conf o equivalentes según la distribución. Tener todo esto fino es esencial, porque si el reloj se descuadra, tus jobs de cron empezarán a ejecutarse a horas absurdas sin que aparentemente hayas cambiado nada.

Qué es exactamente un crontab

El demonio cron no «sabe» qué tiene que hacer por sí mismo; se guía por uno o varios archivos especiales llamados crontab (cron table). Cada uno de estos ficheros es un simple archivo de texto con líneas que indican cuándo y qué ejecutar, usando una sintaxis compacta basada en campos de tiempo.

En un sistema Linux estándar existen dos grandes tipos de configuración:

• Crontab del sistema: suele estar en /etc/crontab y se complementa con archivos en /etc/cron.d/ o con directorios como /etc/cron.hourly, /etc/cron.daily, etc. Lo gestiona normalmente root y se usa para tareas críticas del sistema.
• Crontab de usuario: cada usuario puede tener su propia tabla, que se guarda en rutas como /var/spool/cron o /var/spool/cron/crontabs según la distribución. Es la manera recomendada de que cada persona programe sus propios trabajos sin tocar la configuración global.

Los crontab de usuario no se editan directamente con un editor normal, sino a través del comando crontab, que se encarga de guardar el archivo en el sitio correcto con los permisos adecuados.

Para ver, crear o modificar la tabla del usuario actual se usa:

crontab -e

Si tienes privilegios de administrador, puedes gestionar la tabla de otro usuario añadiendo la opción -u:

crontab -e -u nombreusuario

Sintaxis básica de una línea de crontab

Cada trabajo programado ocupa una única línea en el archivo crontab. La forma básica, en los crontab de usuario, es:

m h dom mon dow comando

Esos cinco campos iniciales definen el momento o la periodicidad, y tras ellos se escribe el comando o script completo a ejecutar. Los campos significan:

• Minuto (m): valores de 0 a 59.
• Hora (h): de 0 a 23 (formato 24 horas).
• Día del mes (dom): de 1 a 31.
• Mes (mon): de 1 a 12 o el nombre/abreviatura del mes según el sistema.
• Día de la semana (dow): de 0 a 6 (a veces 0 y 7 representan domingo) o abreviaturas en inglés (mon, tue, etc.).

En los crontab de sistema (por ejemplo en /etc/crontab) hay un campo adicional justo antes del comando que indica el usuario con el que se ejecutará esa tarea:

m h dom mon dow usuario comando

Una entrada típica de sistema podría ser:

00 19 * * 0 usuario /ruta/absoluta/consulta.sh

Con esa línea se ejecutaría el script todos los domingos a las 19:00, con la cuenta de ese usuario concreto. En los crontab personales, en cambio, el usuario implícito es siempre el dueño del archivo, así que ese campo no aparece.

Caracteres especiales en cron: * , – / y compañía

La gran potencia de cron viene de que no tienes por qué escribir siempre un solo número en cada columna. Puedes usar símbolos especiales para definir rangos, listas o intervalos, lo que permite crear reglas bastante sofisticadas sin necesidad de scripts complejos.

• * (asterisco): significa «todos los valores posibles» en ese campo. Por ejemplo, un * en el campo de mes indica todos los meses.
• , (coma): sirve para indicar una lista de valores concretos. Por ejemplo, en el campo de horas, 6,18 haría que se ejecute a las 6:00 y a las 18:00.
• – (guion): define rangos. Si en el día de la semana pones 1-5, estarás definiendo de lunes a viernes.
• / (barra): expresa un «cada n». Por ejemplo, */10 en el campo minuto equivale a «cada diez minutos».
• rango/excep: algunas implementaciones permiten sintaxis tipo 0-23/2 para decir «cada 2 horas» dentro del rango completo de 0 a 23.

Además, todo lo que empiece por # al inicio de una línea se considera comentario y no se ejecuta. Esto es muy práctico tanto para documentar lo que hace cada job como para deshabilitar temporalmente una entrada sin borrarla.

Cadenas predefinidas: @daily, @reboot y amigos

Para los casos más habituales, cron soporta una serie de palabras clave que sustituyen a los cinco campos de tiempo y simplifican muchísimo la tabla. Dan menos juego que la sintaxis completa, pero son muy cómodas para trabajos sencillos.

Las más usadas son:

• @reboot: ejecuta la tarea una vez cada vez que se inicia el sistema.
• @yearly o @annually: una vez al año (equivale a 0 0 1 1 *).
• @monthly: el primer día de cada mes a medianoche (0 0 1 * *).
• @weekly: una vez por semana, en el primer minuto de la primera hora del día considerado inicio de semana (0 0 * * 0 en la mayoría de sistemas).
• @daily o @midnight: todos los días a las 00:00 (0 0 * * *).
• @hourly: cada hora, en el minuto 0 (0 * * * *).

Cuando editas con crontab -e, puedes usar directamente estas cadenas, por lo que una tarea cotidiana como ejecutar un script una vez al día se queda en una línea muy limpia con @daily y el comando deseado.

Ejemplos prácticos de programación con cron

La teoría está muy bien, pero lo que realmente consolida el concepto son los ejemplos. Con la sintaxis que hemos visto puedes programar cosas como:

• Script todos los días a las 19:00:

  00 19 * * * /ruta/del/script/consulta.sh

• Solo los domingos a las 19:00:

  00 19 * * 0 /ruta/del/script/consulta.sh

• El 4 de febrero a las 19:00 de cada año:

  00 19 4 2 * /ruta/del/script/consulta.sh

• Cada 10 minutos:

  */10 * * * * /ruta/del/script.sh

• De lunes a viernes a las 7:55 y 19:55:

  55 7,19 * * 1-5 /ruta/del/script.sh

En muchos tutoriales se recomienda no abusar de comandos complejos en la propia línea de cron y, en su lugar, crear un script dedicado (por ejemplo en /usr/local/bin o en un directorio de scripts) y lanzar solo ese script desde el crontab. Así mantienes la tabla limpia y la lógica en un archivo más fácil de depurar.

Creación de scripts y permisos para usarlos con cron

Para que cron pueda ejecutar tus scripts no basta con programarlos; deben tener permisos de ejecución correctos y rutas adecuadas. Un ejemplo sencillo de script sería:

nano consulta.sh

#!/bin/bash
# script de ejemplo
sudo ls -l / > archivoResultado.txt

Una vez guardado, hay que hacerlo ejecutable para que cron no falle:

chmod ugo+x consulta.sh

Este punto es crítico, porque si el fichero no es ejecutable, el job fallará silenciosamente o generará errores que verás después en los logs o correos. A partir de ahí, ya puedes añadir la línea correspondiente en tu crontab con la ruta absoluta al script.

Variables de entorno y PATH en crontab

Cuando cron lanza una tarea no lo hace en el mismo entorno que tu terminal interactivo. Arranca con un entorno muy mínimo, con variables como HOME, SHELL, LOGNAME y PATH establecidas a valores básicos. Esto provoca uno de los errores más típicos: scripts que funcionan perfectamente en la consola pero fallan al ir por cron.

El motivo habitual es que el PATH que ve cron no incluye directorios donde se encuentran comandos como git, python, pip, node y similares. La solución es, o bien usar siempre rutas absolutas a los binarios en tus scripts, o bien definir un PATH explícito al principio del archivo crontab, por ejemplo:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAILTO="tu.correo@ejemplo.com"

Con esto garantizas que cron encuentra los ejecutables igual que si los llamaras desde un shell interactivo. Y añadiendo la variable MAILTO puedes controlar a qué dirección se envía la salida y los errores de los trabajos (enviar correos desde bash y powershell).

Dónde ver la salida y los logs de los cron jobs

Por defecto, cron envía la salida estándar y la de error de cada job al correo local del usuario que ha programado la tarea. Si tienes un MTA configurado (por ejemplo postfix o sendmail), podrás leer esos mensajes con herramientas como mail o redirigirlos a una cuenta externa.

En entornos mínimos donde no hay correo configurado, la actividad de cron suele registrarse en archivos de log del sistema. Dependiendo de la distribución, encontrarás información en:

• /var/log/syslog (Ubuntu, Debian y derivadas).
• /var/log/cron (CentOS, RHEL, Oracle Linux, etc.).

Para investigar problemas puedes usar comandos como:

tail -n 50 /var/log/syslog | grep CRON

tail -f /var/log/cron

Además, siempre puedes redirigir la salida de un job a un archivo concreto, por ejemplo para tener un log dedicado a ese trabajo:

0 2 * * * /home/usuario/backup.sh >> /var/log/backup.log 2>&1

Si lo que quieres es que no se envíe nada por correo, puedes mandar toda la salida a /dev/null:

0 2 * * * /ruta/script.sh >/dev/null 2>&1

Administración básica de crontab

El comando crontab concentra las operaciones más habituales para gestionar los trabajos programados de un usuario. Las opciones más utilizadas son:

• crontab -e: edita (o crea) el crontab del usuario actual con el editor por defecto (nano, vim, etc.).
• crontab -l: lista todas las entradas actuales de la tabla del usuario.
• crontab -r: borra por completo el crontab del usuario (sin confirmación, hay que ir con cuidado).
• crontab archivo: reemplaza el crontab actual por el contenido del fichero especificado.
• crontab -u usuario: gestiona la tabla de otro usuario (requiere permisos).
• crontab -c dir: en algunos sistemas permite definir el directorio donde se almacena el archivo crontab.

Si quieres hacer una copia de seguridad de tus trabajos, basta con volcar la tabla a un archivo de texto:

crontab -l > ~/crontab_backup.txt

Y restaurarla más adelante con:

crontab ~/crontab_backup.txt

Impacto en el rendimiento y buenas prácticas

Cron en sí consume muy pocos recursos, pero eso no significa que puedas llenar el sistema de reglas sin pensar. Cada trabajo que se dispara implica uso de CPU, memoria, disco y, a menudo, red. Si muchos jobs pesados coinciden en el tiempo, puedes provocar picos que afecten a usuarios o servicios en producción.

Al programar muchas tareas hay varios riesgos claros:

• Consumo de recursos: si arrancan varios scripts intensivos de golpe (por ejemplo, copias de seguridad y actualizaciones) puedes saturar CPU o I/O y hacer que el sistema se arrastre.
• Sobrecarga de red: tareas que sincronizan datos, suben ficheros o consultan APIs pueden acaparar ancho de banda en momentos delicados.
• Conflictos de acceso: dos jobs escribiendo sobre el mismo archivo o base de datos a la vez pueden generar resultados corruptos o inconsistentes.

Para mitigar estos problemas es recomendable:

• Elegir horarios de baja carga, como la madrugada, para tareas pesadas.
• Usar herramientas como nice y cpulimit para rebajar la prioridad o limitar el uso de CPU de ciertos procesos.
• Evitar ejecuciones simultáneas de un mismo script usando flock u otras técnicas de bloqueo.
• Monitorizar periódicamente los logs y la respuesta del sistema para detectar cuellos de botella mediante monitorizar rendimiento con eBPF.

Un truco práctico es añadir en cron algo como:

0 3 * * * nice -n 19 /ruta/script_pesado.sh

Con eso ejecutas el trabajo en plena madrugada y con la prioridad de CPU más baja, reduciendo su impacto en el resto de procesos.

Errores habituales y cómo evitarlos

Trabajar con cron tiene sus trampas. Hay una serie de fallos muy repetidos que conviene tener en el radar para no volverse loco:

• PATH incompleto: como ya se ha comentado, comandos que funcionan a mano dejan de hacerlo en cron porque no están en el PATH del demonio.
• Permisos incorrectos: scripts sin bit de ejecución o con permisos demasiado restrictivos para el usuario que los lanza.
• Rutas relativas: usar ./script.sh o rutas relativas sin haber cambiado al directorio correcto dentro del script provoca errores de «archivo no encontrado».
• Salida sin controlar: no redirigir logs ni definir MAILTO y luego tener la cola de correo reventada o sin rastro de qué ha pasado.
• Demasiada frecuencia: jobs que se ejecutan cada minuto sin necesidad, generando carga constante y logs enormes.

Para depurar, una práctica muy recomendable es probar primero los scripts a mano con el mismo usuario que usará cron, y solo cuando todo va redondo programarlos. Y, por supuesto, añadir comentarios claros en el crontab para recordar qué hace cada línea.

Seguridad y control de acceso a cron

Las tareas automatizadas son un vector muy jugoso para abusos si alguien consigue escribir o modificar tu crontab. Por eso muchas distribuciones permiten gestionar quién puede usar cron mediante los archivos /etc/cron.allow y /etc/cron.deny.

El funcionamiento típico es:

• Si existe /etc/cron.allow, solo los usuarios listados ahí pueden usar cron.
• Si no existe allow pero sí /etc/cron.deny, todos menos los listados podrán usarlo.

Además, conviene revisar permisos sobre scripts y directorios involucrados, y evitar meter en cron comandos con sudo mal controlado o rutas que cualquiera pueda modificar. Un crontab vulnerable puede ser un atajo para escalar privilegios o mantener persistencia en un sistema comprometido.

Alternativas a cron y crontab en Linux, Windows y macOS

Aunque cron sigue siendo el estándar de facto en muchos servidores, no es la única opción ni siempre la más adecuada. Existen herramientas pensadas para cubrir casos que cron lleva regular, como los jobs que deben ejecutarse aunque el equipo haya estado apagado.

En el mundo Linux/Unix destacan:

• Anacron: ideal para equipos que no están encendidos 24/7. Si una tarea programada no pudo ejecutarse porque la máquina estaba apagada, se lanza cuando el equipo vuelva a arrancar.
• Fcron: similar a cron pero más flexible con horarios, permitiendo especificar cosas como «aproximadamente a esta hora» y funcionando también en máquinas que se apagan con frecuencia.
• hcron: menos conocido, añade características como etiquetas para organizar jobs, administración de redes de equipos y mejoras de seguridad en su gestión.
• Mcron: otra implementación con particularidades, como la posibilidad de redefinir programaciones y reconstruir trabajos desde un punto inicial.

En sistemas que no son Linux también hay alternativas potentes:

• Windows: existen herramientas como WinCron, VisualCron o Advanced Task Scheduler, que ofrecen interfaces gráficas muy completas para programar tareas sin lidiar con la sintaxis de cron.
• macOS: aunque cron sigue presente, Apple recomienda usar launchd. Se configura mediante ficheros .plist y ofrece una integración mucho más profunda con el sistema: reinicios automáticos de tareas fallidas, condiciones avanzadas, etc.

En Linux moderno tampoco hay que olvidar los systemd timers, que actúan como «cron integrado» dentro de systemd. Permiten cosas que cron no hace tan bien: encadenar servicios, reaccionar a eventos (arranque, conexión de red…), gestionar reintentos, registrar en journal, etc. Son más complejos de configurar, pero para entornos exigentes muchas veces son la mejor elección.

Cron en entornos profesionales y empresariales

En el contexto de servidores y empresas, cron y crontab son un pilar para automatizar tareas rutinarias y reducir errores humanos. Algunos usos típicos en organizaciones son:

• Copias de seguridad diarias o semanales de bases de datos y ficheros críticos.
• Actualizaciones periódicas de sistemas y aplicaciones, o comprobaciones de seguridad.
• Generación y envío de informes automáticos a distintos departamentos.
• Scripts de mantenimiento: limpieza de logs viejos, rotación de ficheros, vaciado de temporales.
• Monitorización programada de recursos (CPU, RAM, disco) y servicios.

El beneficio principal es liberar a administradores y técnicos de tareas mecánicas para que se centren en trabajos de más valor. Eso sí, en un entorno profesional hay que ser especialmente cuidadoso con la documentación de los jobs, el control de versiones de los scripts y la revisión periódica de lo que hay programado, para evitar sorpresas cuando cambian equipos o personas.

Además, es buena práctica usar cron para alimentar sistemas de monitorización y alertas (por ejemplo, haciendo que scripts de chequeo avisen a servicios como Healthchecks.io cuando algo falla o no se ejecuta a tiempo), de modo que no dependas solo de mirar logs a mano.

Con todo esto, cron y crontab se convierten en una especie de «agenda automática» del sistema: si planificas bien la frecuencia, vigilas permisos, controlas el entorno y cuidas los logs, puedes apoyarte en ellos para casi cualquier tipo de automatización diaria sin volverte loco ni castigar el rendimiento de tus servidores.