Linux

Cron Linux: la mejor manera de programar tareas automáticas

octubre 9, 2026 Qué es mejor? 13 min read
Cron Linux: la mejor manera de programar tareas automáticas

Datos comprobados en septiembre de 2026.

La respuesta corta: qué método conviene a cada perfil

Si tu equipo está encendido 24 horas y quieres programar algo cada minuto, hora o día, usa crontab clásico (Vixie cron). Es el estándar, está en casi toda distribución, y con una línea ya queda.

Si necesitas que la tarea no se lance dos veces a la vez, que dependa de la red o que deje rastro en el sistema de logs, usa systemd timers. Pide crear dos archivos (.service y .timer) pero te da control de dependencias, calendario y reinicios.

Si tu portátil o PC se apaga por la noche y no quieres perder la copia de seguridad diaria, usa anacron. No trabaja por minuto exacto, trabaja por intervalo de días y ejecuta lo pendiente al encender.

Si la tarea es crítica y necesitas saber desde fuera que se ejecutó, usa cron cloud con heartbeat. El servidor hace ping a Healthchecks.io o Cronitor y te avisa si falla o no llega.

En corto: la mayoría empieza por crontab; si el equipo no es 24/7, añade anacron; si necesitas fiabilidad y trazabilidad, pasa a systemd timers; si necesitas aviso externo, añade heartbeat.

Qué necesitas antes de programar nada

Antes de tocar el programador, deja el entorno cerrado:

  • Comprueba qué tienes instalado. En Debian, Ubuntu, Linux Mint y Fedora Workstation el cron habitual es Vixie cron o cronie. Verifica con cron --version, crond -V o systemctl status cron / systemctl status crond. Para timers, comprueba systemctl --version y que systemctl status systemd-timers responde. Estos programas corren en Linux.
  • Define bajo qué usuario corre. El crontab de usuario (crontab -e) no necesita root y solo ve tus archivos. El de sistema (/etc/crontab y /etc/cron.d/) y los timers de sistema sí piden privilegios con sudo.
  • Fija shell y PATH. Cron arranca con entorno mínimo. Declara SHELL=/bin/bash y PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin arriba del crontab o usa rutas absolutas en el script.
  • Aclara la zona horaria. Cron y systemd usan la hora del sistema (timedatectl). Si cambias TZ en el crontab, solo afecta a ese archivo. Verifica date y timedatectl status antes de programar.
  • Localiza dónde editas. crontab -l lista, crontab -e edita y valida la sintaxis, /var/log/cron o /var/log/syslog y journalctl muestran si se intentó ejecutar.

Checklist rápido: versión de cron/systemd identificada, usuario y permisos definidos, PATH y SHELL declarados, zona horaria comprobada, ruta del crontab y de logs localizada.

Métodos comparados frente a frente

La elección no es por gusto, es por comportamiento cuando el equipo se apaga, por precisión y por cómo te avisa del fallo.

Método Facilidad Coste Precisión mínima Funciona con equipo apagado Limitaciones principales
crontab (Vixie cron) alta: 1 línea 0 EUR 1 minuto no sin ejecución pendiente tras apagón; entorno mínimo; sin control de solapamiento nativo
systemd timers media: 2 archivos + enable 0 EUR 1 minuto con OnCalendar, 1 segundo con AccuracySec no, salvo Persistent=true que ejecuta al arrancar si se perdió solo en sistemas con systemd; más verboso; requiere systemctl
anacron alta: 1 línea en /etc/anacrontab 0 EUR 1 día sí: ejecuta pendiente al encender no sirve para horas/minutos exactos; solo diario o superior; necesita anacron instalado
cron cloud/remoto con heartbeat media: URL + ping 0 EUR en planes gratuitos limitados, pago por volumen 1 minuto según proveedor sí: se ejecuta en servidor externo depende de internet; límites de ejecuciones y retención en plan gratuito; hay que custodiar la URL

Todos los métodos anteriores corren en Linux salvo el cron cloud, que corre en Linux y web según el proveedor. Ninguno ejecuta si el hardware está apagado sin ayuda de Persistent o de un servicio externo.

Método 1: crontab clásico, el estándar de Linux

Crontab es el programador presente en Debian, Ubuntu, Linux Mint, Fedora y derivados. Corre en Linux y cuesta 0 EUR al ser software libre. Su alternativa libre es el propio Debian con cronie/Vixie cron.

