Gerador Crontab e Construtor de Expressão Cron

O que é uma expressão cron?

# Linux crontab entry — runs every 15 minutes
*/15 * * * *  /usr/local/bin/poll-api.sh

# Kubernetes CronJob — weekdays at 9:00 AM UTC
apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-report
spec:
  schedule: "0 9 * * 1-5"
  timeZone: "UTC"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: report
              image: report-runner:1.0
          restartPolicy: OnFailure

# GitHub Actions workflow — hourly
on:
  schedule:
    - cron: '0 * * * *'

# AWS EventBridge — first of each month
ScheduleExpression: cron(0 0 1 * ? *)
# (Note: AWS uses the Quartz 6-field form with '?' for day-of-week)

Principais recursos

Variantes de cron e agendadores

Exemplos de expressão cron

*/15 * * * *

0 9 * * 1-5

0 0 1 * *

*/5 9-17 * * 1-5

0 0 1 JAN,APR,JUL,OCT *

0 0 1 * 5

30 2 * * *

@daily

Como construir uma expressão cron

1. 1

   Digite ou cole uma expressão cron

   Insira uma expressão cron de cinco campos no campo acima (ex.: `*/15 * * * *`). A ferramenta interpreta e valida conforme você digita — check verde para válida, erro vermelho com nome do campo para inválida. Macros como `@daily`, `@hourly` etc. também são aceitas.

2. 2

   Ou ajuste as entradas dos cinco campos

   Não precisa decorar a ordem dos campos — edite Minuto, Hora, Dia do mês, Mês ou Dia da semana individualmente usando os campos rotulados. A expressão completa no topo atualiza automaticamente. Use `*` para curingas, `*/N` para passos, `a-b` para intervalos e `1,3,5` para listas.

3. 3

   Escolha um preset para começar

   Toque em qualquer chip de preset (A cada 15 minutos, Dias úteis às 9h etc.) para carregar um agendamento comum e depois ajuste os campos para sua necessidade exata. Onze presets cobrem os padrões que você vai realmente usar em produção.

4. 4

   Verifique a pré-visualização da próxima execução

   Olhe para as cinco datas e horas das próximas execuções — alterne entre Local e UTC para confirmar que o agendamento dispara quando você pretende. Essa é a forma mais confiável de pegar a pegadinha do OU entre dia do mês e dia da semana POSIX antes que ela morda você em produção.

5. 5

   Copie e cole no seu agendador

   Clique em Copiar para pegar a expressão. Cole no seu crontab, timer do systemd, `cron:` do GitHub Actions, AWS EventBridge, `schedule` do Kubernetes CronJob ou em qualquer agendador compatível com cron. Não esqueça de verificar o fuso do agendador alvo — veja a seção Boas Práticas abaixo.

Erros comuns com cron

# Pretendido: "primeira sexta-feira do mês"
0 0 1-7 * 5
# Na verdade: dispara nos dias 1-7 do mês OU em toda sexta — ambas as condições

# Use wrapper para semântica E verdadeira
0 0 * * 5  [ $(date +\%d) -le 7 ] && /seu-script
# OU largue uma das condições e aceite o agendamento mais frouxo

# Escrito por dev em US East, deployado em servidor UTC
0 9 * * *  /seu-relatorio.sh
# Dispara às 9h UTC = 4h US East — não era o que o dev queria

# Fixe o fuso, ou escreva em UTC explicitamente
CRON_TZ=America/New_York
0 9 * * *  /seu-relatorio.sh

# Pretendido: a cada 15 minutos
15 * * * *
# Na verdade: uma vez por hora, no minuto 15 (4 execuções/hora a menos do que pretendido)

# Correto
*/15 * * * *
# A cada 15 minutos: minuto 0, 15, 30, 45 de toda hora

# 6 campos Quartz copiados para crontab Linux
0 0 9 * * 1-5
# Linux lê: minuto=0, hora=0, dom=9, mês=*, dow=1-5
# = meia-noite nos dias 9 em meses que batem com dias úteis — caos

# POSIX 5 campos, descarte os segundos
0 9 * * 1-5
# = dias úteis às 9:00

# 30 ou 31 de fevereiro — nunca roda
0 0 30 2 *
0 0 31 2 *
# Interpreta mas nenhum agendamento jamais dispara

# Use o padrão 'último dia útil de fevereiro' via script
0 0 28-29 2 *  [ $(date -d tomorrow +\%m) = 03 ] && /seu-script

# Quartz: 'última sexta do mês' — inválido em POSIX
0 0 ? * 6L *

# Abordagem POSIX com script wrapper para última sexta
0 0 25-31 * 5  /seu-script
# Roda na sexta entre os dias 25-31 de qualquer mês

Casos de uso comuns

Jobs de crontab Linux

