Programar tareas en Linux usando Crontab

  • Cron es el demonio que ejecuta tareas programadas y Crontab es el archivo donde se definen, con sintaxis flexible basada en cinco campos de tiempo y comandos.
  • Una buena configuración de hora, permisos, rutas absolutas y variables de entorno es clave para que los cron jobs se ejecuten correctamente sin errores silenciosos.
  • Cron permite automatizar copias de seguridad, limpieza, actualizaciones y monitorización, pero mal planificado puede impactar en rendimiento y seguridad del sistema.
  • Existen herramientas y alternativas como Anacron, Fcron, launchd o servicios externos que amplían o sustituyen a Cron en escenarios más complejos o en otros sistemas.

Programar tareas en Linux con Crontab

Si usas Linux en el día a día, tarde o temprano necesitas automatizar tareas repetitivas con Cron y Crontab: copias de seguridad, actualizaciones, generación de informes, limpieza de ficheros, monitorización… Hacer todo eso a mano es perder tiempo y además es fácil olvidarse. Para eso existe Cron, que lleva décadas siendo uno de los pilares de la administración de sistemas en Unix y GNU/Linux.

Aunque a primera vista la sintaxis de Crontab pueda imponer un poco, en cuanto entiendes su lógica verás que programar tareas en Linux con Crontab es mucho más sencillo de lo que parece. En este artículo tienes una guía muy completa: qué es Cron, qué es Crontab, cómo se escriben las reglas, cómo depurar errores, qué impacto puede tener en el rendimiento, qué herramientas externas puedes usar, alternativas en otros sistemas y casos de uso tanto domésticos como empresariales.

Diferencias entre Cron y Crontab

A menudo se habla de Cron y Crontab como si fueran lo mismo, pero en realidad son dos piezas distintas que trabajan juntas. Entender esta diferencia te evitará muchos líos cuando tengas que depurar tareas que no se ejecutan.

  • Cron es el demonio (daemon) que se ejecuta en segundo plano desde que arranca el sistema. Su trabajo es muy simple: revisar una serie de archivos de configuración cada minuto y comprobar si toca ejecutar alguna tarea programada según la fecha y hora del sistema.
  • Crontab, por su parte, es el archivo de texto donde se definen esas tareas. Cada usuario puede tener su propio fichero crontab, con sus reglas y scripts, que se ejecutan con sus permisos. El demonio Cron lee estos ficheros y lanza los comandos cuando corresponde.

En cualquier distribución moderna de Linux vas a encontrar ambos componentes disponibles por defecto, de modo que puedes programar tareas periódicas en prácticamente cualquier distro, ya sea Debian, Ubuntu, Oracle Linux, CentOS, Rocky, Fedora, etc.

cron

Qué es Cron y por qué la hora del sistema es crítica

Cron es un demonio del sistema que se inicia al arrancar Linux. Normalmente se lanza a través de los scripts de arranque clásicos en /etc/init.d o en rutas equivalentes como /etc/rc.d, o mediante unidades de systemd (service crond o cron, según la distro). Cada minuto revisa:

/etc/crontab, /etc/cron.d, /var/spool/cron y /var/spool/cron/crontabs (la ruta exacta varía según distribución), buscando entradas que coincidan con el minuto actual. Si encuentra alguna, ejecuta el comando indicado.

Algo que muchos pasan por alto es que Cron se fía completamente de la hora del sistema. Si el reloj o la zona horaria están mal configurados, tus tareas se ejecutarán a horas que no tocan. Para comprobar el estado de la hora en sistemas modernos puedes usar:

timedatectl

Este comando muestra la hora local, UTC, la zona horaria y si el sistema está sincronizando con servidores NTP (Network Time Protocol). Lo ideal es que la sincronización NTP esté activa, porque así el reloj se corrige automáticamente.

Si ves que la zona horaria no es la correcta, puedes cambiarla con algo como timedatectl set-timezone Europe/Madrid u otra zona que se ajuste a tu país. Además, en muchas instalaciones de Linux se configura NTP automáticamente, pero si quieres personalizarlo puedes tocar /etc/ntp.conf o usar servicios alternativos como chrony.

Qué es Crontab y cómo se estructura

Crontab es el archivo donde escribes las reglas de ejecución de tus tareas programadas. Cada línea (ignorando comentarios) representa un «job»: cuándo se ejecuta y qué comando se lanza. Lo habitual es que cada usuario tenga su propio crontab en el directorio de spool: /var/spool/cron o /var/spool/cron/crontabs, según la distro.

