Foram 7 horas e 47 minutos fora do ar. Autenticação no chão, Actions parado, o mundo inteiro sem deploy. E eu aqui, com o meu Git no meu ambiente, sem sentir nada.
Resposta rápida: em 17/08/2026 o GitHub ficou 7h47 fora do ar — saturação de rede num data center, cascata até a camada de proxy e a autenticação inteira no chão. Sem login, sem Actions, sem API. É a terceira vez que eu venho falar disso, e eu não uso GitHub: eu rodo o meu próprio Git na minha infraestrutura há mais de 10 anos, com runners distribuídos, atrás de VPN e com 2FA obrigatório. Se você já recebe dinheiro de cliente pra manter serviço no ar, a resposta não é migrar pra outra nuvem — é ter o seu ambiente. Você domina a tecnologia ou a tecnologia te domina.
15 minutos, sem corte — do canal @josimarjmv, publicado em 21/08/2026. Gravei quente, dias depois da queda. Aqui embaixo eu conto a mesma coisa por escrito, com calma e com os números que eu fui conferir na fonte oficial depois.
🎧 PREFERE OUVIR? · 15 min
Este artigo também é um episódio do podcast Josimar JMV | Em Produção — o mesmo vídeo, só o áudio, normalizado pra fone.
Vou dar minha carteirada antes, pra quem está chegando agora: meu nome é Josimar, eu sou CEO de uma empresa de tecnologia e eu boto a mão na massa. Eu desenvolvo, eu pago conta, eu pago folha de pagamento, eu contrato, eu faço gestão, marketing, venda e suporte. Óbvio que eu não faço tudo sozinho, eu tenho equipe — mas eu tenho a visão ampla do negócio, e não só a do dev emocionado ou a do cara de infra emocionado.
E eu avisei. Eu avisei. É a terceira vez que eu venho aqui falar do GitHub, e é a terceira vez pelo mesmo motivo: não dá pra você usar GitHub em produção de forma séria.
"Poxa, Josimar, está de sacanagem, o mundo inteiro usa. Quem é a sua empresa pra falar do GitHub?" Eu sou a empresa que está falando mal do GitHub pela terceira vez, que não usa, que não bota a operação lá dentro e que tem conta só pra pegar teste que desenvolvedor me mandou. Eu não tenho um repositório meu lá. A única vez recente que eu usei foi pra testar o Jules do Google, porque na época ele só integrava com GitHub — e nem por isso eu mudei de ideia.
Na hora de gravar eu falei de cabeça: mais de 8 horas fora do ar, saturação de rede, caiu a autenticação, os proxies lotaram, bateu quase 100 mil requisições por segundo. Fui conferir depois no comunicado oficial do próprio GitHub, e o quadro é esse:
Checagem minha, hoje (08/09/2026) — inclusive contra mim. Eu disse "mais de 8 horas". O número oficial é 7 horas e 47 minutos. Corrigido: o certo já é feio o bastante, eu não preciso arredondar pra cima. Eu disse que faltou rate limit; o comunicado deles chama de retry limits e retry budgets, e é justamente o que eles se comprometeram a implementar depois. Nome diferente, doença igual: ninguém pôs limite no volume de tentativa. O número que eu falei de cabeça bateu: o tráfego saiu de 7 a 9 mil requisições por segundo e foi pra 70 a 100 mil.
Aqui está a parte que interessa pra você, e não é fofoca de manchete. Por que a pressão aumentou tanto? Porque todo curso raso ensina você a subir código onde? GitHub. Você vai integrar o agente do Cursor pra fazer automação, integra onde? GitHub. Você faz o seu crudezinho, sobe onde? GitHub. O volume de código no GitHub aumentou de forma gigantesca — e o pior é onde isso bate primeiro.
Pensa comigo: você é desenvolvedor, faz o seu pull request, e o que tem que rodar? O runner, o Actions, no seu ambiente de sandbox, staging ou produção. Agora entra a IA na conta. Todo mundo produz código em horário comercial muito mais acelerado. Ou seja: exige-se muito mais dos runners. Roda pipeline e deploy muito mais vezes do que rodava quando a galera escrevia na mão. Isso bota uma pressão gigante numa coisa que é maravilhosa, mas é pesada.
E olha o que o próprio comunicado deles entrega, sem meia palavra: os commits mensais na plataforma dobraram de 1,4 bilhão em abril de 2026 pra 2,9 bilhões em agosto. Dobrou em quatro meses. Eles mesmos escrevem que esse crescimento explica a pressão, mas não desculpa as quedas. Eu assino embaixo dessa frase — e ela confirma exatamente o que eu venho falando desde o primeiro vídeo.
Como é que eu sei que é pesado? Porque eu tenho o meu próprio Git na minha própria infraestrutura. Faz uns 10 anos que eu rodo GitLab no meu ambiente — desde a versão que a gente subia na mão, antes de Docker, antes de tudo. Tenho os meus runners distribuídos, tudo sob a minha régua. Pode cair o GitHub, pode ficar fora do ar o dia inteiro: eu não sinto nada.
A Microsoft tinha que ter um pouco mais de atenção nisso, gente do céu. Se a Microsoft não se atentou ao limite de tentativa no caminho de login, quem somos nós nessa vida? Nós somos as pessoas que se atentam a isso — porque quem entende de infraestrutura sabe que limite de requisição derruba qualquer coisa: CDN, API, proxy, o que for. Isso é tratamento básico. Básico.
E repara que não é a primeira vez, nem é sempre o mesmo tipo de problema. No vídeo anterior eu falei dos milhares de repositórios afetados numa invasão por engenharia social. Dessa vez não teve engenharia social nenhuma: foi cagada de casa mesmo, pelo que eu li no comunicado deles. São falhas de naturezas diferentes chegando no mesmo lugar — o que só reforça o meu ponto sobre por que eu não uso GitHub, Supabase ou Firebase em produção: cada plataforma que você adota é mais uma superfície de ataque e mais uma coisa que você não controla.
Aí você fala: beleza, vou pro GitLab. Legal. Mas o que você acha que vai acontecer se todo mundo que está gerando código com IA migrar pro GitLab na nuvem? Pode ser que eles tenham mais esperteza que a Microsoft, pode ser que não. Eu não vou apostar a minha operação nesse "pode ser".
Um adendo honesto: a galera reclama demais que o GitHub funcionava muito bem antes de a Microsoft comprar. Eu, como nunca usei GitHub de verdade, não posso opinar sobre isso. Eu falo do que eu faço no dia a dia, e só.
O que resolve é o GitLab no seu ambiente. Ele não tem todas as features da versão em nuvem, e você pode pagar pela versão self-hosted se quiser. Eu já paguei uma versão do GitLab um dia. Hoje eu uso a Community Edition, a gratuita, e ela me atende perfeitamente — porque eu coloquei hooks personalizados ali dentro pra fazer o que a versão paga fazia. Free com hook feito por quem sabe o que quer. Resolve.
Vou ser bem claro sobre pra quem eu estou falando, porque não é pra todo mundo.
Se você é desenvolvedor júnior, não está nem aí pro seu código e ainda está brincando, está tudo bem: continua no GitHub e só passe raiva quando o Actions estiver fora do ar. Beleza. Sem problema nenhum.
Agora, se você trabalha numa empresa que precisa fazer deploy em horário comercial, ou se você é o vibe coder que começou a colocar em produção coisa pela qual recebe de cliente, mudou tudo. A grande virada de profissionalizar o seu negócio e se preocupar com alta disponibilidade é exatamente esse momento: você está recebendo dinheiro de gente pra manter um serviço no ar. Aí você precisa de backup, redundância, disponibilidade e deploy rápido.
Pensa na cena. Caiu o serviço, você precisa corrigir uma coisinha rápida — e não tem deploy, porque o runner está fora. Você vai fazer o quê? Ou você espera o runner voltar e vai acendendo velinha, ou você entra de SSH e muda o código na mão, direto no servidor. Que loucura. É essa a doideira que eu quero que você nunca precise fazer, e é primo-irmão do medo de subir em produção que quase todo mundo carrega.
Não é receita de guru, é o que roda na minha casa há anos:
docker run. O que segura a sua empresa é saber fazer backup, rollback e monitoramento — e ter testado os três.E se você já tem empresa e está usando GitHub, a tarefa é outra: é hora de treinar a sua equipe — ou você mesmo, se você não bota a mão na massa, treina alguém, ou vocês dois juntos — pra entender e subir o ambiente de vocês. Isso não é despesa, é a diferença entre depender de um comunicado de outra empresa e resolver o seu problema no seu horário. É a mesma tese que eu defendo em infraestrutura é o novo superpoder na era da IA.
Esse relato é do vídeo de 21/08/2026, gravado quatro dias depois da queda. Uma coisa que eu comentei lá de cabeça e que eu fui conferir pra registrar direito aqui: eu falei do Elon Musk, do Grok e de uma compra do Cursor, e embolei os nomes na hora — inclusive falando que tinha esquecido. O que aconteceu de fato, e eu confiro agora: a SpaceX fechou a compra da Anysphere, dona do Cursor, por US$ 60 bilhões em ações, concluída em 14/08/2026, e dobrou a empresa numa divisão nova de IA, depois de já ter absorvido a xAI. Ou seja: o ambiente de repositório passa a viver dentro da IA. Meu ponto continua de pé, e agora com o nome certo e a data certa.
Se funcionar bem eu testo — não testei ainda. E quando eu testar, vai ser do meu jeito: eu não testo pra fazer vídeo. Eu testo, coloco em produção, vejo num pipeline de verdade e trago a minha opinião baseada no meu uso de verdade. Não é opinião de leitor de notícia à toa.
Pra mim o GitHub vai continuar caindo e as pessoas vão migrar. Pode anotar aí: daqui uns dias eu venho gravar o quarto vídeo. Não tem jeito — e o próprio comunicado deles admite que esse foi o segundo incidente grande só no mês de agosto.
Você pode testar o Grok, pode testar amanhã o João, a Maria, o Pedro. Ou pode ter o seu ambiente pro resto da sua vida e ficar tranquilo. É isso que eu faço e é isso que eu recomendo. Nunca tive problema nenhum com deploy. Nenhum. Eu controlo o meu ambiente inteiro, eu controlo os meus runners, eu controlo o meu deploy, eu controlo pra onde ele vai. E se der problema de disponibilidade, a culpa é minha mesmo — e eu mesmo resolvo. É muito mais fácil quando a coisa está na sua mão.
Só que pra isso você precisa entender. Não pode ser um Git cru em produção, subido no escuro, baseado em "vai que dá certo". Você vai bater muita cabeça, pode perder cliente e vai passar muita raiva. Se você passar raiva uns quatro anos seguidos, você fica bom nisso — eu passei. Ou você passa raiva, ou você aprende com quem já passou.
Então eu avisei: terceiro vídeo do GitHub. Sai fora desse negócio pra coisa séria em produção. Um grande abraço — e tem live toda segunda-feira, meio-dia.
Sobre a imersão de infraestrutura. GitLab de produção pancadão, redundante, com backup, rollback, runners distribuídos e o pipeline real de uma empresa que roda de verdade — é isso que eu abro em três dias presenciais em São Paulo. Data, valor e condição finais saem na página, não aqui. Lista de espera em Imersão de Infraestrutura; as quatro estão em todas as imersões. E na imersão do dia 15 de agosto a galera me disse a mesma coisa: "despejou conhecimento na minha cabeça, mas o passo a passo demora demais sozinho". É por isso que a gente vai abrir uma comunidade passo a passo, com suporte — e um dos primeiros módulos é exatamente instalar, monitorar, dar redundância e proteger o seu GitLab. Proteger de atacante externo, da sua própria equipe e de você mesmo.
TODA SEGUNDA · MEIO-DIA · AO VIVO
Discorda? Concorda? Tem um caso parecido? Aqui não tem caixa de comentário de propósito: segunda-feira, ao meio-dia, eu faço live no canal e a gente conversa sobre isso ao vivo — sem corte, como sempre.
Baseado no vídeo do canal @josimarjmv publicado em 21/08/2026 (15min22), com transcrição própria das legendas do próprio vídeo. Os números do incidente foram conferidos em 08/09/2026 na fonte primária: comunicado oficial do GitHub sobre o incidente de 17 de agosto — 7h47 de indisponibilidade, falha de escala num componente crítico do data center Central US, cascata até a autenticação, tráfego de 7–9 mil para 70–100 mil requisições por segundo por retentativa, commits mensais de 1,4 bilhão (abril/2026) para 2,9 bilhões (agosto/2026) e compromisso público com limites e orçamentos de retentativa. A compra da Anysphere (Cursor) pela SpaceX por US$ 60 bilhões, concluída em 14/08/2026, foi conferida na cobertura de CNBC e TechCrunch. Documentação do GitLab citada: server hooks e autenticação de dois fatores. Decisões de arquitetura, tempo de operação e opinião são da minha experiência tocando a infraestrutura da JMV Technology.