Analizador de Expresiones Cron

Analizador de Expresiones Cron - Analizar y Explicar Programaciones Cron

Un potente analizador de expresiones Cron online que le ayuda a entender, validar y explicar expresiones de programación cron. Admite formatos Unix/Linux (5 campos) y Quartz (6-7 campos) con desglose detallado de campos y vista previa del próximo tiempo de ejecución. Perfecto para entender trabajos cron existentes y validar sintaxis cron.

¿Qué es una expresión cron y cómo se lee?

Una expresión cron es una cadena de 5 o 6 campos que define cuándo debe ejecutarse un trabajo recurrente. El cron Unix estándar tiene 5 campos: minuto (0-59), hora (0-23), día del mes (1-31), mes (1-12), día de la semana (0-6, domingo es 0 o 7). Muchos planificadores nuevos (Quartz, Spring, Jenkins, AWS EventBridge) añaden un 6º campo de segundos al frente y un 7º campo de año al final. La cadena "0 9 * * 1-5" significa "a las 09:00 de lunes a viernes." El carácter * significa "todos los valores," / significa "paso" (*/15 = cada 15), - significa rango (1-5), y , significa lista (1,3,5). El manual de Vixie cron es la referencia canónica para el formato original de 5 campos, RFC 4954 cubre alguna semántica de planificación, y los docs de Quartz cubren el dialecto extendido.

¿Cómo encuentro la próxima ejecución de una expresión cron?

Pegue la expresión en el analizador y lea la tarjeta "Próximas Ejecuciones": muestra las próximas 5-10 horas de disparo y una cuenta regresiva en vivo hasta la siguiente. Importante: primero elija la zona horaria correcta en el desplegable, porque esta herramienta calcula las horas de reloj coincidentes en la zona que seleccione (UTC, Asia/Tokyo, etc.), no se limita a reformatear un único instante, así que las ejecuciones previstas son correctas aunque su navegador esté en otra zona. Para verificar un horario antes de desplegar, cambie la zona a la que usa su servidor o clúster y confirme que las próximas ejecuciones caen donde espera. Las macros como @daily se expanden a 0 0 * * * y se previsualizan normalmente; @reboot no tiene hora de reloj (se ejecuta una vez al arrancar el daemon), así que muestra una nota de inicio en lugar de una lista.

¿Cuál es la diferencia entre */5 y 0/5 en el campo de minutos?

Ambos significan "cada 5 minutos comenzando desde 0," pero llegan ahí por rutas sintácticas distintas. */5 significa "paso 5 sobre todo el rango," produciendo 0, 5, 10, 15, ..., 55. 0/5 es la sintaxis extendida de Quartz/Spring que significa "comienza en 0, paso de 5," idéntico en resultado. Sin embargo, 3/5 significa explícitamente "comienza en 3 luego paso 5": 3, 8, 13, 18, ..., 58. El Vixie cron estándar no soporta sintaxis N/M (solo */M); si escribe 3/5 en un crontab Linux vainilla, fallará silenciosamente o se malinterpretará. Siempre compruebe si su runtime usa Vixie cron, croniter (Python), node-cron, Quartz o Spring — difieren exactamente en este rincón. AWS EventBridge en particular usa un formato de 6 campos tipo Quartz y semántica peculiar del día de la semana.

¿Por qué día del mes y día de la semana se interpretan como OR, no AND?

Esta es la regla cron más sorprendente. "0 0 13 * 5" NO significa "el 13 del mes Y solo en viernes" — significa "el 13 de cualquier mes, O cualquier viernes." Cuando ambos día-del-mes y día-de-la-semana están restringidos (ninguno es *), el Vixie cron clásico y la mayoría de descendientes los tratan como unión, no intersección. El BSD cron original usaba intersección, pero Vixie cron cambió deliberadamente a unión en 1992 para coincidir con expectativas de usuarios para cosas como "días laborables más el 1" ("0 9 1 * 1-5" = 9 AM en días laborables O el 1 de cualquier mes). Para obtener la intersección real (alertas de viernes 13), normalmente necesita una guarda dentro del trabajo mismo, o use el ? especial de Quartz en uno de los campos día para desambiguar. La especificación Quartz requiere que exactamente uno de día-del-mes/día-de-la-semana sea ? para hacerlo inequívoco.

¿Qué significan @reboot, @daily, @weekly, @yearly y @hourly?

Estos apodos son atajos definidos por Vixie cron para horarios comunes. @yearly (alias @annually) = 0 0 1 1 * (medianoche del 1 de enero). @monthly = 0 0 1 * * (medianoche del día 1). @weekly = 0 0 * * 0 (medianoche del domingo). @daily (alias @midnight) = 0 0 * * * (medianoche cada día). @hourly = 0 * * * * (en punto de cada hora). @reboot es especial: corre una vez al iniciar el daemon cron, normalmente al arrancar el sistema — útil para tareas de inicio de servicio pero poco fiable en entornos contenedorizados donde el daemon cron puede reiniciarse por otras razones. Los timers systemd y los Kubernetes CronJobs no soportan @reboot semánticamente. Algunos sabores también soportan @minutely (cada minuto) pero no es estándar.

