Expressão Cron para A Cada 15 Minutos

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 Uso 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, invalidaçã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

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.