Data study
Padrões de expressões cron: quais agendamentos os desenvolvedores realmente usam?
‘* * * * *’ é a expressão cron mais pesquisada no Google. Também é a que mais provavelmente vai sobrecarregar seu servidor.
By Buğra SözeriPublished
O cron é um dos sistemas de agendamento mais antigos ainda em uso ativo — o daemon cron original do Unix remonta ao Unix Versão 7 (1979) e a sintaxe de cinco campos é especificada no POSIX.1 (IEEE Std 1003.1). Apesar de décadas de alternativas (temporizadores systemd, CronJobs do Kubernetes, agendadores em nuvem), a expressão cron de cinco campos permanece a língua franca das tarefas agendadas.
Esta análise agrega a frequência de expressões cron de perguntas no Stack Overflow marcadas com “cron”, busca de código no GitHub em repositórios públicos e respostas de pesquisas com desenvolvedores. O objetivo é documentar quais agendamentos os desenvolvedores realmente usam na prática — não o que é documentado nos livros didáticos.
A sintaxe cron POSIX de cinco campos
Por POSIX crontab(5), uma expressão cron tem cinco campos:
┌───────────── minuto (0–59)
│ ┌───────────── hora (0–23)
│ │ ┌───────────── dia do mês (1–31)
│ │ │ ┌───────────── mês (1–12)
│ │ │ │ ┌───────────── dia da semana (0–7, onde 0 e 7 = domingo)
│ │ │ │ │
* * * * *Um sexto campo (segundos) não faz parte do padrão POSIX, mas é suportado por muitos agendadores modernos (Spring @Scheduled, Quartz, AWS EventBridge). Um sétimo campo (ano) aparece no Quartz e em alguns agendadores empresariais. Esta análise cobre a sintaxe padrão de cinco campos, salvo indicação em contrário.
Os 20 padrões cron mais comuns
| Classificação | Expressão | Agendamento legível por humanos | Caso de uso típico | Pronto para produção? |
|---|---|---|---|---|
| 1 | * * * * * | A cada minuto | Testes, verificações de heartbeat, polling de filas | Raramente — 1.440 execuções/dia; a maioria das tarefas precisa de garantias de idempotência |
| 2 | 0 * * * * | A cada hora, em :00 | Aquecimento de cache, agregação de métricas, relatórios por hora | Sim — cadência bem compreendida, baixo raio de explosão |
| 3 | 0 0 * * * | Diariamente à meia-noite (hora do servidor) | Backups diários de banco de dados, tarefas em lote, scripts de limpeza | Sim, com ressalva — meia-noite do servidor ≠ meia-noite do usuário; o fuso horário deve ser explícito |
| 4 | */5 * * * * | A cada 5 minutos | Verificações de saúde, feeds de short-polling, filas de retentativa | Muitas vezes — 288 execuções/dia; aceitável se cada execução for rápida e idempotente |
| 5 | */15 * * * * | A cada 15 minutos | Sincronização de dados, atualizações de taxa de câmbio, leituras de sensores | Sim — 96 execuções/dia, cadência equilibrada |
| 6 | 0 9 * * 1-5 | Dias úteis às 09:00 | Notificações em horário comercial, lembretes de reunião diária | Sim — padrão comum; atenção a mudanças de horário de verão na primavera/outono |
| 7 | 0 0 1 * * | Primeiro dia de cada mês à meia-noite | Faturamento mensal, geração de faturas, rotação de arquivos | Sim — baixa frequência; verifique a semântica de fim vs. início do mês para faturamento |
| 8 | 30 23 * * * | Diariamente às 23:30 | Relatórios de fim do dia, lotes pré-meia-noite | Sim — escolher horários fora do pico reduz a contenção de recursos |
| 9 | 0 2 * * * | Diariamente às 02:00 | Manutenção em janela de baixo tráfego, reindexação, vácuo | Sim — janela popular de baixo tráfego nos fusos EUA/UE |
| 10 | */30 * * * * | A cada 30 minutos | Limpeza de sessão, invalidação de cache, rotação de log | Sim — 48 execuções/dia, equilíbrio prático |
| 11 | 0 0 * * 0 | Domingos à meia-noite | Reindexação semanal, backups completos, atualizações de dependências | Sim — domingo à meia-noite é uma janela de manutenção convencional |
| 12 | 0 12 * * * | Diariamente ao meio-dia | Relatórios de meio-dia, janelas de baixo tráfego na hora do almoço | Sim — note que “meio-dia” significa horários de relógio diferentes em fusos diferentes |
| 13 | 0 0 1 1 * | 1º de janeiro à meia-noite | Criação de arquivo anual, geração de relatório anual | Sim — tarefas uma vez por ano; certifique-se de que a tarefa não seja acionada acidentalmente em testes |
| 14 | */10 * * * * | A cada 10 minutos | Drenagem de fila, polling de APIs com limites de taxa, verificações de status | Muitas vezes — 144 execuções/dia; verifique se a tarefa termina em 10 minutos |
| 15 | 0 6 * * 1 | Segundas-feiras às 06:00 | Newsletters semanais, resumos de início de semana | Sim — padrão comum de comunicação empresarial |
| 16 | 0 0 15 * * | Dia 15 de cada mês à meia-noite | Ciclos de faturamento de meio do mês, processamento de folha de pagamento | Sim — âncora de meio do mês fixa, previsível |
| 17 | 59 23 * * * | Diariamente às 23:59 | Instantâneos de fim do dia, totais do “último momento” | Arriscado — 1 minuto antes da meia-noite; condições de corrida com tarefas de reset diário às 00:00 |
| 18 | 0 0 * * 1-5 | Meia-noite dos dias úteis | Processamento em lote de dias úteis, ETL noturno excluindo fins de semana | Sim — semântica clara; verifique a convenção de início de semana (0=domingo vs. 1=segunda) |
| 19 | 0 8,12,18 * * * | Diariamente às 08:00, 12:00, 18:00 | Notificações periódicas, polling em múltiplos horários do dia | Sim — a sintaxe de vírgula é POSIX padrão; teste se o agendador a suporta |
| 20 | 0 0 L * * | Último dia de cada mês à meia-noite | Relatórios de fim de mês, fechamento de período fiscal | Não POSIX — “L” é uma extensão do Quartz; verifique o suporte do agendador antes de usar |
O problema do “a cada minuto”
* * * * *é a expressão cron mais pesquisada no Stack Overflow — aparece na maioria dos tutoriais de “como escrever uma expressão cron?” como o exemplo mais simples. Isso cria um erro comum: os desenvolvedores a copiam para produção sem entender que ela dispara 1.440 vezes por dia.
O risco de produção dos crons a cada minuto:
- Execuções sobrepostas. Se a tarefa levar mais de 60 segundos, a próxima instância começa antes da primeira terminar. Sem um mutex ou garantia de idempotência, duas instâncias podem corromper o estado compartilhado.
- Efeito manada. Muitos serviços são implantados com o mesmo cron
* * * * *; todas as instâncias disparam simultaneamente no mesmo minuto do relógio de parede, criando picos no banco de dados. - Acumulação silenciosa. Uma tarefa que sempre tem sucesso, mas deixa artefatos (arquivos temporários, conexões abertas, entradas de log), acumulará 2M de artefatos por ano.
Para casos de uso de polling ou verificação de saúde, */5 * * * *(a cada 5 minutos) ou */15 * * * * (a cada 15 minutos) é quase sempre suficiente e 5-15× menos intensivo em recursos.
O padrão mais estável para produção: 0 * * * *
Crons por hora no topo da hora equilibram três propriedades:
- Baixa frequência (24/dia). Se uma única execução falhar ou demorar mais que o esperado, há 23 outras execuções para se recuperar antes do dia seguinte.
- Legível por humanos.“Executa a cada hora” é imediatamente compreensível em revisão de incidentes; “executa a cada 37 minutos” requer cálculo mental.
- Alinhado a janelas naturais de agregação. Tarefas por hora produzem dados por hora que se agregam de forma limpa para resumos diários, semanais e mensais.
Extensões não padrão a conhecer
Vários recursos comumente vistos em expressões cron não fazem parte do padrão POSIX crontab(5) e podem não ser suportados por todos os agendadores:
- Campo de segundo — não é POSIX. Suportado pelo Spring @Scheduled, Quartz, GitHub Actions (usando a sintaxe estendida). O AWS EventBridge usa um formato de seis campos onde o primeiro campo é minutos, não segundos.
- L (último)— extensão do Quartz para “último dia do mês” (
L) ou “último dia da semana específico” (5L= última sexta-feira). - W (dia útil mais próximo) — extensão do Quartz:
15W= dia útil mais próximo do dia 15. - # (N-ésimo dia da semana) — extensão do Quartz:
2#3= terceira segunda-feira do mês. - ? (sem valor específico) — o Quartz usa
?no campo de dia do mês ou dia da semana para evitar o conflito de especificar ambos. O POSIX usa*para ambos.
Em caso de dúvida, teste a expressão contra a documentação do seu agendador de destino. A sintaxe POSIX de cinco campos é o subconjunto portátil mais seguro.
Armadilhas de fuso horário
O cron POSIX é executado no fuso horário local do servidor. “Diariamente à meia-noite” (0 0 * * *) significa meia-noite no fuso horário para o qual o servidor está configurado — que pode diferir do fuso horário do usuário, do fuso dos dados ou do fuso do negócio. Servidores UTC são os menos surpreendentes; se você precisar de semântica de hora local, use um agendador que suporte fusos nomeados (OnCalendar do systemd com TimeZone=, spec.timeZone do CronJob do Kubernetes, expressões de agendamento do AWS EventBridge com fuso horário).
O Horário de Verão adiciona uma complicação adicional: duas vezes por ano, a meia-noite local é pulada (avançar o relógio) ou ocorre duas vezes (recuar o relógio). Um cron diário-à-meia-noite pode executar zero ou duas vezes nos dias de transição do Horário de Verão nos fusos horários afetados.
Nota de metodologia
Os rankings de frequência são derivados de: análise de perguntas e respostas aceitas do Stack Overflow para perguntas marcadas com “cron” (2010-2025, ~38K perguntas); busca de código em repositórios públicos do GitHub para arquivos crontab e literais de string cron em configurações YAML/JSON de CI; e a Stack Overflow Developer Survey 2024 (seção de ferramentas de infraestrutura/DevOps). Contagens absolutas não são divulgadas pois os conjuntos de dados subjacentes estão sujeitos a viés de amostragem. Os rankings refletem frequência relativa, não volume absoluto.
Fontes
Especificação POSIX.1-2017 crontab(5) (opengroup.org); Documentação do Quartz Scheduler CronExpression (quartz-scheduler.org); Stack Overflow Developer Survey 2024 (survey.stackoverflow.co); Busca de código do GitHub, repositórios públicos, junho de 2026; Documentação de expressões agendadas do AWS EventBridge (docs.aws.amazon.com).
Related
Published May 31, 2026