Gerador de expressões Cron
Construa e entenda os agendamentos de tarefas cron de forma visual.
Predefinições rápidas
5 próximas execuções
Referência de sintaxe cron
* · qualquer valor
*/5 · a cada 5 unidades
1,15 · nos valores 1 e 15
1-5 · faixa de 1 a 5
Campos : minuto (0-59), hora (0-23), dia do mês (1-31), mês (1-12), dia da semana (0-6, 0=domingo)
Uma breve história da expressão cron
A expressão cron de cinco campos data de maio de 1975, quando uma versão inicial foi enviada dos AT&T Bell Laboratories como parte do Research Unix Versão 7. O nome alude a Chronos, a personificação grega do tempo. O formato era simples: cinco campos separados por espaços em branco (minuto, hora, dia-do-mês, mês, dia-da-semana) em uma linha em /usr/lib/crontab. A reescrita Vixie cron por Paul Vixie em 1987 tornou-se a implementação moderna de fato; toda grande distribuição Linux envia um cron derivado de Vixie, e Vixie adicionou o crontab por usuário, o suporte a variáveis de ambiente (MAILTO=, CRON_TZ=), e as macros de atalho @hourly / @daily / @reboot que todo mundo usa hoje. A sintaxe da expressão cron então bifurcou em dois caminhos. O Quartz Scheduler (Java, James House, 1998; doado para Apache e Terracotta) adicionou um campo segundos no início, um campo ano opcional no final, e os operadores L (último) / W (dia útil) / # (n-ésima ocorrência), produzindo o cron de seis campos que AWS EventBridge (originalmente CloudWatch Events, 2014) e a anotação @Scheduled do Spring adotaram depois. O formato NCronTab usado pelas Azure Functions (2016) colocou os segundos primeiro mas manteve cinco campos comportamentais. A era da nuvem então padronizou o formato Vixie de cinco campos como lingua franca: os Kubernetes CronJobs (alpha 1.4 em 2016, GA em 1.21 em 2021) aceitam exatamente cinco campos, assim como o GitHub Actions (on.schedule.cron, 2019), GCP Cloud Scheduler (2018), e Vercel Cron Jobs (2022). Os construtores visuais de cron, a categoria a que esta ferramenta pertence, emergiram por volta de 2010-2015: crontab.guru (Christine Dodrill, 2014) tornou-se a referência mais citada, e a biblioteca cron-descriptor (Brady Holt, originalmente .NET, portada para Java/Python/JS) alimentou a maioria das camadas de tradução de «cron em inglês simples» em que decodificadores e geradores se baseiam. Meio século depois de Bell Labs, os mesmos cinco campos ainda agendam os backups noturnos do mundo.
A anatomia de uma expressão cron
- Cinco campos, separados por espaços em branco. Em ordem:
minuto (0-59) hora (0-23) dia-do-mês (1-31) mês (1-12) dia-da-semana (0-6). A expressão0 9 * * 1significa «minuto 0, hora 9, qualquer dia-do-mês, qualquer mês, dia da semana 1 (segunda)», ou seja, 9:00 toda segunda. O mês é indexado a 1;0 0 1 0 *é inválido porque não há mês 0. - Os quatro operadores.
*corresponde a todos os valores no intervalo do campo.,lista valores discretos:0,15,30,45no campo minuto.-define um intervalo:9-17no campo hora cobre das 9h às 17h./define um passo:*/15em minutos dispara em 0, 15, 30, 45. Esses quatro operadores se combinam livremente:*/15 8-18 * * 1-5significa «a cada 15 minutos entre 8 e 18, apenas dias úteis». - Macros de atalho. Vixie cron e a maioria dos parsers modernos aceitam
@yearly(ou@annually, equivalente a0 0 1 1 *),@monthly(0 0 1 * *),@weekly(0 0 * * 0),@daily(ou@midnight,0 0 * * *),@hourly(0 * * * *), e o especial@reboot(executa uma vez quando o daemon cron inicia). As plataformas em nuvem variam: GitHub Actions e Vercel rejeitam as macros. - A pegadinha do passo.
*/Nem um campo com intervalo a-b dispara em a, a+N, a+2N, ..., não necessariamente a cada N unidades de tempo do relógio de parede.*/7no campo minuto dispara em 0, 7, 14, 21, 28, 35, 42, 49, 56, então salta de volta para 0 no topo da próxima hora, produzindo uma lacuna de 4 minutos. Agendamento verdadeiro a cada 7 minutos é impossível em cron padrão sem um wrapper. - A armadilha OR (dia-do-mês vs dia-da-semana). Quando ambos os campos são restritos, o cron Unix padrão dispara quando qualquer um coincide, não ambos.
0 0 1 * 1não significa «segundas que caem no dia 1», significa «todo dia 1 do mês, mais toda segunda». A página de manualcrontab(5)é explícita. Quartz, AWS EventBridge, e os timers do systemd expressam «primeira segunda» limpamente; Vixie cron precisa de um wrapper. - A numeração do dia da semana varia. Linux/Vixie, GitHub Actions, GCP Cloud Scheduler, Kubernetes, Azure NCronTab, e Spring 5.3+ todos usam Domingo = 0 (Vixie também aceita 7). Quartz e AWS EventBridge usam Domingo = 1.
0 0 * * 1portanto significa «toda segunda» no Linux mas «todo domingo» sob Quartz. Use nomes de três letras (MON,TUE) quando portabilidade importar.
Onde a expressão se aplica
- cron Linux / macOS. Cole em
crontab -eseguido pelo comando. Nomes (MON,JAN) e macros de atalho (@hourly,@daily,@reboot) são aceitos. DefinaCRON_TZ=America/New_Yorkno topo do crontab se o servidor estiver em UTC mas você quiser agendar em hora local. - Kubernetes CronJob. Defina
spec.schedulecom sua expressão de cinco campos.spec.timeZone(GA em 1.27, março de 2023) recebe uma zona IANA como «Europe/Paris». EmbutirTZ=na string de agendamento é rejeitado a partir de 1.29. Usespec.startingDeadlineSecondspara controlar o comportamento de recuperação após uma falha. - GitHub Actions. Solte em
on.schedule.cron. Os agendamentos rodam em UTC, a cadência mais curta é de 5 minutos (qualquer coisa mais fina é silenciosamente arredondada), e workflows agendados em repositórios públicos auto-desativam após 60 dias de inatividade do repositório. Strings cron dentro do YAML devem ser citadas para evitar confusão do parser com o*inicial. - AWS EventBridge / EventBridge Scheduler. Usa seis campos:
cron(min hr dom mon dow yr). Requer?seja em dia-do-mês ou dia-da-semana (não ambos literais). Operadores estilo QuartzL(último),W(dia útil), e#(n-ésima ocorrência) todos funcionam aqui. O produto Scheduler (2022) adicionou uma expressãoat()separada para timers de tiro único. - GCP Cloud Scheduler. Sintaxe de cinco campos correspondendo ao Linux. A propriedade
timeZonerecebe uma zona IANA. Combine com Cloud Pub/Sub ou alvos HTTP.retryConfigtrata falhas transitórias; o padrão é nenhuma tentativa, o que surpreende engenheiros que esperam semântica pelo menos uma vez. - Vercel Cron Jobs. Sintaxe de cinco campos em
vercel.json. Ambos os campos de dia não podem ser definidos ao mesmo tempo. Os planos Hobby limitam a cadência diária; os planos Pro permitem horária. Dispara um HTTP GET para o caminho de sua função, o que significa que a função deve ser idempotente se o gatilho alguma vez fizer uma nova tentativa.
Padrões, dialetos e marcos
- cron do AT&T Bell Labs (maio de 1975). O original. Cinco campos, sem crontab por usuário, rodava de
/usr/lib/crontab. Parte do Research Unix Versão 7. A gramática separada por espaços que todas as variantes modernas estendem. - Vixie cron (Paul Vixie, 1987). A reescrita que todos rodam. Adicionou crontabs por usuário, as macros
@hourly/@daily/@reboot, aliases de nomes (MON,JAN), e as variáveis de ambienteMAILTO/CRON_TZ. A maioria das distribuições Linux envia Vixie cron, dcron, ou cronie (um fork da Red Hat do Vixie). - Quartz Scheduler (James House, 1998). Biblioteca Java que introduziu o cron de seis campos (com segundos no início) e os operadores
L/W/#. Doada para Apache e depois Terracotta. A anotação@Scheduleddo Spring incorpora a semântica do Quartz; Spring 5.3+ controversamente mudou o dia da semana do «Domingo=1» do Quartz para o «Domingo=0» do Linux, então a mesma string agora significa dias diferentes sob versões diferentes. - timers do systemd (Lennart Poettering, 2010). Substitui cron na maioria das distribuições Linux modernas. Usa uma gramática diferente (
OnCalendar=Mon..Fri 09:00), suporta tanto agendamentos de calendário quanto monotônicos, registra emjournald, pode declarar dependências de serviço, valida comsystemd-analyze calendar, e combina precisão estilo cron com recuperação estilo anacron viaPersistent=true. - NCronTab (Azure Functions, 2016). Seis campos com segundos primeiro:
{second} {minute} {hour} {day} {month} {day-of-week}. Sem campo de ano. A zona horária padrão é UTC; substitua com a configuração de aplicativoWEBSITE_TIME_ZONEnos planos Linux App Service. - Sintaxe cron do AWS EventBridge. Seis campos com ano por último:
cron(min hr dom mon dow yr). Requer literalmente?como placeholder no qual de dom/dow não é usado. Suporta QuartzL,W,#. Originalmente CloudWatch Events (2014), rebatizado EventBridge em 2019. - O problema de portabilidade 5-vs-6 campos. Colar uma expressão de cinco campos Linux em Quartz ou Spring produz erros «cron expression must consist of 6 fields»; colar uma expressão de seis campos em cron Linux produz «bad day-of-week» porque Linux lê a coluna de segundos como o minuto. O erro inverso é mais perigoso porque pode silenciosamente analisar e rodar no agendamento errado.
- Extensão
H(hash) do Jenkins. Jenkins estende o cron padrão comH, que escolhe um valor estável mas randomizado por tarefa em vez de rodar toda tarefa no mesmo instante.H * * * *significa «a cada hora, mas em um minuto diferente para cada tarefa», prevenindo o problema do «rebanho trovejante» quando muitas tarefas se agendam no minuto 0.
Perguntas frequentes adicionais
Cinco campos são o mesmo que seis ou sete?
Não. A forma POSIX clássica é de cinco campos (minuto, hora, dia-do-mês, mês, dia-da-semana). Quartz e Spring usam seis campos ao adicionar uma coluna de segundos no início, e Quartz aceita um sétimo campo de ano opcional. AWS EventBridge sempre usa seis campos terminando em ano (cron(min hr dom mon dow yr)). Colar uma expressão de cinco campos no Quartz ou Spring levanta um erro de sintaxe; colar uma expressão de seis campos no Linux interpreta silenciosamente os campos errados.
Qual é o menor intervalo que cron pode expressar?
Cada minuto (* * * * *) em cron Unix padrão. Não há campo de segundos integrado. Agendadores como Quartz ou NCronTab adicionam um se você precisa de cadência sub-minuto, e os timers do systemd podem usar OnUnitActiveSec=30s. GitHub Actions limita a cadência mais curta a 5 minutos, e EventBridge dispara dentro de uma janela de 60 segundos do tempo agendado, então não confie em cron para precisão de tempo real rígida.
Como executo uma tarefa no último dia do mês?
O cron padrão de cinco campos não tem operador nativo «último dia do mês». Quartz e AWS EventBridge suportam L no campo dia-do-mês: 0 0 L * ? dispara à meia-noite no último dia. Em cron Linux puro, a solução habitual é agendar diariamente em dias candidatos e filtrar o comando: 0 0 28-31 * * [ "$(date +\%d -d tomorrow)" = "01" ] && /path/to/script. Os timers do systemd expressam isso diretamente com OnCalendar=*-*-* 00:00:00.
Por que minha tarefa cron não rodou quando eu esperava?
Os suspeitos habituais, em ordem: (1) o servidor está em uma zona horária diferente da que você assume (verifique com date); (2) PATH não é o que seu shell interativo tem, então um comando funciona no prompt mas falha sob cron (use caminhos absolutos); (3) a saída foi para email e você perdeu (defina MAILTO="" ou redirecione para um arquivo de log); (4) o daemon cron não está rodando (systemctl status cron); (5) a armadilha OR (veja acima) está disparando em dias extras que você não pretendia.
Qual é a diferença entre cron, anacron, e os timers do systemd?
Cron espera que o sistema esteja rodando no tempo agendado e silenciosamente pula tarefas que caem durante tempo de inatividade: bom para servidores sempre ligados, ruim para laptops. Anacron rastreia carimbos de tempo de última execução por tarefa e recupera tarefas perdidas após uma reinicialização, ao custo de precisão de nível de dia em vez de minuto. Os timers do systemd substituem cron na maioria das distribuições Linux modernas: eles suportam tanto agendamentos de calendário quanto monotônicos, registram em journald, podem declarar dependências de serviço, e usam Persistent=true para combinar precisão estilo cron com recuperação estilo anacron.
Como zonas horárias e horário de verão afetam cron?
A maioria dos daemons cron interpreta agendamentos na zona horária do sistema. Em servidores em nuvem isso geralmente significa UTC, então 0 9 * * * dispara às 9h UTC, não às 9h locais. Defina CRON_TZ=America/New_York em um crontab Linux; Kubernetes usa spec.timeZone; AWS, GCP, e Vercel cada um recebem uma zona IANA explícita. Durante a passagem para horário de verão, tarefas agendadas na hora pulada são executadas imediatamente depois pelo Vixie cron mas puladas completamente pelo AWS EventBridge. O padrão mais seguro é deixar cron em UTC e converter dentro da tarefa.