A expressão cron */30 * * * * executa às :00 e :30 de cada hora (48 vezes por dia). Sintaxe */30 vs 0,30, deslocamento de fase e casos de uso de meia hora.
⏰Every 30 minutes
*Qualquer valor,Separador de lista-Intervalo/Passo1-5Intervalo de 1 a 5*/15A cada 15 unidades*/30 * * * * dispara no minuto 0 e no minuto 30 de cada hora, totalizando 2 execuções por hora, 48 por dia. O passó */30 começa em 0 (o mínimo do campo de minuto) e avança de 30 em 30, o que resulta em exatamente dois valores: 0 e 30.
O agendamento é o mais simples possível: no início e no meio de cada hora, a toda hora, o dia todo. Não há ambiguidade sobre quais minutos são selecionados e nem casos extremos de intervalo de campo.
Ambas as expressões produzem o mesmo agendamento. A escolha é sobre comúnicação de intenção:
*/30 * * * * # "a cada 30 minutos"
0,30 * * * * # "no minuto 0 e no minuto 30"
A forma explícita 0,30 é argumentavelmente mais defensiva. Não deixa espaço para má interpretação. Um desenvolvedor não familiarizado com sintaxe de passó pode ler 0,30 * * * * corretamente de primeira. */30 requer saber que o passó começa em 0 no campo de minuto.
Em comentários de código ou runbooks onde o público inclui não especialistas em cron, 0,30 é a escolha mais segura. Em uma equipe de engenheiros confortáveis com sintaxe cron, */30 é aceitável e é o que a maioria das pessoas usa.
Muitos sistemas de notificação agrupam atualizações e enviam resumos em uma cadência de meia hora. Uma janela de 30 minutos é longa o suficiente para acumular conteúdo significativo mas curta o suficiente para que os usuários não se sintam desconectados. Digests duas vezes por hora são um padrão comum em plataformas de alerta e newsletter.
Dashboards que mostram métricas dos “últimos 30 minutos” se alinham naturalmente com um agendamento de geração de meia hora. Executar o relatório às :00 e :30 significa que os dados estão no máximo 30 minutos desatualizados, o que é aceitável para a maioria dos relatórios internos.
Se um sistema de origem atualiza a cada 15 a 20 minutos, uma sincronização de 30 minutos significa que você está no máximo um ciclo de atualização atrás. Este é frequentemente o tradeoff certo quando a sincronização envolve uma escrita significativa no banco de dados ou transferência de arquivo.
Para índices de busca ou views materializadas que são caras de reconstruir, atualização duas vezes por hora limita o raio de explosão de uma reconstrução lenta enquanto mantém o conteúdo razoavelmente atualizado.
O */30 padrão sempre dispara às :00 e :30. Se você quer o trabalho de meia hora deslocado do marco da hora, use um início explícito:
15,45 * * * * # dispara às :15 e :45
Isso é equivalente a 15/30 * * * *, mas 15,45 é mais legível.
Agendamentos com deslocamento de fase são úteis quando você tem múltiplos trabalhos de meia hora e quer distribuir a carga:
0,30 * * * * /opt/jobs/report-generator
15,45 * * * * /opt/jobs/data-sync
7,37 * * * * /opt/jobs/cache-warmer
@hourly (que expande para 0 * * * *) dispara 24 vezes por dia. */30 * * * * dispara 48 vezes por dia, exatamente o dobro.
A escolha entre horário e meia hora depende da sua janela aceitável de desatualização. Se o trabalho mantém um cache e os dados subjacentes mudam mais rápido que a cada hora, meia hora mantém o cache mais atualizado. Se os dados mudam no máximo uma vez por hora, @hourly é suficiente e gera metade da carga.
Nenhum está sempre certo. Meça com que frequência sua fonte de dados realmente muda antes de escolher o intervalo.
from croniter import croniter
from datetime import datetime
cron = croniter("*/30 * * * *", datetime.now())
for _ in range(6):
print(cron.get_next(datetime))
Isso imprime os próximos 6 horários de execução, cobrindo três horas de dados, mostrando claramente o padrão :00/:30.
Nothing you paste leaves this tab. Every tool runs entirely in your browser — no upload, no server, no account.