Explicador de expressões Cron

Cole uma expressão cron e entenda exatamente o que ela faz.

Exemplos comuns

Como ler expressões cron

Uma expressão cron padrão tem 5 campos separados por espaços :

minuto hora dia mês dia-semana

* · qualquer valor   */n · a cada n unidades   1,5 · nos valores 1 e 5   1-5 · faixa de 1 a 5

Faixas : minuto (0-59), hora (0-23), dia (1-31), mês (1-12), dia da semana (0-6, 0 = domingo)

Como funciona

  1. Insira uma expressão cron : cole uma string cron de 5 ou 6 campos como 0 9 * * 1-5.
  2. Leia a explicação em linguagem clara : a ferramenta exibe imediatamente uma descrição legível de quando a tarefa é executada.
  3. Visualize as próximas execuções : uma lista das 5 a 10 próximas execuções programadas é exibida a partir da data e hora atuais.
  4. Valide : as expressões inválidas são destacadas com mensagens de erro precisas que explicam o problema.

Meio século de tiques de um minuto

cron é o agendador mais antigo ainda em uso contínuo e diário na maioria dos servidores do mundo. A sua primeira aparição no registo histórico é de maio de 1975, quando uma versão inicial saiu da AT&T Bell Laboratories como parte do ramo Research Unix. O nome é uma piscadela a Cronos, a personificação grega do tempo, e o desenho envelheceu com graça estranha: os mesmos cinco campos separados por espaços que os engenheiros da Bell Labs digitavam em /usr/lib/crontab em meados dos anos 70 ainda movem os CronJobs do Kubernetes, os schedules do GitHub Actions e o backup nocturno da base de dados num servidor privado virtual algures em Frankfurt neste preciso instante. A implementação de 1975 era mínima, havia uma única crontab, propriedade do root, que servia toda a máquina. Se um utilizador quisesse uma tarefa recorrente, pedia ao administrador para acrescentar uma linha à mão. cron viajou para o mundo mais vasto com Version 7 Unix, lançado em 1979. Robert Brown e Keith Williamson na Purdue University estenderam o cron para tratar múltiplos utilizadores no fim de 1979, introduzindo o fluxo crontab -e por utilizador. A reescrita decisiva veio quando Paul Vixie lançou o vixie-cron 1.0 a 6 de maio de 1987; o vixie-cron formalizou os caracteres especiais e introduziu os atalhos @reboot, @hourly, @daily, @weekly, @monthly, @yearly. O Vixie 3.0 (27 de dezembro de 1993) acrescentou os valores de passo (/) e foi entregue, com pequenos patches, em praticamente todas as distribuições Linux e BSD da época. O POSIX apanhou o passo em 1992 (IEEE Std 1003.2-1992). Cada esquisitice do cron moderno (a numeração de domingo desfasada, o bug união-vs-intersecção dos campos de dia) é uma cicatriz desta evolução; nada disto foi desenhado de uma só vez.

Anatomia de uma expressão de cinco campos

Uma expressão cron padrão tem cinco campos separados por espaços. Lidos da esquerda para a direita, perguntam: que minuto, de que hora, de que dia-do-mês, de que mês, de que dia-da-semana? Os intervalos exactos não são negociáveis em cron POSIX: minuto 0-59, hora 0-23, dia-do-mês 1-31, mês 1-12, dia-da-semana 0-7 com 0 e 7 a representarem ambos o domingo. Cada campo aceita cinco operadores que se compõem livremente: * significa qualquer valor válido; , separa uma lista de valores discretos (0,15,30,45 * * * * corre à hora certa, e um quarto, e meia, e três quartos de cada hora); - é um intervalo inclusivo (9-17 no campo hora significa 9, 10, 11, 12, 13, 14, 15, 16, 17); / é um valor de passo (*/15 no campo minuto significa cada quinze minutos a partir do zero, ou seja, 0, 15, 30, 45). Os meses e dias da semana também podem ser escritos em abreviaturas de três letras: JAN-DEC e SUN-SAT. Um exemplo trabalhado: */15 9-17 * * 1-5 descodifica-se como de quinze em quinze minutos durante as horas 9 a 17 inclusive, em qualquer dia do mês, em qualquer mês do ano, de segunda a sexta-feira: «de quinze em quinze minutos em horário de expediente nos dias úteis».