Construa e verifique entradas para `/etc/crontab`, `/etc/cron.d/*` ou arquivos `crontab -e` por usuário. Use a pré-visualização da próxima execução para confirmar que o agendamento cai no horário certo no fuso configurado do seu servidor antes de salvar.

Agendamentos de Kubernetes CronJob

Gere o campo `spec.schedule` para um Kubernetes CronJob. Kubernetes 1.27+ também suporta `spec.timeZone` — use o toggle UTC para desenhar seu agendamento em UTC e depois defina `timeZone` explicitamente para evitar o horário local do worker node.

Workflows agendados do GitHub Actions

Construa a entrada `cron:` sob `on.schedule`. GitHub Actions sempre roda em UTC — alterne a pré-visualização para UTC para confirmar seu agendamento. Evite intervalos menores que 15 minutos; o agendador do GitHub pula jobs de intervalo curto sob carga.

Regras do AWS EventBridge

Componha a expressão cron para uma regra agendada do EventBridge. Obs.: a AWS usa sintaxe estilo Quartz de seis campos com `?` para dia da semana — esta ferramenta emite POSIX de cinco campos, que você precisará converter prefixando segundos (`0`) e substituindo o `*` em um dos campos de dia por `?`.

Pipelines agendados do GitLab CI

Verifique a expressão cron para um pipeline CI agendado no GitLab. GitLab usa sintaxe POSIX de cinco campos — exatamente o que esta ferramenta emite — e um seletor de data na UI, mas a forma cron dá controle mais fino para intervalos não padrão.

Cron Triggers do Cloudflare Workers

Construa a entrada `[triggers.crons]` em `wrangler.toml`. Cloudflare usa sintaxe POSIX de cinco campos. O intervalo mínimo é um minuto; o worker roda em UTC. Use a pré-visualização para verificar que o trigger dispara dentro da janela esperada.

Agendamentos do node-cron em Node.js

Construa expressões para a biblioteca `node-cron`, que suporta tanto cinco campos POSIX quanto um campo de segundos opcional no início. Fique nos cinco campos a menos que você especificamente precise de precisão sub-minuto — expressões de seis campos não migram para o crontab do Linux.

Code review e documentação

Cole uma expressão cron de um PR ou runbook para ver instantaneamente o que ela faz — chega de adivinhar `30 7 * * 1-5` ou puxar um cartão de referência. A descrição em linguagem clara também é ótima para comentários inline e arquivos README.

Referência de sintaxe cron

Ordem dos campos: M H D M W

Minuto (0-59), Hora (0-23), Dia do mês (1-31), Mês (1-12), Dia da semana (0-6, 7 também = domingo). Mnemônico: "Meu Hipopótamo Dorme Mais Wee". O campo de dia da semana aceita tanto tokens numéricos (0-6) quanto nomeados (SUN-SAT, case-insensitive).

Operadores

`*` = qualquer valor; `,` = separador de lista (`1,3,5`); `-` = intervalo (`1-5`); `/` = passo (`*/15`, `5/10`); nomes: JAN-DEC para mês, SUN-SAT para dia da semana (case-insensitive).

Macros (aliases)

`@yearly` = `0 0 1 1 *`; `@annually` = `0 0 1 1 *`; `@monthly` = `0 0 1 * *`; `@weekly` = `0 0 * * 0`; `@daily` = `0 0 * * *`; `@midnight` = `0 0 * * *`; `@hourly` = `0 * * * *`. `@reboot` é um não-agendamento especial (roda apenas no boot) e é rejeitado com um erro explicativo.

Semântica POSIX de dia (regra do OU)

Quando AMBOS dia do mês e dia da semana estão restritos (nenhum é `*`), o agendamento dispara quando QUALQUER um bate — semântica de OU. Quando apenas um está restrito, ele decide. Quando ambos são `*`, todo dia bate. Essa regra do OU se aplica ao vixie cron, BSD cron e à maioria das implementações POSIX; Quartz usa `?` para desambiguar E vs OU.

Modo de seis campos (Quartz-Lite)

Se sua entrada tem seis tokens separados por espaço, a ferramenta trata o primeiro como campo de segundos (0-59). Útil para Quartz, Spring `@Scheduled(cron=...)` e node-cron. NÃO portável para crontab do Linux ou agendadores POSIX — eles tratariam seus segundos como minutos e deslocariam tudo em uma posição.

Ancoragem do operador de passo

`*/N` é ancorado ao menor valor do campo: `*/15` em minuto = `0,15,30,45`, não "a cada 15 a partir de agora". Com base que não é curinga: `5/15` em minuto = `5,20,35,50`. Valores de passo que não dividem o intervalo do campo igualmente vão pular perto da volta — isso é correto, não é bug.

Limites de validação

