A Expressão */15 * * * *
*/15 * * * * dispara quatro vezes por hora (às :00, :15, :30 e :45) para um total de 96 execuções por dia. A sintaxe de passó */15 divide o intervalo do campo de minuto (0 a 59) em passos de 15 unidades começando em 0, resultando em exatamente quatro slots por hora que se alinham com os quartos de hora do relógio.
Este alinhamento não é coincidência. Os limites de quarto de hora mapeiam diretamente para como os humanos leem o tempo é como muitas janelas de SLA são definidas. Uma “verificação de 15 minutos” é eficiente para a máquina e legível para humanos.
Por que 15 Minutos é um Intervalo Ideal
Nos extremos, os tradeoffs são óbvios: * * * * * executa com muita frequência para a maioria dos trabalhos, 0 * * * * deixa uma lacuna de uma hora. A questão interessante é onde no meio está o padrão certo.
*/5 (12/hora, 288/dia) é excelente para qualquer coisa com SLA rigorosó ou caminho crítico, mas é 3x mais caro que */15 em termos de execuções. */10 (6/hora) é um ponto médio razoável. */15 vence como padrão porque:
- 96 execuções/dia é invisível na maioria dos orçamentos de recursos. Conexões de banco de dados, chamadas de API, linhas de log. 96 por dia raramente causa ruído.
- A janela de detecção de 15 minutos é aceitável para a maioria dos trabalhos não críticos em segundo plano. Se uma sincronização falha, ela tenta novamente dentro de 15 minutos. Se uma métrica fica desatualizada, ela atualiza dentro de 15 minutos.
- O alinhamento com quartos de hora facilita a inspeção de logs. Ao depurar, filtrar logs para a última janela de 15 minutos é intuitivo.
Casos de Usó Práticos
Kubernetes CronJobs para tarefas internas
A documentação do K8s CronJob usa */15 como exemplo de intervalo padrão. Para tarefas periódicas de limpeza, inválidação de cache ou relatórios internos de saúde que não precisam de atualização abaixo de 5 minutos, */15 é um padrão confiável.
Verificações agendadas de pipeline CI
Builds noturnos são comuns mas algumas equipes também executam um “teste de fumaca” CronJob no deploy que dispara a cada 15 minutos. Ele detecta regressões mais rápido que um nightly sem o custo de uma suíte completa por commit.
Verificações de conformidade SLA
Se sua janela SLA é medida em horas, um intervalo de 15 minutos fornece quatro pontos de dados por hora, suficientes para detectar e alertar sobre uma violação antes que a janela feche, sem gerar ruído excessivo de alerta.
Polling de pipeline de dados
Para pipelines ETL que leem de um sistema de origem e escrevem em um warehouse, 15 minutos é muitas vezes a cadência certa quando a origem atualiza em um agendamento similar. Verifique a frequência de atualização da origem antes de escolher seu intervalo.
Combinando com Restrições de Hora e Dia
O poder de */15 é como ele se combina limpidamente com outras restrições de campo:
*/15 9-17 * * 1-5 # a cada 15 min, 9 AM às 5 PM, apenas dias úteis
*/15 * * * 1-5 # a cada 15 min, 24h, apenas dias úteis
0,15,30,45 8,12,16 * * * # três vezes ao dia, nos quartos de hora
*/15 0-6 * * * # a cada 15 min, apenas horas noturnas
Tabela de Comparação
| Expressão | Disparos/hora | Disparos/dia | Atrasó máx. de detecção |
|---|---|---|---|
*/5 * * * * | 12 | 288 | 5 min |
*/10 * * * * | 6 | 144 | 10 min |
*/15 * * * * | 4 | 96 | 15 min |
*/30 * * * * | 2 | 48 | 30 min |
0 * * * * | 1 | 24 | 60 min |
Verificando Horários de Execução
Para ver os próximos 8 horários de execução para */15 * * * *:
from croniter import croniter
from datetime import datetime
cron = croniter("*/15 * * * *", datetime.now())
for _ in range(8):
print(cron.get_next(datetime))
Em um sistema onde o crontab está ativo, confirme que o trabalho está executando nos horários esperados:
journalctl -u cron --since "1 hour ago" | grep myjob
Você deve ver exatamente 4 entradas por hora. Se vir menos, o trabalho pode estar falhando silenciosamente.