A armadilha dia-do-mês / dia-da-semana

A esquisitice mais consequente do cron (aquela que tem causado quedas, backups falhados e ciclos de facturação silenciosamente errados em produção há trinta e cinco anos) é a forma como o cron combina os campos dia-do-mês e dia-da-semana quando ambos estão restringidos. A linguagem POSIX é invulgarmente precisa aqui: «se tanto o ‘dia do mês’ (campo 3) como o ‘dia da semana’ (campo 5) estiverem restringidos (não contiverem ‘*’), então um ou ambos têm de corresponder ao dia atual». Por outras palavras, quando nenhum dos campos é wildcard, o cron toma a união dos dois, a tarefa corre em qualquer dia que satisfaça uma das restrições. Isto é o oposto do que a maioria dos utilizadores assume. Ler 0 0 13 * 5 em voz alta («meia-noite no dia 13, às sextas») soa naturalmente a uma intersecção: apenas sexta-feira 13. Em vixie-cron e seus descendentes significa de facto «todo o dia 13 do mês e todas as sextas», disparando cerca de nove vezes por mês. Pior, o vixie-cron decide se usa união ou intersecção inspecionando apenas o primeiro caractere de cada campo de dia. O próprio Paul Vixie reconheceu o comportamento como bug, mas recusou-se a alterá-lo, notando que corrigi-lo violaria o princípio do menor espanto, milhões de crontabs já estavam escritas a supor que o comportamento existente era deliberado. O bug é, portanto, agora uma funcionalidade, imortal e a propagar-se. O modelo mental pragmático: se se vir a restringir tanto dia-do-mês como dia-da-semana e quiser mesmo intersecção (p. ex. «a segunda terça-feira de cada mês»), use o operador # em implementações que o suportem (Quartz, cronie com extensões): 0 12 ? * 2#2. Em cron POSIX puro, a intersecção é genuinamente impossível de exprimir numa única expressão e tem de filtrar dentro do script que a tarefa cron invoca.

Os atalhos com macros

Estes atalhos não são POSIX. Ambientes estritamente POSIX vão rejeitar o @daily; na prática, qualquer implementação de cron que um leitor provavelmente venha a encontrar (vixie-cron, cronie, fcron, ISC cron, imagens de contentor) suporta-os.

Os dialectos, padrão vs Quartz vs AWS vs K8s vs systemd

A «expressão cron» é hoje uma pequena família de dialectos mutuamente incompatíveis. cron padrão de 5 campos (POSIX, vixie-cron, cronie): minuto hora dia-do-mês mês dia-da-semana, o mínimo denominador comum universal. Quartz Scheduler (6 ou 7 campos, ecossistema Java): segundos minutos horas dia-do-mês mês dia-da-semana [ano]; introduz ?, L (last), W (weekday), # (n-ésimo dia da semana do mês). O @Scheduled do Spring e o Spring Boot usam Quartz. Kubernetes CronJob usa cron padrão de 5 campos, com um campo spec.timeZone separado que ficou GA no K8s 1.27 (o próprio recurso CronJob ficou GA em 1.21, abril de 2021); o formato de fuso horário é a base de dados IANA tz (Europe/Berlin, America/New_York). Os schedules cron do GitHub Actions usam cron POSIX de 5 campos e correm em UTC. O cron do AWS EventBridge usa 6 campos (minutos horas dia-do-mês mês dia-da-semana ano), exige o operador ? em dia-do-mês ou em dia-da-semana (não pode restringir os dois), e usa 1-7 com SUN=1, significando que uma expressão EventBridge 0 12 ? * 2 * corre ao meio-dia de segunda-feira, não de terça. Os timers do systemd usam uma sintaxe totalmente diferente (OnCalendar=*-*-* 02:00:00) e estão gradualmente a substituir o cron no Linux moderno para o scheduling de sistema, embora ambos sejam entregues lado a lado em qualquer distro maior. Cloud Scheduler (Google Cloud) usa cron padrão de 5 campos com configuração explícita de fuso horário. Traduzir expressões entre plataformas exige atenção cuidada: um schedule de EventBridge copiado e colado vai correr no dia da semana errado em vixie-cron por causa do desfasamento da numeração dos dias.