Para gestionar tu crontab personal se usa el comando crontab con varias opciones muy básicas pero potentes. Los ficheros no se editan a mano con un editor en bruto, sino a través de este comando para evitar errores de permisos o formato.

La sintaxis básica de una línea en Crontab se basa en cinco campos de tiempo más el comando:

m h dom mon dow comando

  • Minuto (m): valores de 0 a 59.
  • Hora (h): valores de 0 a 23.
  • Día del mes (dom): de 1 a 31.
  • Mes (mon): de 1 a 12 o nombre abreviado (Jan, Feb, etc., según sistema).
  • Día de la semana (dow): de 0 a 6 o 0 a 7, siendo domingo 0 (y a veces también 7).
  • Comando: cualquier orden que podrías lanzar en la terminal, incluyendo scripts y redirecciones.

Un ejemplo típico sería:

00 19 * * * /home/usuario/scripts/backup.sh

Esta línea indica que el script se ejecutará todos los días a las 19:00 (7 de la tarde), sin importar el día del mes, el mes o el día de la semana.

crontab

Cómo crear, editar y listar tu Crontab

Para trabajar con tu archivo de tareas personales se usa casi siempre el propio comando crontab. La idea es que no edites a mano los ficheros en /var/spool/cron/crontabs, ya que están pensados para que el sistema los gestione automáticamente.

Las órdenes más habituales son:

  • crontab -e: abre tu crontab en el editor de texto por defecto (en muchas distros vim o nano) para crear o modificar entradas.
  • crontab -l: muestra en pantalla todas las tareas programadas para tu usuario.
  • crontab -r: borra tu crontab completo; es una acción irreversible, no pide confirmación si no añades -i.
  • crontab -i -r: pide confirmación antes de eliminar el crontab.
  • crontab archivo: reemplaza tu crontab actual por el contenido del archivo indicado.
  • crontab -u usuario: gestionar el crontab de otro usuario (solo root o quien tenga permisos).
  • crontab -c dir: en sistemas que lo soportan, define el directorio en el que se almacenará el crontab.

Si quieres tener una copia de seguridad de tu configuración, puedes hacer algo tan simple como:

crontab -l > ~/crontab_backup.txt

Y si necesitas restaurarla más adelante, bastaría con:

crontab ~/crontab_backup.txt

Sintaxis avanzada: caracteres especiales en Crontab

Además de los números, Crontab permite usar caracteres especiales que hacen la sintaxis mucho más flexible. Gracias a ellos puedes expresar rangos, listas o intervalos de forma compacta.

  • * (asterisco): indica «todos los valores posibles» en ese campo. Por ejemplo, * en el campo de horas significa todas las horas.
  • , (coma): separa una lista de valores concretos. Ejemplo: 0 6,18 * * * ejecuta a las 6:00 y a las 18:00.
  • – (guion): define un rango continuo. Ejemplo: 0 8-17 * * 1-5 se ejecuta cada hora de 8 a 17, de lunes a viernes.
  • / (barra): marca un paso o intervalo. Por ejemplo, */10 * * * * significa «cada 10 minutos».
  • rango/except (dependiendo de la implementación): algunas variantes permiten definir valores excluidos, aunque no es estándar en todos los cron.

Un ejemplo típico de uso combinado sería:

*/5 2 * * 1-5 /bin/ejecutar/script.sh

Esta línea lanza el comando cada 5 minutos durante la hora 2 (las 2:00) de lunes a viernes. Es una forma compacta de sustituir una lista extensa de minutos.

El carácter # (almohadilla) al principio de línea sirve para añadir comentarios. Todo lo que haya después de ese símbolo en la misma línea se ignora, lo cual es perfecto para documentar por qué existe un job o desactivarlo temporalmente sin borrarlo.

Palabras clave y atajos de tiempo en Crontab

Para los casos más habituales, Crontab ofrece atajos en forma de «palabras reservadas» que sustituyen a todos los campos de tiempo. Son muy útiles cuando quieres algo como «cada día» o «cada hora» sin pensar en números.

  • @reboot: ejecuta el comando una vez al arrancar el sistema.
  • @yearly o @annually: una vez al año, equivalente a 0 0 1 1 *.
  • @monthly: una vez al mes, el primer día a medianoche, equivalente a 0 0 1 * *.
  • @weekly: una vez a la semana, a medianoche del día 0 (normalmente domingo), equivalente a 0 0 * * 0.
  • @daily o @midnight: una vez al día, a las 00:00, equivalente a 0 0 * * *.
  • @hourly: una vez cada hora, en el minuto 0, equivalente a 0 * * * *.

