Expressão Cron para A Cada 10 Minutos

A Expressão */10 * * * *

*/10 * * * * executa um trabalho seis vezes por hora, nos minutos 0, 10, 20, 30, 40 e 50, repetindo a cada hora, todos os dias. Em 24 horas são 144 execuções. Fica no meio do intervalo comum de passos: mais frequente que */15 ou */30, menos exigente que */5.

A sintaxe */10 usa o operador de passo. No campo de minuto, * cobre o intervalo de 0 a 59, e /10 seleciona cada 10º valor começando de 0. O resultado é sempre os mesmos seis marcos de minuto, independentemente de quando o daemon inicia.

Comparação com Intervalos Vizinhos

O salto de */5 para */10 reduz a contagem de execuções pela metade. Para trabalhos onde latência de 5 minutos é aceitável mas 15 minutos é muito lento, 10 minutos é um meio termo prático que reduz pela metade seu consumo de recursos.

Quando 10 Minutos é a Escolha Certa

Polling de API externa sem webhooks

Muitas APIs não oferecem notificações push. Se você precisa detectar mudanças dentro de uma janela de 10 minutos é a API tem um limite de taxa que um polling de 5 minutos sobrecarregaria, */10 é uma boa opção. Você faz 144 chamadas de API por dia em vez de 288.

Processamento em lote com vazão moderada

Se você está processando uma fila de itens é uma latência de 10 minutos é aceitável, */10 evita a sobrecarga de agendamento mais frequente enquanto mantém a fila sob controle. Monitore a profundidade da fila ao longo do tempo. Se crescer consistentemente, o intervalo é muito longo.

Verificações de monitoramento interno

Verificações de infraestrutura (espaço em disco, contagens de processos, alertas de profundidade de fila) que disparam uma notificação quando um limite é ultrapassado não precisam executar a cada 5 minutos. Uma janela de 10 minutos detecta a maioria das tendências de degradação cedo o suficiente para agir sem sobrecarregar a infraestrutura de monitoramento.

Sincronização de dados de fontes de mudança lenta

Se os dados que você está sincronizando mudam no máximo uma vez a cada poucos minutos, um intervalo de 10 minutos significa que você nunca está mais de um ciclo atrás. Para dados de referência ou sincronização de configuração, isso geralmente é mais que suficiente.

Deslocando o Minuto de Início

O */10 padrão sempre dispara às :00, :10, :20, :30, :40, :50. Se você está executando múltiplos trabalhos em um servidor e todos usam */10, todos começam simultaneamente naqueles marcos de minuto. Isso pode criar picos de carga.

Para distribuí-los, use a sintaxe início/passo:

*/10 * * * *    /opt/jobs/job-a     # dispara às :00, :10, :20...
2/10 * * * *    /opt/jobs/job-b     # dispara às :02, :12, :22...
5/10 * * * *    /opt/jobs/job-c     # dispara às :05, :15, :25...

Cada trabalho agora tem seu próprio offset de 2 minutos. A carga é distribuída uniformemente em cada janela de 10 minutos.

Verificando a Expansão

Para confirmar o que */10 * * * * expande, use Python:

from croniter import croniter
from datetime import datetime

cron = croniter("*/10 * * * *", datetime.now())
for _ in range(6):
    print(cron.get_next(datetime))

Isso imprime os próximos 6 horários de execução. Todos cairão dentro dos próximos 60 minutos, espaçados exatamente 10 minutos.

Quando Atualizar ou Reduzir

Se o trabalho consistentemente termina em menos de 30 segundos é a saída raramente é necessária, considere */15. Você perde 48 execuções por dia mas ganha folga.

Se você perceber que um intervalo de 10 minutos está causando latência visível em um dashboard ou funcionalidade voltada ao usuário, mude para */5. Mas primeiro pergunte se uma abordagem baseada em push (webhooks, Server-Sent Events, WebSocket) eliminaria o polling completamente.