Uma programação precisa de mais do que uma expressão aparentemente correta. Os mesmos cinco campos podem produzir instantes diferentes conforme o fuso horário, e uma expressão válida pode representar a necessidade errada. Antes de configurar uma tarefa, escreva o que deve acontecer, qual relógio importa e como será possível reconhecer um resultado correto.
O gerador de cron ajuda a avaliar essa decisão. Ele valida uma expressão Unix aceita e apresenta datas correspondentes. Não instala um crontab, não contata servidores nem executa trabalhos. O resultado serve como evidência para revisar uma configuração que será aplicada depois no sistema responsável pela execução.
Transforme a necessidade em uma regra de calendário
Imagine uma equipe que precisa de um relatório às 09:00 de cada dia útil em Madri. Primeiro esclareça se «dia útil» significa segunda a sexta ou o calendário real da organização. Cron consegue representar a primeira definição; feriados, fechamentos excepcionais e sábados de trabalho exigem lógica adicional. Sem essa distinção, uma expressão perfeita pode gerar relatórios nos dias errados.
Os cinco campos são minuto, hora, dia do mês, mês e dia da semana, nessa ordem. O relatório fica 0 9 * * 1-5, com Europe/Madrid selecionado separadamente. UTC é o fuso padrão da ferramenta. Mantê-lo significa nove horas em UTC, uma necessidade diferente de nove no relógio local de Madri.
Guarde juntos expressão, fuso e comportamento esperado. Uma captura mostrando apenas os cinco campos perde informação. Acrescente uma frase sobre feriados e sobre o sistema que executará o relatório, para que outra pessoa entenda a regra e seu contexto operacional durante uma revisão futura.
Comece com um exemplo reproduzível
Use estes dados fixos antes de trabalhar com o momento atual:
Expressão: */15 * * * *
Fuso: UTC
Depois de: 2026-01-01T00:00:00Z
Primeiras correspondências:
2026-01-01T00:15:00Z
2026-01-01T00:30:00Z
2026-01-01T00:45:00Z
São datas históricas de verificação, não próximas execuções em relação ao momento da leitura. O limite «depois de» é exclusivo: a correspondência exata da meia-noite não entra. O campo de minutos seleciona zero, quinze, trinta e quarenta e cinco dentro de cada hora; as horas seguintes repetem essas posições.
Registre os três resultados antes de modificar qualquer coisa. Se produção interpretar os mesmos dados de outra forma, investigue seu dialeto cron, instante de referência e fuso. Alterar a hora até que a primeira data pareça conveniente pode esconder um erro que reaparecerá na mudança de dia ou estação.
Depois teste o relatório dos dias úteis e examine várias datas, incluindo a passagem de sexta para segunda. A prévia oferece evidências concretas do calendário; a necessidade escrita informa quais delas importam para essa tarefa e permite discutir o resultado com a equipe.
Revise cada campo separadamente
Abra a ferramenta e informe cinco campos, sem comando, nome de usuário ou declaração de ambiente. Escolha explicitamente um fuso aceito. Resolva os problemas de validação antes de interpretar datas: um resultado antigo nas suas anotações não demonstra o comportamento de uma expressão nova e inválida.
Construa a regra gradualmente. Comece com minuto e hora, depois restrinja dias da semana ou do mês. Use listas para valores separados, intervalos para conjuntos contínuos e passos para posições repetidas dentro de um campo. Após cada alteração, confirme que a expressão visível e as datas ainda representam a intenção original.
Para uma programação importante, reúna exemplos do começo e do fim do mês, da passagem pelo fim de semana e de uma mudança de horário quando houver no fuso escolhido. Preserve os instantes UTC junto das representações locais. Assim será possível comparar registros reais sem reconstruir qual deslocamento correspondia a uma hora ambígua.
Antes de copiar a expressão para o executor definitivo, consulte sua documentação. Uma prévia de cinco campos não comprova compatibilidade com um analisador de seis, uma sintaxe particular de um provedor ou um serviço cujo fuso esteja definido em outra configuração.
Entenda conjuntos, passos e campos de dia
O asterisco aceita todos os valores de um campo. Uma lista como 1,3,5 seleciona valores separados; um intervalo como 1-5 inclui os extremos. Um passo vale dentro do campo, não mede tempo contínuo desde a execução anterior. Portanto, */35 nos minutos seleciona zero e trinta e cinco de cada hora. Na passagem para a hora seguinte, o intervalo é de vinte e cinco minutos.
Os dois campos de dia merecem atenção específica. Quando nenhum começa com asterisco, a ferramenta aplica a combinação Unix OR: basta corresponder ao dia do mês ou ao dia da semana. Por exemplo, 0 9 1 * 1 representa nove horas no primeiro dia de cada mês e em todas as segundas-feiras. Não significa apenas os meses que começam numa segunda. Se algum começa com *, incluindo */n, ambas as seleções precisam corresponder. Assim, 0 9 */1 * 1 seleciona segundas; trocar */1 por 1-31 muda a combinação para OR.
O manual crontab do Cronie explica esses conceitos e outras variantes. O UtilX aceita um subconjunto numérico específico: números, asteriscos, listas, intervalos e passos. Uma extensão presente no manual geral não deve ser considerada automaticamente disponível nesta ferramenta.
Encontre regras plausíveis com a intenção errada
Um sexto campo costuma causar confusão. Alguns agendadores incluem segundos; outros acrescentam um ano. Remover um campo arbitrário pode mudar a regra silenciosamente. Identifique o dialeto de origem, traduza a necessidade e confira datas no destino. Nomes, macros e extensões como L, W, # e ? ficam fora do formato aceito.
Outro erro frequente é combinar data mensal e dia semanal esperando uma condição AND. Teste uma data que satisfaça somente um deles. Esse caso revela o mal-entendido melhor do que uma primeira correspondência que, por coincidência, atende às duas condições.
Uma prévia vazia ou incompleta também exige interpretação. A combinação pode ser impossível ou tão rara que não existam dez correspondências no horizonte de cinco anos. Não conclua que ela nunca executará apenas porque a lista está incompleta. Revise separadamente a validação, o fuso e a regra de calendário pretendida.
Confira mudanças de horário usando instantes concretos
Um fuso nomeado contém regras regionais; um deslocamento fixo descreve uma relação com UTC. Europe/Madrid não equivale a conservar sempre o mesmo deslocamento. A base de fusos horários da IANA mantém essas alterações e o ambiente recebe suas atualizações. As projeções dependem das regras disponíveis.
O caso diário 30 2 * * *, em Europe/Madrid, mostra por que é necessário conferir o motor. Em 29 de março de 2026, a hora inexistente 02:30 é deslocada para 03:30 locais, 01:30Z. Em 25 de outubro de 2026, é escolhida a primeira 02:30, 00:30Z, sem acrescentar a segunda. Essa evidência pertence à regra diária indicada e não deve ser generalizada para toda expressão.
Compare essa política com o executor real. Para um relatório associado à abertura de um escritório, um fuso regional expressa a necessidade. Para um processo explicitamente combinado em UTC, mantenha UTC. Documente a decisão para que uma troca de servidor não altere silenciosamente o relógio esperado.
Separe o cálculo da execução
A ferramenta procura até dez datas posteriores dentro de cinco anos e aceita expressões de até 256 caracteres. Ela não desenvolve todo o calendário futuro de uma tarefa. Uma regra rara pode produzir menos datas nesse intervalo; uma combinação impossível precisa ser corrigida, não pesquisada indefinidamente.
A página não executa comandos, salva tarefas agendadas ou garante entregas. Também não determina se uma execução vai se sobrepor à anterior, se a máquina estará desligada ou se uma nova tentativa duplicará um relatório. Essas propriedades pertencem ao executor e à aplicação.
Se você precisa de um único relatório por período de negócio, projete e teste essa propriedade separadamente. A expressão é uma parte da solução, junto dos registros de execução, do tratamento de falhas e de uma definição precisa do período que está sendo processado pela tarefa.
Preserve evidências úteis para manutenção
Guarde expressão, fuso, instante inicial e datas esperadas representativas. Revise limites de semana e mês, a combinação OR dos dias restritos e mudanças de horário relevantes. Declare se a necessidade segue UTC ou um relógio local e como serão tratados os feriados que cron não distingue.
Para o exemplo fixo, exija 00:15, 00:30 e 00:45 UTC depois da meia-noite de 1 de janeiro de 2026. Para a configuração real, compare o executor antes de ativar a tarefa. Mantenha testes operacionais separados para não confundir uma data calculada corretamente com um relatório entregue corretamente.
Fontes: manual crontab do Cronie e base de fusos horários da IANA.