¿Cómo ejecuto un trabajo cada 5 minutos entre 9 AM y 5 PM en días laborables?

La expresión es "*/5 9-17 * * 1-5" que significa cada 5 minutos (minuto 0, 5, 10, ..., 55) de las horas 9 a 17, cualquier día del mes, cualquier mes, lunes a viernes. Dos sutilezas: esto se dispara también a las 17:00, 17:05, ..., 17:55 — no solo a las 17:00. Para parar a las 17:00 en punto, use "*/5 9-16 * * 1-5" + "0 17 * * 1-5". Además, día-de-la-semana 1-5 es lunes-viernes en Linux cron, pero en Quartz y AWS EventBridge, domingo es 1 y sábado es 7, así que lunes-viernes es 2-6 — un bug de desfase frecuente. Pruebe siempre en su planificador objetivo. Los parsers cron en línea como el de esta página muestran los próximos 5-10 tiempos de ejecución para que pueda revisar la expresión visualmente.

¿Cuál es la diferencia entre cron, timers systemd y Kubernetes CronJobs?

Los tres planifican trabajos recurrentes pero con distintas garantías. El cron Unix clásico es simple, ubicuo, pero no tiene logging, ni seguimiento de dependencias, ni reintentos, y manda errores silenciosamente por email a root. Los timers systemd son el reemplazo Linux moderno: se integran con el journal (logs estructurados), soportan OnBootSec / OnCalendar (más rico que sintaxis cron), manejan ejecuciones perdidas (Persistent=true recupera si el sistema estaba apagado) y tienen dependencias de unidad. Los Kubernetes CronJobs usan una expresión cron tipo Quartz de 5 campos pero añaden concurrencyPolicy (Allow/Forbid/Replace), startingDeadlineSeconds y límites de historial éxito/fallo. Los planificadores cloud (AWS EventBridge, GCP Cloud Scheduler, Azure Logic Apps) añaden reintentos, colas de letra muerta y observabilidad. Para cualquier cosa más allá de un servidor de hobby, prefiera timers systemd o un planificador cloud sobre cron crudo.

¿Cuál es la diferencia entre L, W y # en expresiones cron Quartz?

Estas son extensiones Quartz no encontradas en el Vixie cron estándar. L significa "último": L en día-del-mes = el último día del mes (maneja 28/29/30/31 automáticamente), 5L en día-de-la-semana = el último viernes del mes. W significa "día laborable más cercano": 15W = el día laborable más cercano al 15 (si el 15 es sábado, dispara el viernes 14; si domingo, el lunes 16). LW combinado = el último día laborable del mes — útil para nóminas. # especifica la enésima ocurrencia: 2#3 en día-de-la-semana = el tercer martes del mes (ya que Quartz usa 1=Dom, 2=Lun, ..., 7=Sáb). Estas extensiones manejan reglas de negocio del mundo real ("segundo lunes de cada mes", "último día hábil para facturas") que el cron de 5 campos puro no puede expresar. AWS EventBridge soporta L y # pero no W.

¿Cómo afectan las zonas horarias a los horarios cron?

El Vixie cron clásico corre en la zona horaria local del sistema (variable TZ), lo que causa bugs dolorosos alrededor de las transiciones de horario de verano. En una zona con adelanto de primavera, los trabajos programados a las 02:30 simplemente no corren ese día. Con retraso de otoño, los trabajos a las 01:30 corren dos veces. Los timers systemd usan UTC por defecto salvo que OnCalendar especifique un TZ. Quartz y los Kubernetes CronJobs soportan ambos un campo zona horaria explícito (spec.timeZone en CronJob 1.27+) para que la misma expresión se comporte idéntica en todas las regiones. AWS EventBridge interpreta cron siempre en UTC; las expresiones rate(...) son independientes de zona horaria. Buena práctica: escriba todas las expresiones cron en UTC y convierta para visualización. Si debe usar hora local, evite las horas borde del horario de verano (02:00-03:00 en la mayoría de regiones); programe trabajos a las 04:00 o después.

Características Clave

• Analizar y explicar expresiones cron en lenguaje sencillo
• Soporte para formatos Unix/Linux (5 campos) y Quartz (6-7 campos)
• Detección automática de formato
• Desglose campo por campo con explicaciones detalladas
• Validación en tiempo real con mensajes de error
• Calcular y previsualizar próximos 5-10 tiempos de ejecución en cualquier zona horaria
• Macros de apodo cron: @daily, @hourly, @weekly, @monthly, @yearly, @reboot
• Ejemplos de expresión comunes para pruebas
• Entiende caracteres especiales: * , - / ? L (W y # se rechazan como no soportados)
• Soporte de nombres de mes y día (JAN-DEC, SUN-SAT)
• Copiar expresión al portapapeles
• 100% del lado del cliente - sin datos enviados al servidor
• Funciona offline después de la carga inicial
• Diseño responsive amigable con móviles
• Soporte de modo oscuro