A única checagem confiável num pipeline agendado é a idade do artefato

Abro o painel do agendador e está tudo lá: a tarefa habilitada, a próxima execução marcada, o status em Ready, nenhum erro no log da noite anterior. É exatamente o que qualquer ferramenta de orquestração mostra quando quer dizer que está tudo bem — e era o sinal em que eu confiava.

Esse painel mede uma coisa só: se o processo existe. Ele não mede se o processo produziu o que devia produzir. As duas situações, o sistema saudável e o sistema morto, produzem a mesma tela. Vi isso em dois sistemas meus, por caminhos diferentes, e a pergunta que sobrou foi curta. O que exatamente esse Ready está garantindo?

Ready mede a existência do processo, não o resultado

No DT Dashboard — o motor determinístico de day trading que mantenho — existe uma sub-rotina que transforma a conversa de uma comunidade no Discord em metodologia estruturada. É trabalho de triagem: ler o que foi dito, separar o que virou regra do que era só desabafo, guardar o resto. Roda agendado, sem ninguém olhando.

Ficou morto por três semanas. O status permaneceu Ready o tempo inteiro, a tarefa seguiu habilitada, o log não acusou nada. A causa foi um death-spiral de timeout: o processo travava, estourava o tempo e morria antes de gravar checkpoint. Como morria antes do checkpoint, não havia registro de fracasso — havia ausência de registro, que é uma coisa diferente e muito mais silenciosa.

Três semanas é o número que me interessa aqui. Não é uma execução perdida. É um hábito de confiança construído em cima de um indicador que nunca prometeu aquilo que eu achava que ele prometia.

Log quieto também engana, e engana ao contrário

O Solo Trader é o outro sistema: trading automatizado com gates de risco, stops por drawdown e trilha de auditoria versionada, em Python sobre Postgres, com polars, SQLAlchemy e dados da EODHD. Ele tem um watchdog no feed de barras justamente para isso — vigiar se o dado está chegando.

O watchdog reportava "EXPECTED IDLE". E estava certo. Pela regra que alguém escreveu, naquela janela era esperado não chegar barra nenhuma. Enquanto ele afirmava isso com toda a precisão, faltavam quatro horas de barras no armazenamento de dados.

O problema não é o agendador mentir. É ele responder com precisão a uma pergunta que não é a pergunta certa. "O processo está de pé?" e "o dado desta janela chegou?" são perguntas diferentes, e só a segunda tem consequência.

A checagem autoritativa é o artefato, nunca o processo

Existe uma checagem sem esse defeito: a idade do artefato de saída. Todo pipeline agendado produz alguma coisa — uma linha nova na tabela, um arquivo no disco, um registro com timestamp. Essa coisa tem idade. Compare a idade com a cadência esperada daquele pipeline e você sabe, sem ambiguidade, se ele está vivo no sentido que importa.

Os dois projetos chegaram na mesma correção sem que um soubesse do outro: monitor de idade de artefato, no lugar de monitor de existência de tarefa. Quando o mesmo conserto aparece duas vezes, por caminhos diferentes, ele parou de ser particularidade de um projeto. É o que recomendo hoje para qualquer pipeline agendado. E recomendo sabendo o que a troca custa — alguém vai ter que declarar, pipeline por pipeline, qual é a cadência esperada, e manter esse número quando ela mudar.

Nada disso é exclusividade de trading. Vale para ETL, para classificação com LLM, para relatório disparado por cron — qualquer sistema que produz algo em intervalos e tem gente confiando que ele produziu.

A cadência esperada é um número que alguém precisa manter

O custo da recomendação é concreto e não some com o tempo. O monitor de idade de artefato não descobre sozinho de quanto em quanto tempo o seu pipeline deveria produzir. Você declara. Um job roda a cada quinze minutos. Outro roda no fechamento do pregão. Outro só acorda quando chega arquivo do fornecedor. Cada um tem uma cadência própria, e cada cadência é uma linha de configuração que envelhece junto com o sistema.

Errar esse número para mais apertado produz alarme falso, e alarme falso é pior do que alarme nenhum, porque em poucas semanas todo mundo aprende a ignorar. Errar para mais frouxo produz o mesmo silêncio que a checagem deveria eliminar — só que atrasado, com o alerta disparando quando o estrago já tem idade.

Não conheço saída elegante. Conheço a comparação: manter uma dúzia de números de cadência é trabalho chato e visível. Descobrir três semanas depois que a triagem parou é trabalho invisível até o dia em que fica caro.

O teste que aplico agora, antes de considerar monitorado qualquer pipeline agendado, cabe numa pergunta. O que eu vejo no painel se o processo estiver morto e ainda marcado como Ready? Se a resposta for "nada diferente do que vejo hoje", o monitoramento está olhando para a coisa errada, por mais gráficos verdes que ele exiba.

Mudo de ideia no dia em que checar o status do agendador bastar, sem olhar o artefato, e isso não tiver custado a ninguém três semanas de triagem parada ou quatro horas de barra faltando. Até lá, Ready segue sendo uma promessa sobre o processo, não sobre o resultado.