Padrões comuns que vale a pena memorizar

Armadilhas comuns

Fuso horário. O cron usa por defeito a hora local do sistema, surpreendente em máquinas cloud que vêm por defeito em UTC. Uma tarefa cron às 9 da manhã num servidor UTC dispara às 4 da manhã hora de Nova Iorque. Os schedulers modernos (Kubernetes 1.27+, AWS EventBridge, Cloud Scheduler) acrescentaram campos explícitos de fuso horário; o cron clássico não. A regra «*/N começa em 0». */15 é 0, 15, 30, 45, não 5, 20, 35, 50. Para começar num offset diferente de zero tem de enumerar (5,20,35,50) ou usar a sintaxe Quartz-only 5/15. A armadilha do empilhamento de 60 minutos. Uma tarefa que demora mais do que o seu intervalo de scheduling pode empilhar, três backups de 30 minutos a disparar de 15 em 15 minutos vão sobrepor-se. A mitigação padrão é o flock(1): * * * * * /usr/bin/flock -n /tmp/myjob.lock /path/to/myjob garante que só uma instância corre de cada vez; a flag -n torna a aquisição do lock não-bloqueante, pelo que invocações subsequentes saem em silêncio em vez de ficarem em fila. Anomalias de horário de verão. Uma tarefa cron prevista para as 02:30 dispara duas vezes no dia em que os relógios atrasam e nada no dia em que adiantam. O cron não tem a noção de «hora de parede a contabilizar o horário de verão»; se o seu schedule tiver de saltar transições DST, ancore-o numa hora não afectada (3 da manhã ou mais tarde, na maioria dos fusos) ou use um scheduler que perceba as semânticas de fuso horário. Remoção do PATH. As tarefas cron correm com um PATH mínimo (/usr/bin:/bin) e um ambiente quase vazio; scripts que funcionam na sua shell interactiva podem falhar no cron porque o node, o python3 ou o aws não estão no PATH herdado. Defina o PATH= no topo da crontab ou use caminhos absolutos no comando cron. Estouro de e-mail. Por defeito, o cron envia a saída de cada tarefa para a caixa local do utilizador; num servidor sem mail configurado isto enche silenciosamente /var/spool/mail até o disco ficar sem espaço. Ou redirecciona a saída (>/dev/null 2>&1), ou põe MAILTO="" no topo da crontab, ou configura mesmo um forwarder de e-mail.

Alternativas modernas, quando ir buscar outra coisa

O cron é excelente para tarefas recorrentes simples numa só máquina. É fraco em: scheduling distribuído (a mesma tarefa disparada uma vez por uma frota em vez de uma vez por máquina), gatilhos guiados por eventos (correr quando uma fila recebe uma mensagem, e não por relógio), monitorização (o cron falha em silêncio se a tarefa sair com código diferente de zero a menos que configure encaminhamento de e-mail), retentativas (sem mecanismo embutido, tarefas falhadas voltam a correr no ciclo seguinte e acumulam estado) e dependências (correr a tarefa B só depois da tarefa A ter terminado com sucesso). Para esses casos a resposta moderna é uma de: Kubernetes CronJob (scheduling consciente do cluster, com políticas de retry e paralelismo), AWS EventBridge + Lambda ou Step Functions (orientado a eventos, com observabilidade embutida), Apache Airflow ou Prefect (orquestração de workflows baseada em DAG com dependências explícitas), Temporal (execução de workflows duráveis), healthchecks.io (um «interruptor de homem morto» que o avisa quando uma tarefa cron não corre dentro do horário). Para tarefas recorrentes numa só máquina em 2026, o simples cron continua a ser a resposta certa; para qualquer outra coisa, uma das alternativas compensa o setup adicional.