La sintaxis son 5 campos: minuto (0-59), hora (0-23), día del mes (1-31), mes (1-12), día de la semana (0-7, 0 y 7 son domingo). Todo lo demás son combinaciones de (cada), , (lista), - (rango) y / (paso). Ejemplo: 30 2 es cada día a las 02:30.

Atajos útiles: @reboot al arrancar, @daily una vez al día (00:00), @hourly cada hora, @weekly y @monthly. Son equivalencias legibles a las 5 columnas, pero no permiten fijar minuto concreto.

Pasos para dejar una tarea programada sin sorpresas:

  1. Haz el script ejecutable y con ruta absoluta: chmod +x /home/usuario/bin/copia.sh y prueba /home/usuario/bin/copia.sh a mano.
  2. Declara entorno arriba del crontab: SHELL=/bin/bash y PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin.
  3. Edita con crontab -e. Añade la línea con redirección: 30 2 * /home/usuario/bin/copia.sh >> /home/usuario/logs/copia.log 2>&1.
  4. Comprueba con crontab -l que quedó guardada. Revisa grep CRON /var/log/syslog o journalctl -u cron para ver el disparo.
  5. Si no quieres correo, añade MAILTO="" arriba o redirige a /dev/null solo cuando ya tengas log propio.

Pros: ubicuo, sintaxis breve, ideal para tareas cada minuto/hora/día. Contras: si el equipo estuvo apagado a las 02:30, esa ejecución se pierde; sin bloqueo nativo, dos ejecuciones largas se solapan; el entorno recortado hace que falle en silencio si olvidas PATH.

Cron no avisa por sí mismo si el script falla: sin MAILTO o sin >> log 2>&1, el error se pierde y parece que no se ejecutó.

Cómo construir y probar la expresión sin romper nada

No edites a ciegas la línea de 5 campos. Usa un validador que te diga en lenguaje natural cuándo se dispara y prueba antes con un comando inocuo.

Escribe la expresión en Crontab.guru y verifica que los 5 campos usan solo * , - / y números en rango. Ese sitio marca errores de rango y te muestra los próximos disparos. Para casos dudosos, usa también Crontab Generator como segunda comprobación.

Lista para validar sin riesgo:

  • Comprueba rangos: minuto 0-59, hora 0-23, día 1-31, mes 1-12, semana 0-7. Un 60 es inválido y cron lo ignora.
  • Entiende frente a /n. es cada minuto (1.440 ejecuciones al día), /15 es cada 15 minutos.
  • Usa comas y guiones sin espacios extra: 0 8,20 1-5 es a las 08:00 y 20:00 de lunes a viernes. 0 8, 20 con espacio tras la coma rompe la línea.
  • Prueba con * echo "$(date) prueba" >> /tmp/cron_test.log 2>&1 un minuto y revisa /tmp/cron_test.log antes de poner el script real.

Email, logs y permisos: lo que hace que falle en silencio

Cron falla sin ruido cuando el entorno no es el de tu terminal.

  • MAILTO: por defecto cron envía la salida por correo local. Si no hay servidor de correo, no ves nada. Define MAILTO=tu@ejemplo.com si tienes MTA, o MAILTO="" para desactivar y fíate de tu log.
  • Logs: >> /ruta/archivo.log 2>&1 guarda salida y errores. > /dev/null 2>&1 los descarta. No uses /dev/null hasta que la tarea ya esté probada.
  • PATH y SHELL: cron trae PATH mínimo. Si tu script llama a python3, docker o rsync sin ruta absoluta, falla. Declara PATH arriba o usa /usr/bin/python3 completo.
  • Permisos y saltos de línea: el script debe tener chmod +x y terminar con salto de línea. Un crontab sin \n final a veces no carga la última línea. Revisa crontab -l y que el propietario del archivo en /etc/cron.d/ sea root con 644.
  • Entorno de usuario: crontab -e usa tu usuario. Si el script necesita leer /root/, fallará por permisos. Prueba el comando con sudo -u usuario /ruta/script.sh igual que lo ejecutará cron.

Método 2: systemd timers, la alternativa moderna

Systemd timers es la alternativa incluida en Debian, Ubuntu, Linux Mint y Fedora Workstation cuando el sistema usa systemd. Corre en Linux, cuesta 0 EUR y no requiere instalar nada extra si ya usas systemd. Su límite honesto es que no sirve en sistemas sin systemd, como contenedores mínimos sin init o WSL 1 antiguo.

En lugar de una línea, creas dos unidades: un .service que dice qué ejecutar y un .timer que dice cuándo. El calendario se escribe con OnCalendar y el sistema lo activa con systemctl.