Por ejemplo, si quieres que un script se ejecute cada hora, basta con:

@hourly /bin/ejecutar/script.sh

Y si quieres que un script de mantenimiento arranque después de cada reinicio, usarías:

@reboot /ruta/a/mi_script.sh

Variables de entorno y sintaxis de comandos

Una fuente típica de errores es que Cron se ejecuta en un entorno mínimo. No carga tu .bashrc ni tu entorno de usuario completo, por lo que el PATH es muy limitado (suele ser algo como /usr/bin:/bin). Eso hace que comandos como python, git, php o pip no se encuentren si no usas la ruta absoluta.

Para evitar esto, tienes dos opciones: usar siempre rutas completas en tus scripts (por ejemplo, /usr/bin/python3 en vez de python) o definir las variables de entorno al inicio de tu crontab. Un ejemplo sería:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
SHELL=/bin/bash
HOME=/home/usuario

Estas líneas se colocan al principio del fichero crontab, sin campos de tiempo, y afectan al resto de jobs que declares debajo. También puedes definir MAILTO para indicar a qué correo se envía la salida estándar y de error de los trabajos.

Recuerda que los comandos en Crontab aceptan toda la sintaxis de shell. Puedes redirigir la salida a un archivo, encadenar comandos con tuberías, etc. Por ejemplo, para guardar toda la salida de un script en un log:

* * * * * /home/usuario/helloworld.sh >> /var/log/logs.log 2>&1

Y si quieres silenciar totalmente los mensajes y no recibir correo por ese job, puedes redirigir a /dev/null:

* * * * * /home/usuario/helloworld.sh >/dev/null 2>&1

Gestión de la salida: logs y correo

Dependiendo de la distribución y la configuración, la salida de Cron se puede manejar de varias formas. En sistemas como Oracle Linux o Debian minimal, si no hay un agente de correo instalado, el demonio cron envía la salida directamente al sistema de logs.

En muchos casos podrás consultar la actividad de cron en archivos como:

  • /var/log/cron (típico en Oracle Linux, CentOS, RHEL).
  • /var/log/syslog (habitual en Debian y derivados).

Por ejemplo, para filtrar solo los mensajes relacionados con cron en un sistema que usa syslog puedes hacer algo similar a:

grep CRON /var/log/syslog

La información suele ser escueta (hora, usuario, comando), pero te sirve para ver si algo se está ejecutando o si falla.

Si instalas un agente de transporte de correo (MTA) como postfix o sendmail, entonces la salida de los jobs se envía a la cola de correo local del usuario. Se guarda normalmente en /var/spool/mail/$USER o rutas similares, y puedes leerla con herramientas como mailx (comando mail).

Además, puedes controlar el destinatario de los correos de cron usando la variable MAILTO al inicio del crontab:

MAILTO="tu.correo@ejemplo.com"

Si en su lugar dejas MAILTO vacío, tipo:

MAILTO=""

Entonces no se enviará correo para ninguno de los jobs definidos en ese crontab, algo útil si tienes muchas tareas que generan salida constante.

crontab guru

Herramientas y utilidades para trabajar con Cron

Si no te sientes cómodo escribiendo expresiones cron a mano, existen varias herramientas que te ayudan a generar reglas sin equivocarte. Algunas son servicios web, otras aplicaciones gráficas.

  • Crontab Guru: una página muy práctica en la que escribes una expresión cron y te explica en texto humano qué hace. Te avisa si hay errores y ofrece ejemplos y trucos habituales.
  • Cron Job Generator: asistente online para generar expresiones cron a partir de opciones de hora, día, intervalo… Permite crear trabajos frecuentes con configuraciones predefinidas y personalizarlas.
  • EasyCron: servicio en la nube para programar peticiones HTTP a URLs en intervalos determinados. Muy usado para lanzar scripts web, tareas en APIs, etc., con panel de control, registros y alertas por correo.
  • KDE Cron (KCron): herramienta gráfica integrada en el entorno KDE para crear, modificar y eliminar trabajos de cron sin tocar la línea de comandos. Permite seleccionar horas y fechas desde una interfaz visual.
  • Cron Maker: generador online de expresiones cron pensado para integrarse con la librería Quartz (muy utilizada en entornos Java), pero útil también para entender combinaciones complejas.

