Gerador de Cron

Como funcionam os 5 campos?

São cinco campos no cron: minuto (0-59), hora (0-23), dia do mês (1-31), mês (1-12) e dia da semana (0-6, 0=dom). Em cada um cabem números, listas (1,2,3), faixas (1-5), passos (*/15) e o * (qualquer valor).

Na prática, 0 9 * * 1-5 dispara às 9h nos dias úteis, enquanto */15 * * * * roda a cada 15 minutos.

Comece pelos presets e ajuste o que precisar à mão.

Expressões cron em profundidade: sintaxe, variantes e agendamento real

Uma expressão cron é uma linguagem compacta baseada em tempo usada para descrever quando um job recorrente deve rodar. Introduzida na 7ª edição do Unix em meados da década de 1970, a sintaxe sobreviveu praticamente inalterada por meio século e hoje aparece em distribuições Linux, orquestradores de contêineres como Kubernetes, plataformas de CI como GitHub Actions e schedulers serverless como AWS EventBridge e Vercel Cron. Apesar da semelhança superficial, cada plataforma interpreta os mesmos cinco (ou seis, ou sete) números de uma forma ligeiramente diferente — e errar um dígito é a diferença entre um backup que roda às 3h da manhã e um que roda a cada minuto do dia.

Este gerador emite o formato Unix clássico. Abaixo você encontra uma referência completa de campos, operadores, strings especiais, diferenças de dialeto (Quartz, Spring, Kubernetes, GitHub Actions), exemplos comentados e as armadilhas de timezone/horário de verão que pegam até engenheiros experientes.

Os cinco campos do cron Unix padrão

Uma linha canônica do crontab tem cinco campos separados por espaços, lidos da esquerda para a direita:

┌──────── minuto         (0-59)
│ ┌────── hora           (0-23)
│ │ ┌──── dia do mês     (1-31)
│ │ │ ┌── mês            (1-12 ou JAN-DEC)
│ │ │ │ ┌ dia da semana  (0-7 ou SUN-SAT; 0 e 7 = domingo)
│ │ │ │ │
* * * * * comando-a-executar

A expressão dispara quando todos os campos casam com o relógio atual — com uma exceção famosa descrita mais abaixo. Alguns schedulers acrescentam um sexto campo de segundos no início, e o Quartz acrescenta um sétimo campo de ano no final; os daemons de Linux e BSD operam apenas com resolução de um minuto.

Curingas, intervalos, listas e passos

• * — qualquer valor válido (todo minuto, toda hora, etc.).
• a-b — intervalo inclusivo. 9-17 no campo de hora significa 9, 10, 11, 12, 13, 14, 15, 16, 17.
• a,b,c — lista discreta. 0,15,30,45 casa com os quartos de hora.
• */n — passo de n unidades. */5 em minutos roda em 0, 5, 10, … 55.
• a-b/n — intervalo com passo. 0-23/2 em horas significa de duas em duas horas a partir da meia-noite.
• Mês e dia-da-semana aceitam abreviações de três letras: JAN-DEC, SUN-SAT. Os nomes ignoram maiúsculas/minúsculas, mas em algumas implementações não podem ser combinados em intervalos.

Strings de conveniência: @yearly, @monthly, @daily, @hourly, @reboot

O Vixie cron e a maioria dos seus descendentes modernos aceitam atalhos nomeados que se expandem em uma expressão completa de cinco campos:

@yearly   (ou @annually) → 0 0 1 1 *   meia-noite em 1º de janeiro
@monthly                  → 0 0 1 * *   meia-noite no dia 1 de cada mês
@weekly                   → 0 0 * * 0   meia-noite de domingo
@daily    (ou @midnight)  → 0 0 * * *   meia-noite, todo dia
@hourly                   → 0 * * * *   no minuto 0 de cada hora
@reboot                   → ao iniciar o daemon cron (sem hora)

Observação: @reboot não é suportado pelo CronJob do Kubernetes, pelo GitHub Actions nem pelos systemd timers — é uma característica específica do daemon cron.

Diferenças de dialeto: Quartz, Spring, Kubernetes, GitHub Actions

A maior fonte de bugs em agendamentos é supor que todos os schedulers leem a mesma string da mesma forma. Referência rápida:

