Em 17 de agosto de 2026, o GitHub — a plataforma onde mora o código de boa parte do software do mundo — ficou 7 horas e 47 minutos fora do ar. Não foi ataque, não foi vírus, não foi alguém que apagou o arquivo errado. Foi falta de capacidade: o tráfego bateu um pico novo e um componente crítico não acompanhou.
Se a sua empresa não escreve software, a notícia parece distante. Ela não é. O que aconteceu ali acontece, em escala menor, com o sistema de gestão que você assina, com a maquininha de cartão, com o servidor de e-mail e com a sua loja virtual. A pergunta que este texto responde é uma só: o que a sua empresa faz nas horas em que o sistema de que ela depende não está lá?
O que aconteceu com o GitHub
A queda começou às 13h28 e terminou às 21h15 (horário UTC), segundo o relatório publicado pela própria empresa. Saíram do ar o site, a autenticação, o GitHub Actions, as APIs, os pull requests, as issues e o Copilot. No pico, cerca de 20% das requisições de web e API falhavam, e os downloads de arquivos e conteúdo bruto chegaram a 50% de erro.
Traduzindo para quem não é da área: durante quase oito horas, uma parte grande das equipes de tecnologia do mundo não conseguiu publicar nada. Quem tinha entrega marcada para aquele dia não entregou.
A causa não foi ataque nem bug — foi crescimento
Esta é a parte que mais interessa a quem toma decisão. O relatório do GitHub aponta saturação de rede nos balanceadores de carga do datacenter do centro dos Estados Unidos, provocada por um novo pico de tráfego. Não houve mudança de código nem configuração errada: a demanda passou do que a infraestrutura aguentava.
Os números explicam o tamanho do problema. Desde abril, os commits mensais na plataforma saltaram de 1,4 bilhão para 2,9 bilhões. Os pull requests aprovados chegaram a cerca de 130 milhões por mês e os repositórios novos, a 24 milhões por mês. A empresa diz ter acrescentado mais de 3 milhões de núcleos de processamento e 120 petabytes de armazenamento rápido, além de passar a servir cerca de 58% da carga pela infraestrutura da Azure.
Ou seja: o sucesso do produto foi a causa da queda. É o tipo de risco que ninguém coloca na planilha, porque ele não se parece com um problema — se parece com uma boa notícia. Vale para uma plataforma global e vale para a sua empresa no dia em que a campanha der certo e o site receber dez vezes mais gente do que o normal.
O detalhe que mais ensina: a repetição automática
Quando um sistema falha, os programas que dependem dele costumam tentar de novo, sozinhos. Parece razoável — e, feito sem cuidado, é o que transforma uma falha em uma queda longa. No caso do GitHub, o relatório é explícito: os erros dispararam um laço de novas tentativas do lado dos clientes que aumentou o tráfego durante a recuperação e atrasou a volta do Copilot.
Repare na ordem: a repetição automática não causou a queda, mas atrapalhou a saída dela. É um detalhe técnico com consequência prática direta para qualquer empresa que tenha integrações — emissão de nota fiscal, cobrança, envio de mensagem, sincronização com marketplace. A pergunta para o seu fornecedor ou para quem cuida do seu sistema é: quando a chamada falha, ele tenta de novo na hora, e quantas vezes? A resposta certa é esperar um pouco mais a cada tentativa e desistir depois de algumas — não martelar.
Antes do plano B, a pergunta que quase ninguém faz
A conversa sobre indisponibilidade quase sempre começa errado, pela tecnologia. Ela deveria começar pela conta: quanto custa uma hora parado, para cada parte do seu negócio?
Para uma loja virtual, é o faturamento médio da hora, mais os clientes que não voltam. Para uma clínica, é a agenda do dia. Para uma indústria, pode ser quase nada por algumas horas — e catastrófico se pegar o fechamento do mês. Sem esse número, qualquer discussão sobre redundância vira preferência pessoal, e a decisão acaba sendo tomada pelo susto do último problema.
A conclusão costuma incomodar: a maior parte dos sistemas de uma empresa não merece plano B. Dois ou três merecem, e é neles que o dinheiro deve ir.
Os quatro níveis de plano B
Do mais barato ao mais caro. Escolha o nível pelo custo da hora parada que você acabou de calcular.
1. Aviso. Saber que caiu antes de o cliente avisar. É o nível mais barato de todos e o mais ignorado: uma verificação automática a cada poucos minutos que manda mensagem quando o serviço não responde. Sem isso, o seu tempo de queda começa a contar quando alguém reclama.
2. Modo manual. O combinado escrito de como o time trabalha sem o sistema: anotar o pedido em papel, tirar foto da comanda, registrar depois. Custa uma folha e uma conversa, e é o que salva a operação na maioria das quedas curtas.
3. Alternativa fria. Uma segunda via do que importa, que não depende do fornecedor principal: a lista de clientes exportada toda semana, as notas guardadas fora do sistema, o cadastro num arquivo que você consegue abrir sozinho. Não substitui o sistema — evita que a queda vire perda.
4. Redundância quente. Um segundo caminho pronto para assumir. É o único nível que realmente elimina a parada, e é caro: paga-se por capacidade que fica ociosa quase o tempo todo. Só se justifica quando a hora parada custa mais que a assinatura do segundo caminho.
O que aprendemos derrubando o nosso próprio sistema
Duas histórias nossas, porque teoria de continuidade é fácil de escrever e difícil de praticar.
A primeira: em 2 de agosto, a nossa plataforma de realidade aumentada ficou fora do ar por cerca de quatro minutos. A causa foi um comando mal escrito que esvaziou um arquivo do servidor. O que encurtou a queda não foi nenhuma tecnologia sofisticada — foi ter guardado uma cópia do arquivo antes de trocar e ter o serviço configurado para reiniciar sozinho quando morre.
A segunda é pior, e é a que mais ensina. Criamos um script que pega os contatos enviados pelo formulário do site e manda por e-mail — e esquecemos de agendá-lo. Nada caiu. Nenhuma tela de erro, nenhum alarme, o site respondendo normalmente. Os contatos simplesmente ficavam parados numa fila, esperando um programa que nunca rodava.
A falha que assusta é a que derruba o site. A que custa dinheiro é a silenciosa. Por isso o nível 1 da lista acima não é "monitorar se o site está no ar", e sim "monitorar se o que dá dinheiro está acontecendo": o pedido está chegando, o e-mail está saindo, a cobrança está sendo emitida.
Como decidir, em quatro perguntas
Leve isto para a próxima conversa com quem cuida da sua tecnologia:
1. Quais são os dois ou três sistemas sem os quais a operação para hoje? 2. Quanto custa uma hora sem cada um deles? 3. Como eu fico sabendo que caiu — e em quanto tempo? 4. Existe um combinado escrito de como trabalhar sem ele, que alguém além do dono já leu?
Se a quarta pergunta não tiver resposta, é por ela que se começa: é a mais barata das quatro e a que mais reduz o estrago.
Quando a resposta passa por um sistema feito sob medida — porque o pronto não dá conta do seu processo, ou porque depender de um fornecedor só virou risco grande demais —, é disso que a gente cuida: desenvolvimento de software personalizado. E se a dúvida ainda for entre contratar algo pronto ou mandar fazer, escrevemos sobre como decidir entre software personalizado e sistema pronto.
Fontes
Relatório oficial do GitHub sobre a queda de 17 de agosto de 2026 ("The August 17 outage, and the work ahead"), publicado no blog da empresa. Os números de duração, serviços afetados, taxa de erro, volume de commits e capacidade acrescentada vêm de lá.
Perguntas frequentes
Quanto tempo o meu sistema pode ficar fora do ar sem prejuízo?
Não existe número universal — depende do que uma hora parada custa no seu negócio. O caminho é calcular por sistema: faturamento médio da hora para uma loja, agenda do dia para uma clínica, risco de fechamento do mês para uma indústria. Esse número é o que define quanto vale a pena gastar para reduzir a parada.
Backup e plano B são a mesma coisa?
Não. Backup é a cópia dos dados, e serve para você não perder o que já tinha. Plano B é como a operação continua enquanto o sistema não volta. Dá para ter backup perfeito e mesmo assim ficar oito horas sem atender ninguém.
O que é uma página de status e por que ela importa?
É a página onde o fornecedor publica se o serviço dele está funcionando. Importa porque encurta o tempo entre a queda e a sua decisão: em vez de gastar meia hora achando que o problema é seu, você confirma em um minuto que é do fornecedor e aciona o modo manual.
Contratar um sistema pronto é mais seguro do que mandar fazer um sob medida?
Nem mais nem menos — o risco muda de lugar. No pronto você depende da capacidade e das prioridades do fornecedor, e a queda dele é a sua queda. No sob medida você controla a infraestrutura e a ordem dos consertos, mas precisa de alguém responsável por isso. A escolha depende de qual dos dois riscos a sua empresa consegue administrar melhor.
Como saber se as minhas integrações repetem chamadas do jeito errado?
Pergunte a quem cuida do sistema três coisas: quantas vezes uma chamada que falha é repetida, se o intervalo entre as tentativas aumenta a cada uma, e se existe um limite depois do qual ela desiste e registra o erro. Repetição imediata e sem limite é o padrão que transforma uma falha curta em uma queda longa.
Vale pagar por redundância?
Só quando a hora parada custa mais do que o segundo caminho ocioso. Para a maioria das pequenas e médias empresas, os três primeiros níveis — aviso, modo manual e alternativa fria — resolvem a maior parte do problema por uma fração do preço, e é neles que faz sentido começar.