Pasos exactos:

  1. Crea el servicio /etc/systemd/system/copia.service: con [Unit] Description=Copia diaria, [Service] Type=oneshot ExecStart=/home/usuario/bin/copia.sh y User=usuario si es servicio de sistema. Para timer de usuario, usa ~/.config/systemd/user/.
  2. Crea el timer /etc/systemd/system/copia.timer: [Unit] Description=Timer copia, [Timer] OnCalendar=--* 02:30:00 Persistent=true, [Install] WantedBy=timers.target. Persistent=true ejecuta al arrancar si se perdió la hora.
  3. Recarga y activa: sudo systemctl daemon-reload, sudo systemctl enable --now copia.timer. Comprueba con systemctl list-timers y systemctl status copia.timer.
  4. Depura con journalctl -u copia.service y journalctl -u copia.timer. Ahí ves salida, código de salida y si se solapó.
  5. Ajusta precisión con AccuracySec=1min en el timer si necesitas segundo exacto, o deja el valor por defecto para agrupar despertares y ahorrar energía.

Pros: control de dependencias (After=network-online.target), evita solapamiento con Conflicts o OnUnitActiveSec, logs centralizados en journalctl, y Persistent cubre apagones. Contras: dos archivos por tarea, sintaxis OnCalendar más larga que 5 campos, y diagnóstico exige conocer systemctl.

Método 3: cuando cron no basta

Hay dos huecos que cron puro no cubre: equipos que se apagan y la necesidad de saber si la tarea realmente corrió.

Anacron está pensado para portátiles y sobremesa que no están 24/7. No programa por minuto, programa por días. Lee /etc/anacrontab con formato periodo retraso identificador comando. Ejemplo: 1 5 copia-diaria /home/usuario/bin/copia.sh significa cada 1 día, con 5 minutos de retraso tras arrancar, ejecuta la copia si no se hizo en las últimas 24 horas. Corre en Linux, cuesta 0 EUR y viene en Debian, Ubuntu y Linux Mint. Su alternativa libre es el propio paquete anacron. Límite: precisión mínima de 1 día, no sirve para cada hora y necesita estar instalado y habilitado; en muchos sistemas ya lo llama cron diariamente.

Servicios cloud con heartbeat cubren el otro hueco: confirmación externa. El cron (local o en la nube) hace un ping HTTP al final del script y el servicio espera ese ping dentro de una ventana. Si no llega, avisa por correo o mensaje. Dos referencias son Healthchecks.io y Cronitor. Ambos corren en Linux y web, con plan gratuito limitado y pago por volumen de checks. Límite: dependes de internet y de custodiar la URL; si expones la URL, cualquiera puede falsificar el ping.

Escenario Método que funciona Dato concreto
Portátil que se apaga de noche y debe copiar a las 02:30 anacron con 1 5 ejecuta al encender con 5 min de retraso si perdió la ventana
Servidor 24/7 que debe correr cada 15 min sin solaparse systemd timer con OnCalendar=*:0/15 y Persistent=true ventana de 15 min, no duplica si la ejecución anterior sigue
Tarea crítica que debe avisar si no corrió cron + curl https://hc-ping.com/uuid timeout configurable, por ejemplo 10 min tras la hora esperada
Script cada minuto con aviso externo cron cloud con heartbeat frecuencia mínima 1 min, revisa límite de pings del plan gratuito

Elige anacron si tu problema es el apagón, y añade heartbeat si tu problema es enterarte del fallo desde fuera. Se pueden combinar: anacron o systemd dispara, y la última línea del script hace curl --retry 3 https://hc-ping.com/tu-uuid.

Qué hacer si la tarea no se ejecuta

Cuando cron no dispara, casi siempre es entorno, permisos o tiempo. Revisa en orden y con comandos que dejan rastro.