• Cron Unix / Vixie: 5 campos, dia-da-semana 0-7 (domingo é tanto 0 quanto 7), resolução de um minuto, semântica OR entre dia-do-mês e dia-da-semana.
• Quartz (Java): 6 ou 7 campos — segundos no início, ano opcional no fim. Dia-da-semana vai de 1 a 7, com domingo = 1. Suporta L (last), W (dia útil mais próximo), # (n-ésima ocorrência) e ? (nenhum valor específico).
• Spring @Scheduled: 6 campos (segundos + os 5 padrão). Domingo é 0 como no Unix, e não 1 como no Quartz — armadilha comum ao portar expressões.
• Kubernetes CronJob: 5 campos padrão. Os horários são UTC a menos que você defina .spec.timeZone (k8s 1.25+). Prefixos CRON_TZ= são rejeitados pela validação.
• GitHub Actions: 5 campos padrão, apenas em UTC, sem parâmetro de timezone. O menor intervalo é de 5 minutos e períodos de alta carga podem atrasar ou pular execuções.
• AWS EventBridge: 6 campos (ano obrigatório), dia-da-semana 1-7 (domingo = 1), usa ? como o Quartz e não permite especificar dia-do-mês e dia-da-semana ao mesmo tempo.

Exemplos comentados

*/5 * * * *      a cada 5 minutos
0 * * * *        no minuto 0 de cada hora (em ponto)
30 2 * * *       todo dia às 02:30
0 3 * * 1        toda segunda-feira às 03:00
0 0 1 * *        meia-noite do dia 1º de cada mês
0 9-17 * * 1-5   a cada hora das 09:00 às 17:00, seg-sex
15 14 1 * *      14:15 do dia 1º de cada mês
0 22 * * 1-5     todo dia útil às 22:00
0 0 */2 * *      meia-noite a cada dois dias
*/15 9-17 * * 1-5 a cada 15 min das 09:00-17:59, dias úteis
0 0 1 1 *        uma vez por ano, 1º de janeiro à meia-noite
5 4 * * sun      todo domingo às 04:05

Armadilhas: semântica OR, timezone e horário de verão

Dia-do-mês e dia-da-semana são combinados com OR, não com AND. A expressão 0 0 13 * 5 dispara no dia 13 de todo mês e em toda sexta-feira — não apenas em sextas-feiras dia 13. Para ter um AND real, restrinja um dos campos na expressão e cheque o outro dentro do seu script, ou use Quartz/AWS, que interpretam um valor literal junto com ? de outra forma.

Timezone. O cron do Linux respeita a variável TZ do sistema; é possível sobrescrever por crontab com a linha CRON_TZ=America/Sao_Paulo. O Kubernetes usa UTC por padrão. O GitHub Actions é UTC sem exceção — se você quer 09:00 em São Paulo (BRT, UTC-3), escreva 0 12 * * *.

Horário de verão. Quando o relógio adianta, os jobs da hora pulada normalmente se perdem; quando atrasa, os jobs da hora repetida podem rodar duas vezes. O Vixie cron moderno tenta evitar ambos os casos, mas o caminho mais seguro é agendar fora da janela entre 01:00 e 04:00 ou rodar em UTC.

O corpo do job. O cron executa comandos com um PATH mínimo e sem shell interativo. Sempre use caminhos absolutos para os binários e redirecione stdout/stderr (>> /var/log/job.log 2>&1) para que as falhas sejam depuráveis.

Onde rodar um agendamento

• crontab em um único host Linux — crontab -e por usuário.
• systemd timers — sintaxe de calendário (incompatível com cron) com logging melhor, grafo de dependências e persistência entre boots.
• Kubernetes CronJob — YAML declarativo, com política de concorrência e budget de retentativas.
• GitHub Actions on.schedule — jobs disparados pelo CI, apenas em UTC e com granularidade mínima de 5 minutos.
• Vercel Cron / Netlify Scheduled Functions — invocam um endpoint HTTPS a partir de um scheduler gerenciado.
• AWS EventBridge / GCP Cloud Scheduler — gatilhos nativos da nuvem com retry e fila de dead-letter.

FAQ

O cron consegue rodar jobs em frequência menor do que um minuto? O cron Unix padrão não consegue. Para agendamento abaixo de um minuto, use Quartz, um systemd timer com OnUnitActiveSec=30s ou um pequeno loop dentro do próprio script.

Qual a diferença entre 0 e * no campo de minuto? 0 dispara só no minuto zero; * dispara em todo minuto. 0 * * * * é de hora em hora; * * * * * é de minuto em minuto (sessenta vezes por hora).

Por que meu job rodou duas vezes? Causas comuns: retorno do horário de verão, dois daemons cron (sistema + usuário) lendo o mesmo arquivo, ou uma execução anterior que excedeu o intervalo e se sobrepôs — proteja com flock para impedir execuções concorrentes.

O @reboot garante que meu job rode a cada boot? Apenas se o daemon cron iniciar depois das condições que o seu script precisa (rede, mounts). Em Linux moderno, prefira uma unit do systemd com After=network-online.target.

Existe um jeito de testar uma expressão antes de colocar em produção? Sim — cole a expressão em um validador como o crontab.guru, ou use este gerador e inspecione as próximas N execuções no log da sua CI antes de promover para produção.