Expresiones Cron Una referencia práctica con ejemplos reales

Una expresión cron es un conjunto de cinco campos separados por espacios que indican a un scheduler Unix cuándo ejecutar un comando. Cinco campos, un par de caracteres especiales y algunos patrones comunes — eso es todo el modelo mental. Esta referencia cubre la sintaxis, los caracteres que confunden a las personas y los horarios que realmente utilizan los desarrolladores.

Los Cinco Campos

Cron estándar utiliza cinco campos posicionales:

* * * * *
│ │ │ │ └─ Day of week   (0–7, Sunday = 0 or 7)
│ │ │ └─── Month         (1–12)
│ │ └───── Day of month  (1–31)
│ └─────── Hour          (0–23)
└───────── Minute        (0–59)

AWS EventBridge y el scheduler Quartz de Java añaden un segundos campo al principio, haciendo un total de seis campos. Todos los demás campos se desplazan a la derecha. Esto confunde a los desarrolladores que pasan entre entornos — una expresión Quartz pegada en un crontab estándar se ejecutará en un horario incorrecto sin ninguna advertencia.

Siga utilizando cron POSIX de cinco campos a menos que su plataforma requiera explícitamente seis.

Caracteres Especiales

Carácter	Significado	Ejemplo
*	Cualquier valor — coincidir con cada unidad	* * * * * — cada minuto
,	Lista de valores	0 9,17 * * * — a las 9 de la mañana y a las 5 de la tarde
-	Rango	0 9-17 * * * — cada hora entre las 9 de la mañana y las 5 de la tarde
/	Intervalo de paso	*/15 * * * * — cada 15 minutos
?	Sin valor específico (solo Quartz/AWS)	0 0 15 * ? — el 15 de cada mes, cualquier día de la semana
L	Último (solo Quartz/AWS)	0 0 L * ? — último día de cada mes
W	Día más cercano (solo Quartz/AWS)	0 0 15W * ? — día más cercano al 15

Estándar crontab solo reconoce *, ,, -y /. Si ves ?, L, o W en una expresión, fue escrita para Quartz o AWS EventBridge — no la pegues directamente en un crontab de Linux sin modificarla.

La tabla de referencia: horarios que realmente utilizan los desarrolladores

Esta es la parte que vale la pena bookmarkear. Crea y valida cualquier expresión de este tipo con el Generador de expresiones cron IO Tools.

Descripción	Expresión cron	Notas
Cada minuto	* * * * *	Rara vez adecuada en producción
Cada 5 minutos	*/5 * * * *	Verificaciones de salud, ciclos de consulta cortos
Cada 15 minutos	*/15 * * * *	Calentamiento de caché, sincronización de feeds
Cada 30 minutos	*/30 * * * *	Equivalente a 0,30 * * * *
Cada hora (a las horas exactas)	0 * * * *	Ejecuta a las :00 de cada hora
Cada 6 horas	0 */6 * * *	Sincronización de datos, exportaciones incrementales
Diaria a medianoche UTC	0 0 * * *	Desencadenador diario estándar
Diaria a las 9 de la mañana UTC	0 9 * * *	Generación de informes matutinos
Días laborables a las 9 de la mañana UTC	0 9 * * 1-5	Tareas durante horarios laborales (lunes a viernes)
Días laborables a las 8:30 UTC	30 8 * * 1-5	Entrega de informes previos a la reunión
Cada domingo a las 2 de la mañana	0 2 * * 0	Mantenimiento semanal, copias de seguridad fuera de pico
Primer día de cada mes	0 0 1 * *	Ejecuciones mensuales de facturación, informes recurrentes
El 1 de enero a medianoche	0 0 1 1 *	Reinicios anuales, tareas al inicio del año

El problema del horario

Cron no tiene conciencia de zona horaria. Se ejecuta en la zona horaria configurada en el servidor — en la mayoría de los sistemas Linux, eso es UTC. Esto generalmente está bien hasta que tienes tareas vinculadas a horarios laborales o usuarios en múltiples regiones que se preguntan por qué el “informe a las 9” llega a las 2 de la tarde.

Los valores más seguros:

