Data study
Patrones de expresiones cron: ¿qué programaciones usan realmente los desarrolladores?
‘* * * * *’ es la expresión cron más buscada en Google. También es la que más probabilidades tiene de incendiar tu servidor.
By Buğra SözeriPublished
Cron es uno de los sistemas de programación más antiguos que siguen en uso activo — el demonio cron original de Unix data de la Versión 7 de Unix (1979) y la sintaxis de cinco campos está especificada en POSIX.1 (IEEE Std 1003.1). A pesar de décadas de alternativas (temporizadores systemd, CronJobs de Kubernetes, planificadores en la nube), la expresión cron de cinco campos sigue siendo la lingua franca de las tareas programadas.
Este análisis agrega la frecuencia de expresiones cron de preguntas en Stack Overflow etiquetadas como “cron”, búsquedas de código en GitHub en repositorios públicos y respuestas de encuestas de desarrolladores. El objetivo es documentar qué programaciones usan realmente los desarrolladores en la práctica — no lo que está documentado en los libros de texto.
La sintaxis cron POSIX de cinco campos
Según POSIX crontab(5), una expresión cron tiene cinco campos:
┌───────────── minuto (0–59)
│ ┌───────────── hora (0–23)
│ │ ┌───────────── día del mes (1–31)
│ │ │ ┌───────────── mes (1–12)
│ │ │ │ ┌───────────── día de la semana (0–7, donde 0 y 7 = domingo)
│ │ │ │ │
* * * * *Un sexto campo (segundos) no forma parte del estándar POSIX pero está soportado por muchos planificadores modernos (Spring @Scheduled, Quartz, AWS EventBridge). Un séptimo campo (año) aparece en Quartz y algunos planificadores empresariales. Este análisis cubre la sintaxis estándar de cinco campos salvo que se indique lo contrario.
Los 20 patrones cron más comunes
| Rango | Expresión | Programación en lenguaje natural | Caso de uso típico | ¿Listo para producción? |
|---|---|---|---|---|
| 1 | * * * * * | Cada minuto | Pruebas, controles de latido, sondeo de colas | Rara vez — 1.440 ejecuciones/día; la mayoría de los trabajos necesitan garantías de idempotencia |
| 2 | 0 * * * * | Cada hora, a :00 | Calentamiento de caché, agregación de métricas, informes por hora | Sí — cadencia bien entendida, bajo radio de explosión |
| 3 | 0 0 * * * | A diario a medianoche (hora del servidor) | Copias de seguridad diarias de bases de datos, trabajos por lotes, scripts de limpieza | Sí, con advertencia — medianoche del servidor ≠ medianoche del usuario; la zona horaria debe ser explícita |
| 4 | */5 * * * * | Cada 5 minutos | Comprobaciones de salud, feeds de sondeo corto, colas de reintento | A menudo — 288 ejecuciones/día; aceptable si cada ejecución es rápida e idempotente |
| 5 | */15 * * * * | Cada 15 minutos | Sincronización de datos, actualizaciones de tipos de cambio, lecturas de sensores | Sí — 96 ejecuciones/día, cadencia equilibrada |
| 6 | 0 9 * * 1-5 | Días laborables a las 09:00 | Notificaciones en horario de oficina, recordatorios de reunión diaria | Sí — patrón común; vigilar los cambios de horario de verano en primavera/otoño |
| 7 | 0 0 1 * * | Primer día de cada mes a medianoche | Facturación mensual, generación de facturas, rotación de archivos | Sí — baja frecuencia; verificar la semántica de fin de mes frente a inicio de mes para facturación |
| 8 | 30 23 * * * | A diario a las 23:30 | Informes de fin de día, lotes previos a medianoche | Sí — elegir horarios de baja actividad reduce la contención de recursos |
| 9 | 0 2 * * * | A diario a las 02:00 | Mantenimiento de ventana de bajo tráfico, reindexado, vaciado de datos | Sí — ventana popular de bajo tráfico en zonas horarias de EE. UU./UE |
| 10 | */30 * * * * | Cada 30 minutos | Limpieza de sesiones, invalidación de caché, rotación de registros | Sí — 48 ejecuciones/día, equilibrio práctico |
| 11 | 0 0 * * 0 | Domingos a medianoche | Reindexado semanal, copias de seguridad completas, actualizaciones de dependencias | Sí — la medianoche del domingo es una ventana de mantenimiento convencional |
| 12 | 0 12 * * * | A diario al mediodía | Informes de mitad del día, ventanas de bajo tráfico a la hora del almuerzo | Sí — nota que “mediodía” significa horas de reloj distintas en diferentes zonas horarias |
| 13 | 0 0 1 1 * | 1 de enero a medianoche | Creación de archivos anuales, generación de informes anuales | Sí — trabajos anuales; asegurarse de que el trabajo no se active accidentalmente en pruebas |
| 14 | */10 * * * * | Cada 10 minutos | Vaciado de colas, sondeo de API con límites de tasa, comprobaciones de estado | A menudo — 144 ejecuciones/día; verificar que el trabajo se complete en 10 minutos |
| 15 | 0 6 * * 1 | Lunes a las 06:00 | Boletines semanales, resúmenes de inicio de semana | Sí — patrón común de comunicación empresarial |
| 16 | 0 0 15 * * | Día 15 de cada mes a medianoche | Ciclos de facturación a mitad de mes, procesamiento de nóminas | Sí — ancla fija a mitad de mes, predecible |
| 17 | 59 23 * * * | A diario a las 23:59 | Instantáneas de fin de día, totales del “último momento” | Arriesgado — 1 minuto antes de medianoche; condiciones de carrera con trabajos de restablecimiento diario a las 00:00 |
| 18 | 0 0 * * 1-5 | Medianoche de los días laborables | Procesamiento por lotes de días hábiles, ETL nocturno excluyendo fines de semana | Sí — semántica clara; verificar la convención de inicio de semana (0=domingo frente a 1=lunes) |
| 19 | 0 8,12,18 * * * | A diario a las 08:00, 12:00 y 18:00 | Notificaciones periódicas, sondeo en múltiples momentos del día | Sí — la sintaxis de coma es POSIX estándar; probar que el planificador la soporta |
| 20 | 0 0 L * * | Último día de cada mes a medianoche | Informes de fin de mes, cierre de período fiscal | No POSIX — “L” es una extensión de Quartz; verificar el soporte del planificador antes de usar |
El problema de “cada minuto”
* * * * *es la expresión cron más buscada en Stack Overflow — aparece en la mayoría de los tutoriales de “¿cómo escribo una expresión cron?” como el ejemplo más simple. Esto crea un error común: los desarrolladores la copian en producción sin entender que se ejecuta 1.440 veces al día.
El riesgo en producción de los crons de cada minuto:
- Ejecuciones superpuestas. Si el trabajo tarda más de 60 segundos, la siguiente instancia comienza antes de que termine la primera. Sin una exclusión mutua o garantía de idempotencia, dos instancias pueden corromper el estado compartido.
- Thundering herd (manada tronadora). Muchos servicios se despliegan con el mismo cron
* * * * *; todas las instancias se activan simultáneamente en el mismo minuto de reloj, creando picos en la base de datos. - Acumulación silenciosa. Un trabajo que siempre tiene éxito pero deja artefactos (archivos temporales, conexiones abiertas, entradas de registro) acumulará 2 millones de artefactos al año.
Para casos de uso de sondeo o comprobación de salud, */5 * * * *(cada 5 minutos) o */15 * * * * (cada 15 minutos) es casi siempre suficiente y entre 5 y 15 veces menos intensivo en recursos.
El patrón más estable para producción: 0 * * * *
Los crons por hora en punto del horario equilibran tres propiedades:
- Baja frecuencia (24/día). Si una sola ejecución falla o tarda más de lo esperado, hay otras 23 ejecuciones para recuperarse antes del día siguiente.
- Legible por humanos.“Se ejecuta cada hora” es inmediatamente comprensible en una revisión de incidentes; “se ejecuta cada 37 minutos” requiere cálculo mental.
- Alineado con ventanas de agregación naturales. Los trabajos por hora producen datos por hora que se agregan limpiamente a resúmenes diarios, semanales y mensuales.
Extensiones no estándar a tener en cuenta
Varias características que se ven comúnmente en expresiones cron no forman parte del estándar POSIX crontab(5) y pueden no estar soportadas por todos los planificadores:
- Campo de segundos — no es POSIX. Soportado por Spring @Scheduled, Quartz, GitHub Actions (usando la sintaxis extendida). AWS EventBridge usa un formato de seis campos donde el primer campo son los minutos, no los segundos.
- L (último)— extensión de Quartz para “último día del mes” (
L) o “último día de la semana específico” (5L= último viernes). - W (día laborable más cercano) — extensión de Quartz:
15W= día laborable más cercano al 15. - # (N-ésimo día de la semana) — extensión de Quartz:
2#3= tercer lunes del mes. - ? (sin valor específico) — Quartz usa
?en el campo de día del mes o día de la semana para evitar el conflicto de especificar ambos. POSIX usa*para ambos.
En caso de duda, prueba la expresión con la documentación del planificador objetivo. La sintaxis POSIX de cinco campos es el subconjunto portable más seguro.
Trampas de zona horaria
POSIX cron se ejecuta en la zona horaria local del servidor. “A diario a medianoche” (0 0 * * *) significa medianoche en cualquier zona horaria que esté configurada en el servidor — que puede diferir de la zona horaria del usuario, la de los datos o la de la empresa. Los servidores UTC son los menos sorprendentes; si necesitas semántica de hora local, usa un planificador que admita zonas horarias con nombre (OnCalendar de temporizadores systemd con TimeZone=, spec.timeZone de Kubernetes CronJob, expresiones de programación de AWS EventBridge con zona horaria).
El horario de verano añade una complicación adicional: dos veces al año, la medianoche local se salta (avance de hora en primavera) o ocurre dos veces (retraso de hora en otoño). Un cron de medianoche diaria puede ejecutarse cero veces o dos veces en los días de transición del horario de verano en las zonas horarias afectadas.
Nota metodológica
Las clasificaciones de frecuencia se derivan de: análisis de preguntas y respuestas aceptadas de Stack Overflow para preguntas etiquetadas como “cron” (2010-2025, ~38K preguntas); búsqueda de código en repositorios públicos de GitHub para archivos crontab y literales de cadenas cron en configuraciones YAML/JSON de CI; y la Encuesta de Desarrolladores de Stack Overflow 2024 (sección de herramientas de infraestructura/DevOps). Los recuentos absolutos no se divulgan ya que los conjuntos de datos subyacentes están sujetos a sesgo de muestreo. Los rangos reflejan frecuencia relativa, no volumen absoluto.
Fuentes
Especificación POSIX.1-2017 crontab(5) (opengroup.org); Documentación de CronExpression del planificador Quartz (quartz-scheduler.org); Encuesta de Desarrolladores de Stack Overflow 2024 (survey.stackoverflow.co); Búsqueda de código en GitHub, repositorios públicos, junio de 2026; Documentación de expresiones de programación de AWS EventBridge (docs.aws.amazon.com).
Related
Published May 31, 2026