Perguntas frequentes

O que significa * numa expressão cron?

Um asterisco (*) num campo cron significa «qualquer valor válido», cada minuto, cada hora, cada dia, cada mês, cada dia-da-semana. * * * * * corre cada minuto de cada dia. O asterisco também é especial nos campos dia-do-mês e dia-da-semana por causa da armadilha união-vs-intersecção: quando qualquer dos campos de dia tem um * à frente, o vixie-cron usa o modo intersecção; quando nenhum tem, usa o modo união e corre na união das duas restrições.

Como faço uma tarefa cron correr a cada 15 minutos?

Use a notação de passo: */15 * * * * corre de 15 em 15 minutos, em xx:00, xx:15, xx:30 e xx:45. Note que */N começa sempre em 0; não pode usar */15 para significar «de 15 em 15 minutos a partir do minuto 5», para isso escreve 5,20,35,50 * * * *. O cron no dialecto Quartz suporta 5/15 como alternativa não padrão.

Qual a diferença entre cron e at?

O cron corre tarefas num horário repetitivo (todos os minutos, diariamente, semanalmente). O comando at agenda uma tarefa de uma só vez para correr num momento futuro específico, at 14:30 tomorrow põe uma tarefa em fila para esse momento isolado. Use o cron para tarefas recorrentes e at para execuções futuras pontuais. Ambos descendem da mesma linhagem Bell Labs / vixie-cron e acabaram por ficar integrados no mesmo daemon na maioria dos sistemas.

Porque é que a minha tarefa cron não bate com o que esperava?

As cinco causas mais comuns, por ordem aproximada de frequência: (1) Confusão dia-do-mês vs dia-da-semana (o cron usa a união dos dois quando ambos estão restringidos, não a intersecção. (2) Fuso horário) o cron usa por defeito a hora local do servidor, muitas vezes UTC em máquinas cloud. (3) Problemas de PATH, o PATH da sua shell interactiva não é herdado, pelo que comandos que funcionam na linha de comandos podem falhar no cron. (4) A armadilha */N-começa-sempre-em-0. (5) Saída não capturada em lado nenhum, tarefas falhadas desaparecem em silêncio se não tiver configurado e-mail ou redirigido a saída para um ficheiro de log. O painel «próximas 10 execuções programadas» deste explicador é a forma mais barata de verificar o que a sua expressão realmente significa antes de fazer deploy.

Isto suporta formatos cron não padrão?

Trata o cron POSIX/vixie-cron de 5 campos padrão, a variante Quartz/Spring de 6 campos com segundos, e as cadeias especiais @hourly, @daily, @weekly, @monthly, @yearly e @reboot. Não trata as extensões Quartz completas (L, W, #) nem a numeração de dias em base 1 do AWS EventBridge, para esses, use o validador da própria plataforma antes de fazer deploy.

A minha expressão cron é enviada para algum lado?

Não. O parsing e a explicação correm inteiramente no seu navegador via JavaScript. As expressões coladas nunca atravessam a rede, verifique no separador Rede das DevTools enquanto carrega em Explicar. Seguro para expressões cron em configurações de CI de produção, código de infra-estrutura e runbooks operacionais em que o próprio schedule pode ser sensível (p. ex. schedules nocturnos de exportação de base de dados que sugerem janelas de indisponibilidade).

Ferramentas relacionadas

Gerador cron

Construa agendamentos cron visualmente com predefinições, descrições e próximas execuções.

Conversor epoch

Converta timestamps Unix em datas humanas e vice-versa. Relógio epoch em tempo real.

Biblioteca regex

Navegue e copie padrões regex testados para tarefas comuns.