Errores frecuentes y cómo atacarlos:

  • PATH recortado: el script funciona en terminal pero no en cron porque python, node o aws no están en el PATH mínimo. Solución: declara PATH completo arriba del crontab o usa rutas absolutas /usr/bin/python3 /ruta/script.py.
  • Permisos: crontab -e de un usuario no puede escribir en /root/ ni leer claves de otro usuario. Prueba con sudo -u usuario /ruta/script.sh y ajusta chmod +x y propietario. En /etc/cron.d/ el archivo debe ser root 644.
  • Zona horaria: programas a las 02:30 y se ejecuta a otra hora porque el sistema está en UTC. Comprueba timedatectl y date. Si usas TZ en el crontab, esa variable solo afecta a ese archivo.
  • Solapamiento: la tarea tarda 10 minutos y cron la lanza cada 5, se pisan dos copias. Evita con flock -n /tmp/copia.lock /ruta/script.sh en cron o con systemd timer que no relanza si sigue activo.
  • Entorno de shell: cron usa sh por defecto. Si tu script es bash con [[, declara SHELL=/bin/bash arriba.

Checklist de comprobación:

  • ¿Está el servicio activo? ps aux | grep cron y systemctl status cron o crond. Para timers, systemctl list-timers --all y systemctl status copia.timer.
  • ¿Quedó cargado? crontab -l debe mostrar la línea y journalctl -u cron o grep CRON /var/log/syslog debe mostrar el intento con hora y usuario.
  • ¿Qué dijo el script? revisa tu >> /ruta/log.log 2>&1 y journalctl -u servicio si es timer. Si redirigiste a /dev/null, quítalo y vuelve a probar.
  • ¿Llegó el heartbeat? entra a Healthchecks.io o Cronitor y verifica el último ping. Si no llegó, el fallo está antes del curl final; añade curl --retry 3 --max-time 10 para descartar red.

Preguntas frecuentes sobre cron en Linux

1. ¿Qué es Crontab Guru y cómo funciona?

Crontab Guru es una herramienta web en crontab.guru que ayuda a construir y verificar la sintaxis de las expresiones cron. Puedes escribir tu secuencia de campos (minuto, hora, día, etc.) y la página interpreta en lenguaje natural cuándo se ejecutará tu tarea, lo que evita errores comunes al programar comandos en el servidor.

2. ¿Qué es el sistema de programación de tareas en Linux?

En Linux, el sistema de programación de tareas se basa en el demonio crond, que revisa el archivo /etc/crontab y la carpeta /etc/cron.d cada minuto para lanzar procesos. Este servicio es el encargado de ejecutar automáticamente las tareas definidas por el usuario o por el sistema sin intervención manual.

3. ¿Cómo puedo probar mis comandos cron desde un navegador?

Existen simuladores online que permiten comprobar la sintaxis de los comandos antes de subirlos al servidor. Puedes pegar tu cadena de texto en estos sitios para ver una lista de las próximas fechas de ejecución y corregir errores de formato de manera instantánea.

4. ¿Cómo genero la sintaxis correcta para mi crontab?

Puedes utilizar asistentes web para generar la sintaxis correcta. Estas herramientas suelen tener casillas o desplegables para seleccionar la frecuencia, como 'cada lunes a las 8:00', y generan la línea de código con los cinco asteriscos y valores numéricos necesarios para el archivo de configuración.

5. ¿Qué es una tarea programada en Linux?

Una tarea programada (o cron job) es un proceso que se ejecuta de forma automática y recurrente en segundo plano a la hora que tú definas. Para activarla, debes editar tu lista de tareas con el comando 'crontab -e' y añadir una línea que especifique la periodicidad y el script a ejecutar.

6. ¿Cómo veo la lista de tareas programadas que tengo activas?

Para ver las tareas programadas que están activas en tu sesión, ejecuta el comando 'crontab -l' en la terminal. Este comando muestra el contenido completo de tu archivo de configuración personal en la ruta /var/spool/cron/crontabs, lista que incluye tanto los comentarios como los comandos a ejecutar.

7. ¿Cuál es la sintaxis básica para definir una tarea en crontab?

La sintaxis básica consta de cinco campos numéricos para el tiempo (minuto, hora, día del mes, mes, día de la semana) seguidos del comando a ejecutar. Por ejemplo, una línea que diga '30 2 * /ruta/script.sh' significa que el script se ejecutará todos los días a las 2:30 de la madrugada.

8. ¿Dónde se guarda el archivo de configuración de mis tareas cron?

En la mayoría de distribuciones, el archivo personal del usuario se encuentra en /var/spool/cron/crontabs/ con el nombre del usuario. Los ajustes globales que afectan a todo el sistema están en /etc/crontab, el cual requiere permisos de superusuario para ser modificado.

Fuentes

  1. Man7cron(8) – Linux manual page – man7.orgconsultado el 22/09/2026
  2. MediumThe Linux Concept Journey — Cron – Mediumconsultado el 22/09/2026
  3. NareshitLinux Automation Using Cron Jobs Guide 2026 – NareshITconsultado el 22/09/2026
  4. XitoringBest Cronjob Monitoring Tools 2026 – Xitoringconsultado el 22/09/2026
  5. AskubuntuHow do I set up a Cron job? – Ask Ubuntuconsultado el 22/09/2026