Cómo programar tareas automáticas con Crontab en Linux

Si trabajas con Linux tarde o temprano necesitas que el sistema haga cosas por ti sin que tengas que estar delante del teclado: copias de seguridad nocturnas, limpieza de ficheros temporales, generación de informes o sincronización de datos. Para todo eso, el viejo conocido de los sistemas Unix sigue siendo el rey: cron.

Aunque a primera vista pueda imponer un poco, cron y su archivo crontab son mucho más sencillos de lo que parecen. Con un par de conceptos claros podrás programar tareas automáticas muy potentes y flexibles, tanto para tu usuario como a nivel de sistema. En las próximas líneas vas a ver cómo funciona cron, cómo se configura crontab, qué detalles hay que vigilar (hora del sistema, permisos, PATH…), errores típicos, impacto en rendimiento, alternativas y mucho más.

¿Qué es cron y por qué es tan importante en Linux?

En los sistemas tipo Unix, cron es un demonio (daemon) que se ejecuta en segundo plano desde que el sistema arranca. Su misión es muy simple: cada minuto revisa si hay alguna tarea programada para ese instante y, si la hay, la ejecuta. Ni más ni menos.

Crontab: la tabla de tareas de cron

El corazón de la programación en cron es el archivo crontab, una tabla de tareas donde se definen los comandos y su horario. Cada usuario puede tener su propio crontab, de forma que no hace falta ser root para automatizar tareas personales.

Para trabajar con tu crontab de usuario se usa el propio comando crontab. Con él puedes crear, editar, listar o borrar las tareas programadas sin tener que tocar directamente los ficheros de sistema.

Sintaxis básica de una línea en crontab

Cada línea de crontab corresponde a un trabajo de cron y sigue este patrón de cinco campos de tiempo más el comando:

minuto hora día_del_mes mes día_de_la_semana comando

Cada campo puede tomar valores específicos o caracteres especiales. Los rangos habituales son los siguientes, y es importante tenerlos claros porque son el núcleo de la programación:

Minuto: valores de 0 a 59.
Hora: valores de 0 a 23.
Día del mes: valores de 1 a 31.
Mes: valores de 1 a 12 o nombres de mes abreviados en algunos sistemas.
Día de la semana: valores de 0 a 7, donde 0 y 7 suelen representar domingo; también se pueden usar nombres abreviados en inglés (mon, tue…).

Después de esos cinco campos va el comando a ejecutar, que puede ser desde un binario del sistema hasta un script de shell, Python, PHP, etc. Lo que escribirías en una terminal, lo puedes plasmar ahí, teniendo en cuenta el entorno restringido en el que corre cron.

Caracteres especiales en las expresiones de cron

Para no volverte loco escribiendo montones de líneas, cron admite varios modificadores y caracteres especiales que dan mucha más potencia a la programación:

*: significa “todos los valores” en ese campo. Por ejemplo, * en el campo mes implica todos los meses.
,: separa una lista de valores. Por ejemplo, 1,15 en el día del mes ejecuta la tarea el día 1 y el día 15.
–: indica un rango continuo. Por ejemplo, 1-5 en día de la semana equivale a lunes a viernes.
/: se utiliza como paso o intervalo, normalmente junto a * (por ejemplo, */10 en minutos significa cada 10 minutos).
rangos con excepción: combinando rangos, listas y pasos se pueden crear reglas complejas, como ejecutar una tarea en un abanico de minutos excepto uno concreto.

