Analisador cron

O `0 3 * * 1` no Actions “toda segunda às 3h” acordou o DBA às 0h em Brasília. Esta aba traduz a expressão — não liga o crontab e não escolhe o fuso do runner.

O backup “toda segunda às 3h” rodou quando o plantão ainda estava no ônibus. O trabalho desta página é ler a expressão cron nesta aba — cinco ou seis campos — e devolver uma descrição / próximas datas se a UI mostrar. Não SSH. Não dispara o Actions.

No Brasil o furo clássico é tratar o número como relógio de Brasília. Crontab do host, GitHub Actions e Cloud Scheduler cada um tem o próprio relógio. A aba usa o fuso do aparelho para “próxima vez”, se mostrar isso: o runner em UTC não muda porque você abriu o site em São Paulo.

UTC, Brasília e o Slack do DBA

• 0 3 * * 1 = minuto 0, hora 3, toda segunda — no fuso do interpretador.
• Actions e muitos containers: UTC. Brasília (America/Sao_Paulo) está em UTC−3 o ano todo desde o fim do horário de verão em 2019.
• Daily humana às 10h BRT → 0 13 * * 1-5 em UTC, salvo o YAML já pinte timezone.

Reunião com o time de produto: conversor de fusos. Log em epoch: timestamp.

Cinco campos, seis campos, o que colar

1. Cole minuto hora dia-do-mês mês dia-da-semana ou o sexto campo de segundos, se o destino for Quartz.
2. Leia a descrição. */15 no minuto não é “quinze horas”.
3. Confira o fuso no comentário do YAML ou no CRON_TZ do host — esta aba não lê o servidor.

Exemplo que costuma ir no Slack sem contexto:

0 3 * * 1

Sem a frase “UTC, segunda 00:00 em Brasília”, o próximo DBA herda o incidente.

O que o parser não faz

Não instala crontab. Não respeita L, W, # do Quartz se o motor for POSIX. Não garante que o Actions rode no minuto exato (fila, atraso, repo público inativo). Não é o scheduler da VPS.

Nada é enviado. A expressão no canal do Slack continua sendo só texto — o job de verdade mora no runner.