# Sua automação parou. Quando você vai descobrir? > A automação que para não emite aviso, ela só deixa de rodar. Veja por que a falha silenciosa é o padrão e as quatro decisões que devolvem o alarme. - Autor: Marlon Trettin - Publicado: 2026-10-14 · Atualizado: 2026-10-14 - Idioma: pt-BR - Canonical: https://yowpi.com/blog/automacao-parou-quando-voce-vai-descobrir --- Quem descobre que a automação parou costuma ser o cliente que ligou cobrando. A rotina não avisa quando falha, ela apenas deixa de rodar, e o silêncio se parece com funcionamento normal. Fazer a operação avisar é decisão de arquitetura, não escolha de ferramenta de monitoramento. ## TL;DR - A automação que para não emite erro para ninguém que esteja olhando. O sinal de saúde dela é a ausência de reclamação, que é também o sinal de que ela morreu. - Em 198 falhas reais analisadas por Yuan e colegas na OSDI de 2014, 92% das falhas catastróficas vieram do tratamento incorreto de um erro que o software já tinha sinalizado. Em 35% dessas falhas catastróficas, o trecho responsável por tratar o erro caía em padrões triviais, como estar vazio ou apenas escrever uma linha de log. - O prazo das ligações entre sistemas está encolhendo. Desde 15 de março de 2026 o certificado TLS vale no máximo 200 dias, cai para 100 em 2027 e para 47 em 2029. A Let's Encrypt encerrou o e-mail de aviso de vencimento em 4 de junho de 2025. - Quatro decisões devolvem o alarme: sinal de vida, conferência das duas pontas, inventário de vencimentos com dono e um destino definido para o erro. ## Por que a falha silenciosa é o estado normal de uma automação? Porque o erro que aparece na tela tem uma pessoa olhando para ele, e o erro que acontece às três da manhã não tem. A diferença é essa. Quando um usuário clica e a tela trava, existe alguém incomodado e um chamado aberto em minutos. Quando a rotina noturna que empurra pedidos do portal para o ERP falha, não existe pessoa nenhuma na cena. O sintoma é um número um pouco menor no dia seguinte, e um número menor sempre encontra uma explicação plausível. O problema é mais antigo e mais estrutural que a sua operação. Yuan e colegas estudaram 198 falhas reais reportadas por usuários em cinco sistemas de dados de uso amplo, entre eles Cassandra, HDFS e Redis, e publicaram o resultado na [OSDI de 2014](https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf). Em 92% das falhas catastróficas, a causa foi o tratamento incorreto de um erro não fatal que o próprio software já havia detectado e sinalizado. Releia a frase, porque ela desmonta a intuição comum. O erro foi visto. Ele só não foi levado a ninguém. O detalhe seguinte é pior. Em 35% das falhas catastróficas, o trecho de código que deveria tratar o erro caía em três padrões triviais, entre eles estar vazio ou conter apenas uma linha de log. Log que ninguém lê é silêncio com carimbo de data. Os autores calculam ainda que um teste simples do próprio tratamento de erro teria apanhado 58% dessas falhas catastróficas. O estudo é de 2014 e trata de software de infraestrutura, não da sua integração de pedidos. A lógica é a mesma sempre que alguém precisa decidir o que o programa faz quando o outro lado não responde, e esse alguém não é quem vai sentir a consequência. ## O que na sua operação tem data de validade? Mais coisas do que estão anotadas em algum lugar com dono. Certificado digital, chave de API, token de acesso, senha de serviço, contrato de fornecedor e o cartão que paga a assinatura da ferramenta. No Brasil, o certificado ICP-Brasil do tipo A1 vale um ano e o A3 vai de um a cinco, [segundo o ITI](https://www.gov.br/iti/pt-br/acesso-a-informacao/perguntas-frequentes/certificacao-digital). Uma data por ano, em uma única linha do inventário. O certificado que sustenta a ligação técnica entre dois sistemas encolheu mais rápido. O CA/Browser Forum, onde emissores de certificado e fabricantes de navegador definem essas regras, aprovou em 11 de abril de 2025 a [redução progressiva do prazo](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/), com 25 votos a favor, nenhum contra e 5 abstenções entre os emissores, e 4 a zero entre os navegadores. Pela [tabela de datas do documento normativo](https://cabforum.org/working-groups/server/baseline-requirements/requirements/), o máximo caiu de 398 para 200 dias em 15 de março de 2026, vai para 100 dias em 15 de março de 2027 e para 47 dias em 15 de março de 2029. Uma tarefa por ano virou duas, depois quase quatro, e em 2029 serão perto de oito. No mesmo período o lembrete foi desligado. A Let's Encrypt [encerrou o serviço de aviso de vencimento por e-mail em 4 de junho de 2025](https://letsencrypt.org/2025/06/26/expiration-notification-service-has-ended), citando, entre outros motivos, que muitos assinantes já automatizaram a renovação. O argumento está certo para quem automatizou. Para quem dependia daquele e-mail, o alarme saiu do ar nove meses antes de a frequência da tarefa dobrar. ## Quanto tempo o relatório continua contando um ganho que já parou? Até alguém conferir a execução, e essa conferência não está no calendário de ninguém. O caso de negócio da automação foi aprovado com uma conta de horas por execução vezes execuções por mês, e essa conta continua rodando na planilha depois que a rotina morreu. A distorção é dupla. O ganho segue reportado no número cheio e o retrabalho manual que voltou aparece diluído na folha, sem nome próprio. Isso é raciocínio sobre a mecânica do indicador, não medição de campo, e é uma das razões pelas quais [o retorno de uma automação precisa ser medido no fluxo, não na estimativa de aprovação](/blog/roi-automacao-de-processos). Vale um exemplo, e ele é uma hipótese: os números abaixo são ilustrativos e não descrevem nenhum cliente. Uma distribuidora com faturamento acima de R$ 200 mil por mês liga o portal de pedidos ao ERP: o pedido entra no portal e uma rotina cria o pedido correspondente no ERP a cada quinze minutos. O fornecedor do portal muda o formato de um campo de data. A rotina passa a falhar apenas nos pedidos com entrega agendada e continua funcionando em todo o resto. Ninguém percebe. A queda de volume cabe dentro da variação normal do mês, e a equipe resolve o problema no nível dela: volta a digitar aqueles pedidos à mão, porque é mais rápido que abrir chamado. A automação está morta em uma fatia do fluxo, o relatório mostra o ganho inteiro e o time absorveu a diferença sem contar a ninguém. Repare no formato dessa falha. A parada total vira reclamação em horas. A falha parcial cabe dentro da variação normal e sobrevive meses. ## O que faz a operação avisar quando algo para? Quatro decisões, todas anteriores à escolha de qualquer ferramenta. A primeira é o sinal de vida. A rotina precisa registrar que rodou, e não apenas gritar quando falha, porque a rotina que morreu não grita. Se o registro de execução não chega dentro da janela esperada, isso é o alarme. Ausência de notícia vira notícia. A segunda é a conferência das duas pontas. Quantos pedidos saíram do portal e quantos entraram no ERP no mesmo período. Essa comparação não depende de o erro ter sido tratado corretamente lá dentro, e é ela que pega a falha parcial do exemplo acima. A terceira é o inventário de vencimentos com dono. Uma lista de cada ligação, com o que vence, quando vence e quem responde por ela. Enquanto a data morar na caixa de e-mail de quem configurou a integração, ela sai da empresa junto com a pessoa. É o mesmo hábito que sustenta [documentar e versionar automações](/blog/documentar-versionar-automacoes-corporativas), aplicado ao prazo de validade. A quarta é o destino do erro. Todo erro precisa de um endereço humano e de uma ação esperada, senão ele volta a ser uma linha de log. Definir isso é decidir quem é chamado, em quanto tempo e o que essa pessoa tem alçada para fazer, e a falta dessa definição é uma [das falhas que mais comprometem integrações de sistemas internos](/blog/5-falhas-que-comprometem-integracoes-de-sistemas-internos). Nenhuma das quatro é compra de software de monitoramento. Monitorar servidor responde se a máquina está de pé. A pergunta do negócio é outra: o pedido chegou do outro lado. Nenhuma ferramenta responde isso sem que alguém tenha definido antes o que deveria ter chegado. A [UniTrust, IMO de seguros dos EUA, gerencia apólices, agentes e comissões desde 2022](/cases/unitrust) e a [Reatop registra resíduos hospitalares em campo, com uso offline e sincronização posterior](/cases/reatop). Em operações assim, o desenho começa pela mesma pergunta: como o sistema prova que o registro chegou. ## Perguntas frequentes **A implementação disso não vai consumir tempo demais do meu time?** Três das quatro decisões são desenho, não construção. Definir quem recebe o erro, o que precisa bater entre as duas pontas e quem responde por cada vencimento é trabalho de reunião. A parte que vira código são dois itens, o registro de execução e a contagem comparada, e nenhum dos dois exige mexer na lógica da integração que já está de pé. **Como eu meço o resultado de um alarme, se ele só serve para avisar que algo parou?** Com dois números que a sua operação já consegue contar. O tempo entre a parada e a descoberta, e quantas ocorrências foram descobertas pelo sistema em vez de pelo cliente. Se o segundo número não melhora depois da mudança, o desenho está errado, e essa também é uma resposta útil. **Isso não é só mais um painel que ninguém vai olhar?** Seria, se a saída fosse um painel. Painel depende de alguém lembrar de abrir, e a falha silenciosa acontece justamente quando ninguém lembrou. O que muda a operação é o caminho inverso: a divergência procura uma pessoa nomeada, com prazo e alçada para agir. ## O próximo passo Se você não sabe dizer hoje quantas ligações a sua operação tem e qual delas avisa quando para, o Diagnóstico de Arquitetura Operacional é uma conversa de 30 minutos para mapear isso. [Fale com um arquiteto](/contato).