Estas utilidades no sustituyen a Cron en tu sistema, pero hacen más sencilla la parte de composición de la expresión, reduciendo errores de sintaxis.

Tipos de Crontab: sistema y usuario

En Linux hay dos grandes tipos de archivos de configuración para tareas programadas: el crontab de sistema y los crontab de usuario. Ambos usan una sintaxis muy similar, pero no se gestionan igual.

El Crontab del sistema, normalmente en /etc/crontab y en ficheros de /etc/cron.d, suele requerir permisos de root. Se utiliza para trabajos críticos del sistema (rotación de logs, mantenimiento de bases de datos, tareas de backup de alto nivel, etc.) y, a diferencia del crontab de usuario, incorpora explícitamente el campo de usuario en cada línea para indicar con qué identidad se ejecuta el comando.

Los Crontab de usuario se gestionan con crontab -e y se guardan en /var/spool/cron/crontabs o ubicación similar. Solo el propio usuario puede lanzar sus trabajos (o root, que puede gestionar los de otros), y no se deben editar directamente. Para restringir quién puede usar cron, se pueden tocar los ficheros /etc/cron.allow y /etc/cron.deny.

Impacto de Cron y Crontab en el rendimiento

Aunque Cron en sí consume muy pocos recursos, una mala planificación de tareas puede impactar negativamente en el rendimiento del sistema. El problema no suele ser el demonio cron, sino lo que mandamos ejecutar.

Cuando programas muchas tareas que se disparan a la vez, puedes provocar picos de uso de CPU y RAM. Por ejemplo, lanzar tres copias de seguridad pesadas, una reindexación de base de datos y un script de análisis de logs justo a la misma hora es casi garantía de que el servidor se va a arrastrar.

Si las tareas implican red (copias remotas, sincronizaciones con rclone, envíos masivos de datos), puedes generar sobrecarga en el ancho de banda, aumento de latencia y ping, afectando a otros servicios que dependan de la conexión.

También existe el riesgo de conflictos de tareas: dos scripts que actúan simultáneamente sobre el mismo archivo o base de datos con operaciones distintas pueden provocar corrupción de datos o fallos extraños difíciles de diagnosticar.

Para limitar el impacto, puedes utilizar utilidades como nice para reducir la prioridad de CPU de un job, o cpulimit para restringir el porcentaje máximo de CPU que puede consumir un proceso:

  • Prioridad baja de CPU:
    0 19 * * * usuario nice -n 19 /ruta/script.sh
  • Limitar CPU al 50 %:
    0 19 * * * usuario cpulimit -l 50 /ruta/script.sh

Uso de Crontab para tareas habituales: backups, limpieza y monitorización

Una de las grandes ventajas de Cron es que te permite automatizar el «mantenimiento» de tu máquina casi sin esfuerzo, mejorando el rendimiento a medio plazo y ahorrando tiempo.

Un uso muy típico es limpiar periódicamente ficheros temporales, cachés y directorios vacíos. Con un script que borre archivos antiguos o vacíos en determinadas rutas, puedes liberar espacio y reducir la fragmentación del sistema de archivos.

Otro patrón útil es programar actualizaciones de sistema y aplicaciones en horas valle. Por ejemplo, un job nocturno que lance apt update && apt upgrade (o el equivalente en tu distro) permite que el sistema esté al día sin interrumpir el trabajo diario.

También puedes automatizar el cierre de aplicaciones que lleven demasiado tiempo inactivas, liberando memoria para otros procesos. En entornos de escritorio o servidores de aplicaciones esto puede marcar una diferencia importante.

Y, por supuesto, Cron es perfecto para scripts de monitorización y registro: capturar regularmente el uso de CPU, RAM, disco, latencia de red, etc., almacenarlo en archivos de log y luego analizar tendencias para detectar cuellos de botella antes de que se conviertan en incidentes serios.

Desventajas y limitaciones de Cron y Crontab

Aunque Cron es una herramienta potentísima, no es la solución perfecta para todo. Tiene limitaciones que conviene conocer para no forzarlo más allá de lo que ofrece.

Por un lado está la curva de aprendizaje. Si vienes de entornos más gráficos o de sistemas como Windows, al principio puede intimidar escribir expresiones cron a pelo y trabajar sin interfaz visual.