• Configure su servidor en UTC. Convierta a la hora local en la lógica de la aplicación, no en el cron.
• Comente cada tarea cron con la hora local efectiva, para que la siguiente persona que lea el crontab no tenga que adivinar.
• Al usar schedulers en la nube (AWS EventBridge, Google Cloud Scheduler), verifique el campo de zona horaria — la mayoría de ellos soportan directamente nombres de zonas IANA, lo que elimina la ambigüedad.

# Always comment with the effective local time
# Runs daily at midnight UTC (= 8pm EST / 5pm PST)
0 0 * * * /usr/bin/python3 /opt/scripts/daily_report.py

Pruebas: Calcule las próximas ejecuciones antes de desplegar

Desplegar una tarea cron para descubrir que se ejecuta cada minuto en lugar de cada hora es una tradición. Salte esta situación.

El Calculadora IO Tools de próximas ejecuciones cron muestra exactamente cuándo se ejecutará la siguiente vez tu expresión — pega tu expresión y obtén las próximas diez ejecuciones antes de tocar un servidor.

Para validación en línea de comandos:

# Install croniter (Python) for quick expression testing
pip install croniter

python3 -c "
from croniter import croniter
from datetime import datetime

cron = croniter('*/15 * * * *', datetime.utcnow())
for _ in range(5):
    print(cron.get_next(datetime))
"

Agregar una tarea cron en Linux

# Open the crontab editor for the current user
crontab -e

# Format: minute hour day month weekday command
# Run backup script daily at 2:30am UTC
30 2 * * * /home/user/scripts/backup.sh >> /var/log/backup.log 2>&1

# Run a Python script every 5 minutes
*/5 * * * * /usr/bin/python3 /home/user/scripts/sync.py

# View current crontab entries
crontab -l

# Edit another user's crontab (requires root)
crontab -u www-data -e

El 2>&1 al final de la línea de backup redirige stderr a stdout, así que ambos flujos van al archivo de log. Sin ello, los errores de cron van al spool de correo — y nadie los revisa.

Flujo programado de GitHub Actions

GitHub Actions utiliza la misma sintaxis de cinco campos cron, siempre en UTC. No hay sobrecarga de zona horaria.

name: Nightly Data Export

on:
  schedule:
    # Runs at 1:00 AM UTC every weekday
    - cron: "0 1 * * 1-5"
  workflow_dispatch: # Allow manual trigger

jobs:
  export:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run export script
        run: python scripts/export.py

Una advertencia: los flujos programados de GitHub Actions pueden ser retrasados hasta 15 minutos durante periodos de alta carga. No dependas de ellos para tareas que requieran un tiempo preciso.

Cuando el cron no es suficiente

El cron estándar atiende la mayoría de los casos en un solo servidor. Sus limitaciones se convierten en problemas a escala:

• Sin reintentos en caso de fallo. Si la tarea falla, la próxima ejecución será el siguiente horario programado — no hay reintentos automáticos.
• Sin bloqueo distribuido. Varios servidores ejecutando el mismo crontab lanzarán la misma tarea simultáneamente.
• Sin observabilidad. No hay un panel integrado para historial de ejecuciones, alertas de fallos o seguimiento del tiempo de ejecución.

Problema	Alternativa mejor
Lógica de reintentos y colas de tareas	Celery Beat (Python), Sidekiq-Cron (Ruby)
Programación nativa en la nube con reintentos	AWS EventBridge + Lambda, Google Cloud Scheduler
Desencadenadores de pipelines CI/CD	Programaciones de GitHub Actions
Orquestación observable de tareas	Airflow, Prefect, Temporal

Para scripts en un solo servidor, cron sigue siendo la herramienta adecuada — es simple, confiable y tiene cero dependencias. Para cualquier cosa que necesite garantías de reintentos, ejecución distribuida o visibilidad de fallos, una cola de tareas dedicada se justifica rápidamente.

Utiliza el Generador de expresiones cron para construir tu próxima programación sin tener que memorizar la sintaxis, y el Calculadora de próximas ejecuciones cron para verificar que se ejecute cuando esperas.

También te puede interesar