Convierte la intención en una regla de AWS
Un horario de AWS puede ser válido y aun así representar una intención operativa equivocada. Antes de crear un recurso, escribe el requisito como regla de calendario: minuto y hora, días válidos, zona horaria y años. Después decide si el destino es EventBridge Scheduler o una regla programada heredada. El generador cron de AWS mantiene esas decisiones junto a las fechas calculadas. Funciona en local y no necesita cuenta ni credenciales de AWS.
Una tabla de revisión útil tiene seis columnas: minuto 0–59, hora 0–23, día del mes 1–31, mes 1–12 o JAN–DEC, día semanal 1–7 o SUN–SAT y año 1970–2199. Pon ? en la columna de día no usada. Al migrar, Unix 0 9 * * 1-5 se convierte en AWS cron(0 9 ? * MON-FRI *); el ? aporta significado.
Verifica un ejemplo fijo de último viernes
Usa un caso fijo: cron(15 10 ? * 6L 2026-2027), EventBridge Scheduler, UTC, después de 2026-09-18T00:00:00Z. Las tres primeras coincidencias son 2026-09-25T10:15:00.000Z, 2026-10-30T10:15:00.000Z y 2026-11-27T10:15:00.000Z. 6L indica el último viernes con la numeración de AWS y ? deja sin especificar el día del mes. El instante inicial no se incluye. Es un ejemplo comprobable con cualquier calendario.
Añade dos casos. cron(0/15 * * * ? *) después de las 10:00 UTC produce 10:15, 10:30 y 10:45; es un patrón de calendario, no un temporizador desde el despliegue. cron(0 8 1 * ? *) después de 2026-07-01T08:00:00Z produce 1 de agosto, septiembre y octubre a las 08:00 UTC. Las fechas esperadas hacen visibles los fallos.
Revisa el horario en un orden repetible
Elige primero el servicio. Scheduler admite una zona IANA; las reglas heredadas usan UTC. Introduce minuto, hora, día del mes, mes, día de la semana y año. Pon ? en exactamente un campo de día, calcula y revisa varias coincidencias, incluidos cambios de mes. Compara hora local, desplazamiento e instante UTC. Copia cron(...) solo cuando concuerde con el requisito. En AWS configura aparte destino, rol, ventana flexible, reintentos y cola de errores.
Prueba los días especiales por separado. En UTC después de 2026-08-01T00:00:00Z, cron(0 9 1W * ? *) elige el lunes 3 de agosto: el día 1 es sábado y el día de lunes a viernes debe permanecer en agosto. Para cron(0 9 ? * TUE#2 *), las fechas siguientes son 11 de agosto, 8 de septiembre y 13 de octubre. No se admiten listas con varias reglas #.
Entiende los seis campos y operadores
Cron Unix suele usar cinco campos y combina los días según su implementación. AWS exige seis y termina con un año entre 1970 y 2199. Admite nombres de meses y días. L expresa una regla de último día, nW el laborable más cercano a un día del mes y n#k la k-ésima aparición semanal. La herramienta admite L aislada como sábado y 6L como último viernes. Rechaza combinaciones ambiguas en lugar de inventar su significado.
Lee cada campo como un conjunto. La barra define incrementos dentro del campo, no un intervalo transcurrido. Un rango de horas 20-2 cubre noche y madrugada. Los nombres facilitan la revisión y la copia normaliza a mayúsculas. L en día del mes significa el último día; una L sola significa sábado únicamente en día de la semana; 6L significa el último viernes. nW busca el día de lunes a viernes más cercano. LW, desplazamientos de L y listas de operadores especiales quedan fuera del subconjunto de este simulador.
Diagnostica expresiones plausibles pero erróneas
Un error grave es copiar cinco campos Unix y añadir otro por intuición. Traduce el requisito. Otro es definir reglas en ambos campos de día: AWS obliga a usar ? en uno. Tampoco son válidas listas con varias expresiones #. Un resultado vacío no siempre implica sintaxis errónea. La búsqueda cubre cinco años; una expresión con 2199 puede ser válida y no mostrar fechas desde 2026.
Si el resultado sorprende, simplifica: cambia el año por *, usa UTC y sustituye temporalmente el día especial por un valor sencillo. Restaura después cada restricción. Comprueba si se excluyó el instante inicial, si el año cae dentro de los próximos cinco y si ? aparece exactamente en un campo de día. Así separas un límite de horizonte de un error de campo o zona.
Separa zonas, cambio horario y precisión
Scheduler evalúa la hora civil de la zona indicada. Si una hora no existe durante el salto de primavera, omite esa ejecución; en la hora repetida de otoño invoca una sola vez. Las reglas heredadas permanecen en UTC, por lo que su relación con la hora de una ciudad cambia según la estación. AWS habla de precisión de minuto: programar 10:15 no promete un milisegundo exacto. Las ventanas flexibles y la entrega son configuraciones independientes.
Para Madrid, prueba cron(30 2 * * ? *) con Scheduler. El 29 de marzo de 2026, 02:30 no existe y se omite. El 25 de octubre, 02:30 aparece dos veces en el reloj, pero Scheduler invoca una vez en la primera. Como regla heredada, UTC no tiene salto ni repetición; la representación de Madrid cambia con el desplazamiento estacional.
Qué no puede demostrar una previsualización local
Esta página simula el calendario; no prueba un despliegue de AWS. Acepta 256 caracteres, devuelve hasta diez coincidencias y se detiene tras cinco años. No comprueba permisos IAM, payloads, cuotas, reintentos, latencia, disponibilidad ni idempotencia. Los instantes son coincidencias esperadas del calendario, no pruebas de que AWS haya aceptado el recurso o de que el destino recibiera un evento.
AWS documenta precisión de 60 segundos. Una fila 10:15 identifica el minuto, no garantiza latencia. Scheduler también puede aplicar una ventana flexible y la entrega puede reintentarse; la herramienta no modela esas opciones. Si el proceso exige exactitud, haz el destino idempotente y observa registros reales en vez de tratar las filas como ejecuciones.
Conserva evidencias junto a la expresión
Guarda expresión, servicio, zona, instante de referencia y fechas esperadas en la revisión. Comprueba una semana normal, un límite de mes, el operador especial y un cambio horario cuando uses zona local. Revisa el año. En consola o infraestructura como código confirma expresión y zona, prueba el destino y observa métricas. Enlaza la guía de cron Unix al documentar una migración.
Antes de activar, pide que otra persona derive las tres primeras fechas. Prueba un mes cuyo día 1 sea fin de semana para W, un mes con cinco días candidatos para # o L y un cambio horario. Confirma que la infraestructura conserva la zona. Tras desplegar, usa un destino inocuo, revisa métricas y destino de errores y documenta quién puede revertir.
Una revisión final debe distinguir tres relojes: la hora escrita en la regla, la hora civil que interpreta Scheduler y el instante UTC que queda registrado. Para una regla heredada solo intervienen la expresión UTC y su representación posterior. Si el equipo usa nombres como MON o JAN, conserva también una versión legible del requisito; si usa números, documenta la correspondencia. Repite la prueba cuando cambie la zona configurada o el rango de años, porque ambas decisiones alteran el conjunto de fechas sin cambiar necesariamente minuto y hora.
Fuentes: Tipos de horario de AWS EventBridge Scheduler y Patrones de reglas programadas de AWS EventBridge.