Por otro lado, Cron está muy ligado al ecosistema Unix/Linux. Lo que aprendas te servirá en muchos servidores y sistemas similares, pero no podrás usarlo tal cual en Windows ni en macOS (que tiene sus propios mecanismos).

En cuanto a seguridad, si los archivos de configuración de cron no están bien protegidos, pueden ser un punto de entrada para ejecuciones maliciosas. Dejar que cualquier usuario programe cosas sin control es abrir la puerta a problemas.

Además, Cron no es ideal para tareas muy complejas o con muchas dependencias. No gestiona de forma avanzada el flujo de errores, no sabe reintentar con lógica condicional ni se integra de forma nativa con sistemas distribuidos. Para eso hay planificadores más sofisticados o los propios temporizadores de systemd.

También hay que tener en cuenta que crontab solo ofrece precisión de un minuto. Si necesitas algo que se ejecute varias veces por segundo o con menos de un minuto de intervalo, tendrás que recurrir a otras herramientas o programar bucles dentro del propio script.

Alternativas a Cron y Crontab: Anacron, Fcron, hcron, Mcron y otros

En algunos escenarios, Cron no encaja del todo bien. Por ejemplo, si tienes un portátil o un servidor que no está encendido permanentemente, los jobs programados para una hora concreta se pueden «perder» si el equipo está apagado en ese momento.

Para cubrir casos así existen alternativas como Anacron, que está pensada para ejecutar tareas periódicas sin exigir que la máquina esté siempre encendida. Si el equipo estaba apagado cuando tocaba una tarea, Anacron la lanzará en cuanto sea posible tras el arranque.

Fcron es otra opción interesante. No requiere que el sistema esté siempre activo, puede trabajar con fechas y horas específicas, y ofrece más flexibilidad a costa de requerir instalación manual en muchas distros.

hcron va un paso más allá, permitiendo usar etiquetas para organizar trabajos, gestionar redes de máquinas y mejorar la seguridad. No es tan popular, pero puede encajar bien en entornos donde se quiera centralizar la administración.

Mcron (basado en Guile) se diferencia en que se apoya en un lenguaje de programación completo para definir la programación de tareas, lo que le da una potencia enorme a la hora de redefinir trabajos, crear dependencias y manejar lógica compleja.

En Windows, en lugar de Cron se utilizan soluciones como WinCron, VisualCron o Advanced Task Scheduler, que proporcionan interfaces gráficas intuitivas y funcionalidades comparables, aunque integradas con el ecosistema de Microsoft.

Cron y Crontab en entornos empresariales

En empresas de todos los tamaños, Cron y Crontab son parte del «pegamento» que mantiene en marcha los sistemas. Permiten automatizar procesos repetitivos y críticos sin intervención humana constante, reduciendo el riesgo de fallos y liberando tiempo de los administradores.

Entre los usos empresariales más habituales están las copias de seguridad programadas, actualizaciones de software, generación periódica de informes, tareas de mantenimiento de bases de datos y limpieza de logs. Gracias a la granularidad de la sintaxis, puedes ajustar al milímetro en qué momento se realizan para minimizar impacto.

Además, estas automatizaciones tienen un efecto directo en eficiencia y productividad. Los empleados no tienen que acordarse de lanzar procesos de rutina, se reducen errores humanos y se aprovechan mejor las ventanas de baja carga para hacer operaciones pesadas.

Eso sí, en entornos empresariales conviene documentar muy bien todos los jobs programados, mantener copias de seguridad de los crontab y revisar periódicamente que lo que está definido sigue teniendo sentido. Con el tiempo, es fácil acumular tareas obsoletas que siguen consumiendo recursos sin aportar nada.

Al final, Cron y Crontab se convierten en una especie de «agenda automática» del sistema. Si los usas con cabeza, se vuelven imprescindibles tanto en servidores modestos como en infraestructuras grandes con muchas máquinas, y te permiten mantener una base sólida para construir encima otras herramientas más avanzadas de orquestación o monitorización.

Visto todo lo anterior, queda claro que programar tareas en Linux con Crontab sigue siendo una de las formas más simples y potentes de automatizar tu sistema: con unas pocas líneas bien escritas puedes encargarte de backups, limpieza, actualizaciones, monitorización y procesos de negocio sin tocar un botón, siempre que respetes sus límites, cuides los permisos, controles el entorno y planifiques con sentido el impacto en rendimiento y seguridad.

copia de seguridad automática en discos externos
Artículo relacionado:
Copia de seguridad automática: protege tus datos en discos externos