Analisador de Expressão Cron

Analisador e explicador de Expressão Cron online gratuito. Analise, valide e entenda expressões de agendamento cron para Linux, Unix e Quartz com descrições legíveis e próximas execuções. Perfeito para desenvolvedores e administradores de sistema.

Expressão Cron

Clear

Paste

Fuso horário de exibição

As próximas execuções são exibidas neste fuso horário

Exemplos Comuns

Tem feedback? Reporte bugs, sugira recursos ou compartilhe suas ideias — lemos todos

Analisador de Expressão Cron - Analisar e Explicar Agendamentos Cron

Um poderoso Analisador de Expressão Cron online que ajuda você a entender, validar e explicar expressões de agendamento cron. Suporta formatos Unix/Linux (5 campos) e Quartz (6-7 campos) com detalhamento de campo detalhado e visualização de próxima execução. Perfeito para entender tarefas cron existentes e validar sintaxe cron.

O que é uma expressão cron e como lê-la?

Uma expressão cron é uma string de 5 ou 6 campos que define quando um trabalho recorrente deve rodar. O cron Unix padrão tem 5 campos: minuto (0-59), hora (0-23), dia do mês (1-31), mês (1-12), dia da semana (0-6, domingo é 0 ou 7). Muitos agendadores mais novos (Quartz, Spring, Jenkins, AWS EventBridge) adicionam um 6º campo de segundos à frente e um 7º campo de ano no fim. A string "0 9 * * 1-5" significa "às 09:00 de segunda a sexta-feira." O caractere * significa "todo valor," / significa "passo" (*/15 = a cada 15), - significa intervalo (1-5), e , significa lista (1,3,5). A página man do Vixie cron é a referência canônica para o formato original de 5 campos, RFC 4954 cobre alguma semântica de agendamento, e os docs do Quartz cobrem o dialeto estendido.

Qual a diferença entre */5 e 0/5 no campo de minutos?

Ambos significam "a cada 5 minutos começando de 0," mas chegam lá por caminhos sintáticos diferentes. */5 significa "passo 5 sobre o intervalo inteiro," produzindo 0, 5, 10, 15, ..., 55. 0/5 é a sintaxe estendida Quartz/Spring que significa "comece em 0, passo de 5," idêntico no resultado. Porém, 3/5 significa explicitamente "comece em 3 então passo 5": 3, 8, 13, 18, ..., 58. O Vixie cron padrão não suporta sintaxe N/M (só */M); se você escrever 3/5 em um crontab Linux puro, falhará silenciosamente ou será mal interpretado. Sempre verifique se seu runtime alvo usa Vixie cron, croniter (Python), node-cron, Quartz ou Spring — eles diferem exatamente neste canto. O AWS EventBridge em particular usa um formato de 6 campos tipo Quartz e semântica peculiar de dia da semana.

Por que dia do mês e dia da semana são interpretados como OR, não AND?

Esta é a regra cron mais surpreendente. "0 0 13 * 5" NÃO significa "dia 13 do mês E apenas na sexta-feira" — significa "dia 13 de qualquer mês, OU qualquer sexta-feira." Quando dia-do-mês e dia-da-semana estão ambos restritos (nenhum é *), o Vixie cron clássico e a maioria dos descendentes os tratam como união, não interseção. O BSD cron original usava interseção, mas o Vixie cron deliberadamente mudou para união em 1992 para coincidir com expectativas dos usuários para coisas como "dias úteis mais o dia 1" ("0 9 1 * 1-5" = 9h em dias úteis OU dia 1 de qualquer mês). Para obter a interseção real (alertas de sexta-feira 13), você normalmente precisa de uma proteção dentro do próprio job, ou use o ? especial do Quartz em um dos campos de dia para desambiguar. A especificação Quartz exige que exatamente um de dia-do-mês/dia-da-semana seja ? para tornar isso inequívoco.

O que significam @reboot, @daily, @weekly, @yearly e @hourly?

Esses apelidos são atalhos definidos pelo Vixie cron para agendamentos comuns. @yearly (alias @annually) = 0 0 1 1 * (meia-noite de 1º de janeiro). @monthly = 0 0 1 * * (meia-noite do dia 1). @weekly = 0 0 * * 0 (meia-noite de domingo). @daily (alias @midnight) = 0 0 * * * (meia-noite todo dia). @hourly = 0 * * * * (no topo de cada hora). @reboot é especial: roda uma vez quando o daemon cron inicia, tipicamente no boot do sistema — útil para tarefas de inicialização de serviço mas não confiável em ambientes conteinerizados onde o daemon cron pode reiniciar por outros motivos. Timers systemd e Kubernetes CronJobs não suportam @reboot semanticamente. Alguns sabores também suportam @minutely (a cada minuto) mas não é padrão.

