O que é cron job e como ele faz sua automação rodar sozinha

Cron job é uma tarefa que o servidor executa sozinho, em horários definidos por você, sem ninguém clicar em nada. É ele que publica o post agendado às 7h, manda o relatório toda segunda de manhã, limpa registros antigos de madrugada e tenta de novo o que falhou na rodada anterior.

Se você monta automação com Supabase, Make ou n8n, já usa cron job mesmo sem saber o nome. Entender como ele funciona evita os erros mais comuns de automação: post saindo três horas fora do horário, tarefa rodando duas vezes e falha que acontece todo dia sem aparecer em lugar nenhum.

De onde vem o nome

O cron nasceu nos sistemas Unix como um programa que fica rodando em segundo plano e confere, minuto a minuto, se existe alguma tarefa marcada para aquele momento. A lista de tarefas fica numa tabela chamada crontab, e cada linha dessa tabela é um cron job: um horário mais um comando.

A ideia sobreviveu a tudo. Hoje o mesmo formato de agendamento aparece dentro do banco de dados (pg_cron no Postgres), em plataformas de automação, em serviços de hospedagem e em praticamente todo agendador que você vai encontrar.

Como ler uma expressão cron

O horário de um cron job é escrito numa expressão de cinco campos, separados por espaço:

O asterisco significa "qualquer valor". A barra define um intervalo, a vírgula separa uma lista e o hífen marca uma faixa. Com essas quatro peças você escreve quase qualquer agenda:

Repare que nenhuma expressão diz o fuso horário. Esse detalhe causa o erro número um de quem começa, e ele tem uma seção só dele mais abaixo.

Onde o cron aparece no seu stack

Supabase: pg_cron

No Supabase, o agendamento roda dentro do próprio banco, com a extensão pg_cron. Você ativa a extensão no painel (Database, Extensions) e agenda tarefas com SQL. Para chamar uma rota do seu site ou uma edge function, o pg_cron trabalha junto com o pg_net, que faz requisições HTTP de dentro do banco:

-- Agenda uma chamada a cada 5 minutos
select cron.schedule(
  'renderizar-carrosseis',          -- nome do job
  '*/5 * * * *',                    -- expressão cron
  $$
  select net.http_post(
    url := 'https://seusite.com.br/api/hooks/renderizar',
    headers := '{"Content-Type": "application/json", "x-cron-secret": "SEU_SEGREDO"}'::jsonb,
    body := '{}'::jsonb
  );
  $$
);

-- Lista os jobs agendados
select jobname, schedule, active from cron.job;

-- Remove um job pelo nome
select cron.unschedule('renderizar-carrosseis');

O segredo no cabeçalho impede que qualquer pessoa que descubra a URL dispare a sua rota. Num projeto real, guarde esse valor no Vault do Supabase em vez de deixá-lo escrito no SQL.

Make e n8n

No Make, cada cenário tem uma configuração de agendamento: intervalos regulares, horários fixos por dia, dias da semana ou do mês. O intervalo mínimo depende do plano, então confira o seu antes de desenhar uma automação que precisa rodar a cada minuto.

No n8n, o agendamento fica no nó Schedule Trigger, que aceita tanto opções prontas (a cada X minutos, todo dia em tal horário) quanto uma expressão cron personalizada. Se você está decidindo entre os dois, a comparação completa está em Make vs n8n.

O fuso horário que engana todo mundo

O pg_cron executa os horários em UTC por padrão, e não no horário de Brasília. Como o Brasil não tem horário de verão desde 2019, a conta é fixa: Brasília é UTC menos 3 horas.

Na prática, para algo rodar às 7h de Brasília, a expressão é 0 10 * * *. Se você escrever 0 7 * * *, a tarefa roda às 4h da manhã no Brasil. Esse erro passa despercebido em teste, porque quase ninguém testa agendamento esperando o horário chegar.

Make e n8n deixam você escolher o fuso nas configurações do cenário ou da instância. Confira uma vez e anote.

Cron que executa e cron que verifica

Existem dois jeitos de usar cron em automação de conteúdo, e entender a diferença muda a arquitetura.

O primeiro é o cron que executa: um job para cada tarefa, no horário exato. "Publique este post às 10:00" vira um job marcado para as 10:00. Funciona para poucas tarefas, mas cria um job novo a cada agendamento e complica cancelar ou mudar o horário.

O segundo é o cron que verifica: um único job roda a cada poucos minutos e pergunta ao banco "tem alguma coisa com horário vencido esperando?". Os posts guardam o próprio horário numa coluna, e o job publica tudo que já passou da hora. É assim que o publicador do lowcode.ai funciona, e é o padrão que eu recomendo. Mudar o horário de um post vira só editar uma data, e o mesmo job cuida de mil posts.

Os erros mais comuns

Tarefa processada duas vezes

Se o job roda a cada 5 minutos e uma execução demora mais que isso, a próxima começa antes da anterior terminar e as duas pegam o mesmo item. A solução é marcar o item como "em processamento", com um horário, antes de começar, e fazer as execuções seguintes ignorarem o que já está marcado. Limitar o lote (por exemplo, 5 itens por rodada) também ajuda.

Tentativas que acabam cedo demais

Um limite de tentativas protege contra loop infinito, mas precisa conversar com o tempo real das etapas. Eu tive um publicador que desistia depois de 6 tentativas a cada 5 minutos, ou seja, meia hora, enquanto a etapa anterior dependia de alguém abrir o painel. Contei essa história em navegador ou servidor: onde gerar as imagens da sua automação.

O job "deu certo", mas nada aconteceu

Esse é o mais traiçoeiro. O pg_net faz requisições de forma assíncrona: quando o cron chama uma URL com net.http_post, o job termina assim que a requisição entra na fila. O registro de execução do cron mostra sucesso mesmo que a rota tenha devolvido erro 500. A resposta real fica em outra tabela:

-- Últimas respostas das chamadas HTTP feitas pelo banco
select id, status_code, content, created
from net._http_response
order by created desc
limit 20;

Se a sua automação falha "sem motivo", olhe essa tabela antes de qualquer outra coisa. E a rota chamada pelo cron deve gravar o próprio erro no registro que estava processando, para o problema aparecer no painel. Os erros de rede mais frequentes nesse tipo de chamada estão em rate limit, timeout e retry.

Projeto pausado, agenda pausada

O pg_cron roda dentro do banco. Se o projeto do Supabase for pausado por inatividade, todos os jobs param junto, sem aviso. Em projeto que está indo para produção, isso entra no checklist de lançamento, como mostro em colocando o SaaS no ar sem quebrar no primeiro dia.

O que fazer agora

1. Liste todas as tarefas da sua operação que dependem de horário: publicação, relatórios, limpezas, reprocessamentos.
2. Para cada uma, escreva a expressão cron no horário de Brasília e converta para UTC somando 3 horas antes de agendar no pg_cron.
3. Troque jobs de horário exato por um job que verifica a cada poucos minutos e processa o que estiver vencido, com a data guardada no próprio registro.
4. Antes de processar cada item, marque o horário de início para evitar execução duplicada, e limite quantos itens cada rodada pega.
5. Rode select * from cron.job; e confira se só existem os jobs que você reconhece. Remova os esquecidos com cron.unschedule.
6. Consulte net._http_response depois da primeira rodada de cada job novo, para confirmar que a rota chamada respondeu 200.
7. Proteja toda rota chamada por cron com um segredo no cabeçalho, guardado no Vault.