Una expresión cron estándar tiene cinco campos separados por espacios: minuto (0–59), hora (0–23), día del mes (1–31), mes (1–12) y día de la semana (0–6, donde 0 es domingo; la mayoría de implementaciones acepta también 7). Cada campo admite * para cualquier valor, comas para listas (1,15), guiones para rangos (1-5) y barras para intervalos (*/10 significa cada 10 unidades). Así, 0 9 * * 1-5 es a las 9:00 de lunes a viernes, */5 * * * * es cada cinco minutos y 0 0 1 * * es la medianoche del día 1 de cada mes. Si escribes seis campos, el primero se interpreta como segundos, formato habitual en planificadores de Node.js.
La herramienta traduce la expresión a lenguaje natural y muestra las próximas cinco ejecuciones reales para que confirmes la programación antes de desplegar. El error clásico es invertir minuto y hora: para ejecutar a diario a las 2:30 necesitas 30 2 * * *, no 2 30 * * * (inválido, porque la hora llega hasta 23). Otra trampa es que los intervalos se reinician dentro de su unidad: */45 * * * * se ejecuta en el minuto 0 y en el 45 de cada hora, así que la separación no es siempre de 45 minutos.
Cuidado al restringir a la vez el día del mes y el de la semana. En cron estándar (Vixie), si ninguno de los dos es *, la tarea se ejecuta cuando coincide cualquiera de ellos, no ambos. Por eso 0 0 13 * 5 se dispara el día 13 de cada mes y todos los viernes, no solo los viernes 13. Las plataformas con sintaxis Quartz (Java y algunos servicios en la nube) usan siete campos y ? para "sin valor específico", algo distinto de la sintaxis Unix de esta herramienta.
Las zonas horarias provocan más fallos que cualquier otra cosa. La herramienta muestra las ejecuciones en la zona horaria de tu navegador, pero los servidores, GitHub Actions y muchos planificadores en la nube usan UTC por defecto. Para las 9:00 en Madrid en horario de verano (UTC+2), un planificador en UTC necesita 0 7 * * *. Comprueba siempre la zona horaria de la plataforma de destino.