Además, en los ficheros crontab es muy habitual recurrir a la almohadilla (#) para escribir comentarios. Cualquier línea que comience por # será ignorada por cron, pero sirve para dejar notas aclaratorias sobre lo que hace cada tarea.

Cadenas especiales @yearly, @daily y compañía

Para casos frecuentes, cron permite usar palabras clave abreviadas que sustituyen a los cinco campos de tiempo. Facilitan bastante la lectura del fichero:

@reboot: ejecuta el comando una vez cada vez que se inicia el sistema.
@yearly o @annually: equivalente a “0 0 1 1 *”, se lanza una vez al año.
@monthly: igual a “0 0 1 * *”, se ejecuta el primer día de cada mes a medianoche.
@weekly: equivalente a “0 0 * * 0”, se lanza una vez por semana.
@daily y @midnight: ambos son “0 0 * * *”, cada día a las 00:00.
@hourly: se corresponde con “0 * * * *”, el primer minuto de cada hora.

Estas cadenas son muy cómodas, pero conviene recordar que no permiten elegir una hora concreta distinta de la que traen por defecto. Si por ejemplo quieres que algo se ejecute cada día a las 13:00, tendrás que usar la forma numérica estándar («0 13 * * *») en lugar de @daily.

¿Cómo crear y editar tu crontab de usuario?

La forma correcta de gestionar las tareas de un usuario es mediante el comando crontab -e. Esto abre el crontab del usuario actual en el editor por defecto (nano, vim, etc.) para que puedas añadir o modificar líneas.

La primera vez que lo uses, el sistema te suele preguntar qué editor quieres usar. A partir de ahí, cada vez que ejecutes crontab -e se abrirá el mismo editor con el contenido actual del fichero, incluyendo comentarios de ayuda generados por la distribución.

Una vez añadidas las tareas y guardado el archivo, el demonio cron recarga automáticamente la nueva configuración, no hace falta reiniciar el servicio. Para comprobar qué tienes programado, puedes listar tu crontab con:

crontab -l

Si en algún momento quieres vaciar por completo tu crontab, puedes hacerlo con:

crontab -r

Existe también la variante crontab -r -i, que antes de borrar te pedirá confirmación, algo muy recomendable para no llevarte por delante sin querer todas las tareas configuradas.

Ejemplo práctico: crear un script y programarlo con cron

Para ver todo esto en acción, podemos preparar un script de ejemplo y hacer que cron lo ejecute automáticamente. Imagina que creas un fichero llamado consulta.sh en tu directorio personal con un pequeño comando:

nano consulta.sh

En su interior podrías poner algo como:

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

Este pequeño script lista el contenido del directorio raíz y lo vuelca a un archivo de texto llamado archivoResultado.txt. Para que cron lo ejecute sin problemas es imprescindible darle permisos de ejecución:

chmod ugo+x consulta.sh

Ahora toca añadirlo al crontab. Ejecutas:

crontab -e

Y agregas una línea, por ejemplo, para que se ejecute todos los días a las 19:00:

00 19 * * * usuario /ruta/completa/consulta.sh

En esa línea, los campos indican minuto 0, hora 19, cualquier día del mes, cualquier mes, cualquier día de la semana. A continuación se especifica el usuario (en el caso de crontab de sistema) y después la ruta al script. Otros ejemplos típicos serían:

Todos los domingos a las 19:00:
00 19 * * 0 usuario /ruta/consulta.sh
El 4 de febrero a las 19:00 cada año:
00 19 4 2 * usuario /ruta/consulta.sh

Opciones del comando crontab para administrar tareas

El binario crontab no solo sirve para editar tareas, sino también para gestionar archivos de otros usuarios o cargar ficheros desde rutas concretas. Las opciones más usadas son:

crontab archivo: sustituye el crontab actual del usuario por el contenido del archivo indicado.
crontab -e: abre el crontab del usuario actual en el editor por defecto.
crontab -l: muestra en pantalla todas las tareas actualmente configuradas para ese usuario.
crontab -r: borra el crontab completo del usuario (sin confirmación, salvo que se use -i).
crontab -c dir: permite definir el directorio donde se almacenarán los ficheros crontab, siempre que haya permisos.
crontab -u usuario: administra el crontab de otro usuario (requiere permisos de root).

También se suele hablar de crontab -h para ver la ayuda rápida, donde vienen detalladas todas las banderas disponibles.

Entorno y variables en la ejecución de cron

Algo que a menudo da quebraderos de cabeza es que cron no ejecuta los comandos en el mismo entorno que tu sesión interactiva. Es decir, no carga tu .bashrc ni tu .profile salvo que tú lo fuerces. Por defecto define unas pocas variables como:

HOME: el directorio personal del usuario que ejecuta el crontab.
LOGNAME y USER: el nombre del usuario.
SHELL: el shell que se utiliza para interpretar los comandos, normalmente /bin/sh.
PATH: la ruta básica de búsqueda de binarios, a menudo algo limitado como /usr/bin:/bin.

Si confías en que haya comandos en el PATH que luego cron no encuentra, te vas a topar con errores silenciosos. Por eso es muy recomendable usar rutas absolutas en tus scripts (por ejemplo, /usr/bin/python en lugar de python a secas), o bien redefinir PATH en el propio crontab:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

También puedes cambiar el shell usado e incluir la carga de tu .bashrc si lo necesitas, ajustando el inicio de tu crontab así:

SHELL=/bin/bash . $HOME/.bashrc

En cuanto a la salida, como son comandos de shell, puedes redirigir STDOUT y STDERR igual que en la terminal. Por ejemplo, para que una tarea no genere ni correo ni logs:

* * * * * comando > /dev/null 2>&1

O para acumular la salida en un fichero de log propio de la tarea, algo muy útil para depuración y auditoría:

*/10 * * * * /ruta/script.sh >> /var/log/mis_cron.log 2>&1

Control de acceso a cron: cron.allow y cron.deny

En muchos sistemas se controla quién puede programar tareas mediante los ficheros /etc/cron.allow y /etc/cron.deny. Estos archivos sirven para restringir o conceder acceso al comando crontab.

La lógica es sencilla: si existe cron.allow, solo los usuarios listados ahí pueden usar cron; si solo existe cron.deny, todos salvo los incluidos están autorizados. Si están ambos presentes y un usuario aparece en los dos, cron.allow tiene prioridad, por lo que ese usuario sí podrá usar crontab.

Por ejemplo, podrías bloquear a todos y luego habilitar solo a un usuario particular con algo como:

echo ALL | sudo tee -a /etc/cron.deny echo ishmael | sudo tee -a /etc/cron.allow

Incluso con permisos de sudo, si un usuario está vetado según estos archivos, no podrá modificar ni su propio crontab ni el de otros, y recibirá un mensaje indicando que no puede usar el programa crontab.

Tipos de crontab: sistema y usuario

En un servidor típico conviven dos niveles de configuración: por un lado está el crontab de sistema, y por otro los crontabs de usuario personales. Ambos usan sintaxis similar, pero se almacenan y gestionan de forma distinta.

Crontab de sistema (UNIX/Linux): suele encontrarse en /etc/crontab y en archivos bajo /etc/cron.d. Requiere privilegios de root para editarse y se suele usar para servicios críticos, tareas de mantenimiento global, rotación de logs, etc. Aquí las líneas incluyen un campo extra con el usuario bajo el que se ejecuta el comando.
Crontab de usuario: cada cuenta puede tener uno, accesible con crontab -e. Se almacenan en directorios como /var/spool/cron o /var/spool/cron/crontabs según la distro. No se editan directamente; se modifican usando el comando crontab, y se ejecutan con los permisos del usuario que los creó.

Gracias a esta dualidad, cada usuario puede automatizar sus tareas habituales de forma aislada, mientras el administrador mantiene una programación global para el sistema.

Logs y salida de las tareas de cron

Cuando algo falla en una tarea programada es fundamental saber dónde mirar. Dependiendo de la configuración del sistema, la salida de cron puede ir a syslog, a un archivo dedicado o a la cola de correo local.

Impacto de cron en el rendimiento del sistema

Aunque cron en sí mismo consume muy pocos recursos, un mal uso puede provocar picos de CPU, saturación de disco o de red. Al final, todo depende de cuántos trabajos programes y con qué frecuencia.

Si defines un montón de tareas pesadas para la misma hora, el sistema puede sufrir tirones importantes: consumo alto de CPU y RAM, contención de disco o ancho de banda si hay transferencias grandes. Además, varias tareas simultáneas que accedan a los mismos archivos o bases de datos pueden generar conflictos y ralentizaciones.

Cuando hay trabajos que tiran de red —por ejemplo, sincronización de backups remotos, llamadas a APIs o descargas masivas—, también puedes notar aumentos en el ping y latencia general, sobre todo en entornos con bandas limitadas.

Buenas prácticas para minimizar el impacto

Para aprovechar cron sin castigar la máquina, compensa seguir algunas estrategias muy sencillas:

Distribuir las tareas en distintos momentos, sobre todo las pesadas, evitando horas punta para usuarios o servicios.
Usar herramientas como nice para bajar la prioridad de CPU de algunas tareas largas:
0 3 * * * nice -n 19 /ruta/script.sh
Aprovechar utilidades como cpulimit si necesitas limitar el porcentaje de CPU que puede usar un proceso lanzado por cron.
Combinar cron con flock u otros mecanismos de bloqueo para evitar ejecuciones simultáneas del mismo script (muy útil en tareas de backup o mantenimiento).

También es muy interesante usar cron para mejorar el rendimiento del propio sistema: limpieza periódica de cachés y temporales, cierre de aplicaciones inactivas, monitorización de uso de CPU, RAM y disco en logs para detectar cuellos de botella, etc.

Errores frecuentes al programar con cron y cómo evitarlos

Quien haya trabajado un tiempo con cron sabe que hay una serie de errores típicos que acaban repitiéndose. Tenerlos controlados te ahorra muchas horas de prueba y error.

Uno de los más comunes tiene que ver con el PATH limitado en el entorno de cron. Comandos como git, python o php pueden no encontrarse si no pones la ruta completa o si no ajustas PATH al principio del crontab. La solución es clara: rutas absolutas o redefinir PATH explícitamente.

Otro fallo clásico es olvidarse de los permisos de ejecución del script. Si el archivo no es ejecutable o el usuario de cron no tiene permisos sobre él, la tarea nunca se lanzará. Conviene revisar con ls -l y, si es necesario, usar chmod +x /ruta/script.sh.

También entra en juego el tema de privilegios. Cron ejecuta los trabajos con los permisos del usuario que los ha configurado; si necesitas operaciones que requieran root, tienes que plantearte usar sudo dentro del script (con todas las precauciones de seguridad pertinentes) o trasladar la tarea al crontab de root.

Por último, muchos problemas se deben a sobreprogramar (demasiadas tareas frecuentes), falta de logs útiles o ausencia de notificaciones. Establecer un sistema mínimo de registros y alertas —por ejemplo con servicios externos como Healthchecks.io— ayuda a detectar que un cron ha dejado de funcionar antes de que sea tarde.

Herramientas externas para trabajar más cómodo con cron

No siempre apetece pelearse con la sintaxis de cron a mano. En Internet tienes varias herramientas que generan expresiones cron, validan reglas y ayudan a depurar errores sin tener que instalar nada en tu máquina.

Crontab Guru: un editor online muy ligero que te permite escribir una expresión cron y ver en texto plano qué significa (“every 15 minutes”, “at 03:00 on Sundays”, etc.). Además, resalta errores de sintaxis y muestra ejemplos y trucos.
Cron Job Generator: orientado a crear tareas preconfiguradas mediante formularios sencillos. Permite seleccionar intervalos típicos, personalizarlos y te devuelve la línea cron lista para copiar.
EasyCron: servicio online que no solo genera expresiones, sino que ejecuta tareas remotamente llamando URLs según la programación que definas. Incluye panel de control, logs de ejecuciones y avisos por correo en caso de fallos.
KDE Cron (KCron): aplicación gráfica integrada en escritorios KDE que ofrece una interfaz visual para gestionar tareas cron sin tocar la línea de comandos. Muy útil para quien prefiera hacer clic en lugar de editar ficheros.
Cron Maker: generador web muy orientado a integraciones con bibliotecas tipo Quartz. Permite montar expresiones complejas sin teclear a mano, ideal para quienes trabajan con sistemas basados en cron pero desde entornos de desarrollo.

Estas utilidades son especialmente prácticas cuando necesitas programaciones enrevesadas o cuando estás empezando y quieres confirmar que has entendido bien la expresión antes de ponerla en producción.

Alternativas a cron y uso en otros sistemas

Aunque cron es un estándar de facto en Linux y Unix, existen alternativas que cubren casos en los que cron se queda corto, además de soluciones equivalentes en otros sistemas operativos.

En el ecosistema Unix/Linux puedes encontrarte con herramientas como:

Anacron: pensada para máquinas que no están encendidas todo el día. Si un trabajo diario no ha podido ejecutarse porque el equipo estaba apagado, se lanza cuando se vuelve a encender.
Fcron: similar a Anacron, permite combinar tareas por fecha y hora exacta sin exigir que el equipo esté siempre activo. Suele requerir instalación y compilación desde código fuente en muchas distros.
hcron: introduce conceptos como etiquetas para clasificar tareas, gestionar redes o distintos grupos de usuarios con mayor flexibilidad, añadiendo un plus de seguridad y organización.
Mcron: compatible con cron pero con la capacidad de redefinir horarios reconstruyendo trabajos desde un punto inicial. También suele instalarse aparte y no viene de serie en la mayoría de sistemas.

En Windows no existe cron como tal, pero hay programas que cumplen funciones muy parecidas, algunos de ellos con interfaz gráfica muy cómoda: WinCron, VisualCron o Advanced Task Scheduler son ejemplos de planificadores con muchas opciones, adaptados al entorno de Microsoft.

En macOS, aunque cron sigue estando disponible, Apple recomienda usar launchd, su sistema de administración de servicios. Con launchd se definen tareas en archivos .plist (Property List) con muchas opciones de control: reinicio automático de tareas fallidas, condiciones complejas de ejecución, mejor integración con el sistema y programación precisa mediante StartCalendarInterval. Para automatizaciones serias en Mac, merece la pena apostar por launchd en lugar de cron.

Cron en entornos empresariales y nivel de complejidad

En una empresa, cron es un aliado potente para reducir trabajo repetitivo y minimizar errores humanos. Permite automatizar backups con rsync, despliegues programados, generación de informes diarios o mensuales, sincronización entre servidores, tareas de mantenimiento, etc.

Aunque la herramienta en sí es sencilla, la complejidad real viene de la cantidad y tipo de tareas que vas acumulando. Un entorno con decenas de scripts encadenados, alta frecuencia de ejecución y dependencias entre procesos puede resultar difícil de mantener sin buena documentación y sin monitorización adecuada.

En esos escenarios es crucial planificar la frecuencia de las tareas para que no devoren recursos, asegurar la seguridad de los ficheros de configuración (para evitar manipulaciones maliciosas) y contar con un sistema de alertas que avise en caso de fallos. De lo contrario, algo tan básico como un backup diario puede dejar de ejecutarse durante semanas sin que nadie se dé cuenta.