Como saber se uma automação parou mesmo quando o botão dá erro

Na aula Sextas Ímpares #151, eu estava a mostrar a central de gestão de anúncios que construí para o AdSummit, uma automação que corre num cron horário e ajusta orçamentos com base numa matriz de regras que eu próprio defini, sem chamada a nenhum modelo de linguagem por trás. A meio da demonstração tentei desligar o botão de uma automação e a interface devolveu erro. A causa foi simples: tinha perdido a ligação Wi-Fi porque estava a gravar dentro do carro. Percebi o problema em segundos, ao notar que estava sem rede.

O episódio é pequeno, mas vale a pena olhar para ele com atenção, porque é este tipo de falha silenciosa que separa uma automação em que confias de uma que continua a agir sem que saibas.

O que significa um botão que não confirma nada

Um botão de ligar/desligar só é útil se o que mostra corresponder ao que realmente aconteceu no servidor. Se a interface muda de estado visualmente sem esperar por confirmação, cria-se uma falsa sensação de controlo, algo comum em painéis feitos à pressa, onde o clique altera logo o ícone antes de qualquer resposta do backend.

No meu caso, o erro apareceu de imediato, o que já é uma vantagem: soube logo que o comando não tinha chegado a lado nenhum. O risco maior é o cenário oposto, quando a interface aceita o clique, muda o botão de posição, e nunca verificas se o pedido foi de facto processado do outro lado. Nesse caso a rotina automática pode continuar a correr, a gastar orçamento ou a disparar ações, enquanto tu já achas o assunto resolvido.

Se estiveres a construir os teus próprios painéis para gerir campanhas ou processos, vale a pena tratar isto como critério mínimo: o painel só deve dizer que algo está parado depois de o servidor confirmar essa mudança de estado. Podes, por exemplo, mostrar um estado intermédio, algo como "a confirmar", em vez de saltar direto para "parado".

Perder a ligação não é um caso raro

O que me aconteceu foi trivial: estava a gravar dentro do carro, sem rede fixa, e a ligação caiu. Não foi um erro do sistema, foi uma falha de infraestrutura fora do meu controlo. É este tipo de falha, banal e comum, que qualquer automação encontra em algum momento, por instabilidade de rede ou indisponibilidade momentânea de um serviço externo.

Se quem opera o teu painel não sabe distinguir "o pedido falhou por causa da rede" de "o pedido foi recusado pelo servidor" de "o pedido foi aceite mas ainda não foi processado", começamos por aí. É essa distinção simples e concreta que decide se confias no que vês no ecrã ou se vais verificar manualmente do outro lado, por exemplo abrindo a própria plataforma de anúncios para confirmar o estado real de uma campanha.

No meu caso concreto, bastou eu perceber, em poucos segundos, que estava sem Wi-Fi, para saber que o problema não era do servidor da automação nem da minha matriz de regras. Foi só uma questão de rede local. Mas se eu não tivesse essa clareza imediata, podia ter perdido tempo a duvidar da automação em si, quando o problema estava a três metros de mim, no meu telefone sem sinal.

Que limites defino antes de uma automação mexer no orçamento dos anúncios

Como testar uma automação antes de a entregar à equipa

Como planear uma aplicação com Claude Code antes de começar a programar

Para desenhar a execução e tratar as exceções, consulta o guia de automação de processos empresariais.

Quando vale a pena verificar manualmente

A matriz que construí para o AdSummit corre sozinha, sem intervenção de um modelo de IA a decidir em tempo real: são regras fixas, definidas por mim, aplicadas a cada hora sobre os dados de desempenho dos anúncios. Recebo, no WhatsApp, um relatório a cada checkpoint horário.

Essa disciplina de reporte é o que me permite confiar que a automação está a fazer o que devia, mesmo estando de férias, sem ter de abrir constantemente o gestor de anúncios. Mas isso não substitui a confirmação de estado quando tentas intervir manualmente. Se decides parar uma rotina porque algo parece errado, e a interface não confirma a paragem, a atitude sensata é ir verificar diretamente na plataforma de origem, no meu caso o gestor de anúncios do Meta, se a alteração de facto aconteceu.

Esta verificação manual não precisa de ser feita sempre. Se a automação está a correr de forma previsível, com relatórios regulares e sem sinais de alarme, não faz sentido estar constantemente a confirmar tudo à mão, isso anularia a vantagem de ter automatizado o processo. Mas no momento exato em que decides intervir e o sistema não confirma essa intervenção, aí sim vale a pena parar e confirmar do outro lado antes de seguir com o dia.

PARAR, REVER, RETOMAR

Quando as condições mudam, interrompe a execução, revê a situação e confirma o que permite retomar.

O que isto significa para quem constrói as próprias ferramentas

Cada vez mais gestores de tráfego e donos de negócio estão a montar as suas próprias centrais de operação com automações, em vez de depender só das plataformas nativas. Isso dá mais controlo, mas também transfere para ti a responsabilidade de garantir que o painel não mente sobre o que está a acontecer.

Precisas que qualquer botão de paragem aguarde pela resposta do servidor antes de mostrar sucesso. Se essa resposta falhar, o painel deve indicar claramente que desconhece o estado atual. A confirmação correta do estado permite-te confiar no sistema e evita decisões com dinheiro real em campanhas ativas baseadas em dados incorretos.

Pensa num caso simples: uma campanha está a receber alterações automáticas e o cliente avisa que a oferta mudou. Eu começaria por perceber que ações ainda fazem sentido com essa nova informação. O critério que estava certo para a oferta anterior pode precisar de revisão.

Para organizar essa conversa, podes registar quando surgiu a alteração, qual a regra afetada e quem vai confirmar as novas condições. Depois, verificas o estado da campanha e decides o que retomar. Este é um exemplo de aplicação do raciocínio da aula, não uma descrição de uma funcionalidade que tenha demonstrado. A utilidade está em tornar explícita a decisão que a equipa precisa de tomar.

Nota da fonte

Este artigo parte de um momento concreto da Sexta Ímpar #151, a partir de cerca de 43:37, quando tentei desligar uma automação no meu painel de gestão do AdSummit e a interface devolveu um erro por perda de ligação Wi-Fi. Podes ver a aula completa aqui: https://www.youtube.com/watch?v=SYe0ebyVZ5c

Passagem 1 · 00:43:45 · Passagem 2 · 00:43:37