minuto ∈ [0,59], hora ∈ [0,23], dia do mês ∈ [1,31], mês ∈ [1,12], dia da semana ∈ [0,7]. Valores fora do intervalo produzem um erro no nível do campo. O dia do mês NÃO é validado contra o mês (`0 0 31 2 *` é interpretado normalmente, mas nunca bate porque fevereiro não tem dia 31 — a pré-visualização da próxima execução mostrará "Nenhuma execução próxima").

Operadores Quartz rejeitados

Cron POSIX não suporta o `?` (sem valor específico), `L` (último), `W` (dia útil mais próximo) nem `#` (n-ésimo dia da semana) do Quartz. Esta ferramenta os rejeita com uma mensagem clara "Operadores Quartz não suportados" em vez de interpretá-los silenciosamente como POSIX inválido. Para agendamentos Quartz, use uma ferramenta que entenda Quartz ou o scheduler do Spring.

Limite de ano na busca da próxima execução

O cálculo da próxima execução busca até 4 anos à frente; expressões que batem com menos frequência (ex.: padrões de "29 de fevereiro") mostrarão "Nenhuma execução nos próximos 4 anos". Isso é por design para evitar iteração ilimitada em padrões impossíveis.

Boas práticas para agendamentos cron

Use UTC nos servidores, converta na hora de exibir

Configure seus servidores em UTC (`/etc/timezone` ou `TZ=UTC`) e escreva todas as expressões cron em UTC. Converta para horário local apenas na hora da exibição em seus dashboards e relatórios. Isso elimina toda uma categoria de bugs de fuso horário que atacam mais forte durante transições de horário de verão, quando agendamentos em horário local silenciosamente disparam em dobro ou pulam uma execução. Use o toggle UTC nesta ferramenta para desenhar seu agendamento em UTC desde o início.

Evite a armadilha do OU entre dia do mês e dia da semana POSIX

Nunca restrinja tanto dia do mês QUANTO dia da semana a menos que você queira semântica de OU. Se você quer "toda segunda de janeiro", escreva `0 0 * 1 1` (dia do mês é `*`); se você quer "o dia 1º de todo mês", escreva `0 0 1 * *` (dia da semana é `*`). A regra POSIX do OU significa que `0 0 1 * 1` roda no dia 1 E em toda segunda — quase certamente não o que você pretendia. A pré-visualização da próxima execução pega isso se você checar antes do deploy.

Fixe o fuso do agendamento explicitamente

Agendadores modernos suportam fixar o fuso na definição do agendamento: `CRON_TZ=America/New_York` no topo de um crontab (vixie cron 3.0+), `spec.timeZone: "America/New_York"` para Kubernetes CronJobs 1.27+, expressão de agendamento com `ScheduleExpressionTimezone` para o AWS EventBridge Scheduler. Fixe o fuso explicitamente em vez de confiar no padrão do servidor — fusos de servidores podem mudar sem aviso durante migrações de infraestrutura.

Distribua a carga entre minutos, não no :00

Evite `0 * * * *` (toda hora no minuto 0) para jobs não críticos — em escala, agendar muitas coisas exatamente em :00 cria picos de carga. Escolha um offset aleatório de minuto (`23 * * * *`, `41 * * * *`) para cada job para distribuir a carga. O mesmo vale para jobs diários: `30 3 * * *` é mais amigável para seu banco do que `0 3 * * *` quando muitos jobs convergem em 3:00.

Torne os jobs idempotentes

Cron não tem retry embutido, nem prevenção de sobreposição, nem recuperação de execução perdida. Seu job deveria ser seguro para rodar múltiplas vezes (idempotente) e se auto-verificar. Em vez de "enviar relatório às 9h", desenhe como "enviar o relatório de hoje se ainda não foi enviado" — isso se auto-cura depois de downtime, agendamentos duplicados acidentais e execuções concorrentes. Idempotência é uma propriedade do job, não do agendador, e é a prática de confiabilidade mais importante.

Adicione um heartbeat para agendamentos críticos

O modo de falha silenciosa do cron é sua maior fraqueza — se o agendamento não dispara, nada te avisa. Para jobs críticos, faça o job pingar um serviço de heartbeat (Healthchecks.io, Cronitor, Dead Man's Snitch) ao final de cada execução; o serviço te alerta se o ping esperado não chega. Isso pega tanto a falha do job quanto a falha do próprio agendamento. O tier grátis cobre a maioria das necessidades pessoais e de equipes pequenas.

Verifique com a pré-visualização da próxima execução antes do deploy

Antes de fazer deploy de um novo agendamento cron, olhe para as cinco próximas datas e horas na pré-visualização desta ferramenta. Alterne entre Local e UTC. Confirme que o agendamento cai quando você pretende — não cinco minutos antes, não no dia errado, não pulando o fim de semana que importava. A pré-visualização é o teste de produção mais barato possível.

Perguntas frequentes