Analisador de Expressão Cron — Analisador e explicador de Expressão Cron online gratuito. Analise, valide e entenda expressões de agendamento cron para — **Analisador de Expressão Cron**

Como rodar um job a cada 5 minutos entre 9h e 17h em dias úteis?

A expressão é "*/5 9-17 * * 1-5" significando a cada 5 minutos (minuto 0, 5, 10, ..., 55) das horas 9 a 17, qualquer dia do mês, qualquer mês, segunda a sexta. Duas sutilezas: isto dispara também às 17:00, 17:05, ..., 17:55 — não só às 17:00. Para parar exatamente às 17:00, use "*/5 9-16 * * 1-5" + "0 17 * * 1-5". Além disso, dia-da-semana 1-5 é segunda-sexta no Linux cron, mas no Quartz e AWS EventBridge, domingo é 1 e sábado é 7, então segunda-sexta é 2-6 — um bug de off-by-one frequente. Sempre teste no seu agendador alvo. Parsers cron online como o desta página mostram os próximos 5-10 horários de execução para você verificar a expressão visualmente.

Qual a diferença entre cron, timers systemd e Kubernetes CronJobs?

Os três agendam trabalhos recorrentes mas com garantias diferentes. O cron Unix clássico é simples, ubíquo, mas não tem logging, nem rastreamento de dependências, nem retentativas, e envia erros silenciosamente por e-mail para root. Timers systemd são o substituto Linux moderno: integram com o journal (logs estruturados), suportam OnBootSec / OnCalendar (mais rico que sintaxe cron), lidam com execuções perdidas (Persistent=true recupera se o sistema estava desligado) e têm dependências de unidade. Kubernetes CronJobs usam uma expressão cron tipo Quartz de 5 campos mas adicionam concurrencyPolicy (Allow/Forbid/Replace), startingDeadlineSeconds e limites de histórico sucesso/falha. Agendadores cloud (AWS EventBridge, GCP Cloud Scheduler, Azure Logic Apps) adicionam retentativas, filas de letra morta e observabilidade. Para qualquer coisa além de um servidor de hobby, prefira timers systemd ou um agendador cloud em vez de cron puro.

Qual a diferença entre L, W e # nas expressões cron Quartz?

Estas são extensões Quartz não encontradas no Vixie cron padrão. L significa "último": L em dia-do-mês = o último dia do mês (lida com 28/29/30/31 automaticamente), 5L em dia-da-semana = a última sexta-feira do mês. W significa "dia útil mais próximo": 15W = o dia útil mais próximo ao dia 15 (se 15 for sábado, dispara na sexta dia 14; se domingo, segunda dia 16). LW combinado = o último dia útil do mês — útil para folha de pagamento. # especifica a Nésima ocorrência: 2#3 em dia-da-semana = a terceira terça-feira do mês (já que Quartz usa 1=Dom, 2=Seg, ..., 7=Sáb). Estas extensões lidam com regras de negócio do mundo real ("segunda segunda-feira de cada mês", "último dia útil para faturas") que cron puro de 5 campos não pode expressar. AWS EventBridge suporta L e # mas não W.

Como fusos horários afetam agendamentos cron?

O Vixie cron clássico roda no fuso horário local do sistema (variável TZ), o que causa bugs dolorosos em torno das transições de horário de verão. Em um fuso com adiantamento de primavera, jobs agendados às 02:30 simplesmente não rodam naquele dia. Com retrocesso de outono, jobs às 01:30 rodam duas vezes. Timers systemd usam UTC por padrão a menos que OnCalendar especifique um TZ. Quartz e Kubernetes CronJobs ambos suportam um campo de fuso horário explícito (spec.timeZone em CronJob 1.27+) para que a mesma expressão se comporte identicamente entre regiões. AWS EventBridge interpreta cron sempre em UTC; expressões rate(...) são independentes de fuso. Boa prática: escreva todas as expressões cron em UTC e converta para exibição. Se precisar usar hora local, evite as horas de borda do horário de verão (02:00-03:00 na maioria das regiões); agende jobs às 04:00 ou depois.