Falha em Issues e Webhooks – resolvida

 (githubstatus.com)
1 pontos por GN⁺ 2 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • O GitHub investigou a degradação de desempenho em Issues e Webhooks e depois mudou o status do incidente para resolvido em 4 de maio de 2026, às 16:40 UTC
  • Este incidente afetou Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages e Codespaces
  • Às 15:45 UTC começou a investigação sobre a degradação de desempenho em Issues e Webhooks, e às 15:48 UTC ela foi ampliada para investigar aumento de latência e timeouts em vários serviços do GitHub
  • A partir das 16:25 UTC, Git Operations, Actions, Packages, Pages, Pull Requests, Issues, Codespaces e Webhooks foram sendo normalizados ou mitigados em sequência
  • O GitHub informou que a latência em toda a plataforma voltou ao normal e que continuará trabalhando na prevenção de recorrências e na análise da causa raiz, que será compartilhada assim que estiver pronta

Visão geral do incidente

  • O GitHub anunciou que o incidente foi resolvido após investigar relatos de degradação de desempenho em Issues e Webhooks
  • O incidente afetou Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages e Codespaces
  • O GitHub agradeceu aos usuários pela paciência durante o tratamento do problema e informou que uma análise detalhada da causa raiz será compartilhada assim que estiver pronta

Andamento

  • Início da investigação

    • Em 4 de maio de 2026, às 15:45 UTC, foi anunciado que estavam investigando relatos de degradação de desempenho em Issues e Webhooks
    • Às 15:48 UTC, o aviso foi ampliado para informar que estavam investigando aumento de latência e timeouts em vários serviços do GitHub

  • Ampliação dos serviços afetados

    • Às 15:48 UTC, foi informado que Git Operations estava sofrendo degradação de desempenho
    • Às 15:50 UTC, foi informado que Packages estava sofrendo degradação de desempenho
    • Às 15:51 UTC, foi informado que Actions estava sofrendo degradação de desempenho
    • Às 15:51 UTC, foi informado que Pull Requests estava sofrendo redução de disponibilidade
    • Às 15:56 UTC, foi informado que Pull Requests estava sofrendo degradação de desempenho
    • Às 16:05 UTC, foi informado que Codespaces estava sofrendo degradação de desempenho
    • Às 16:06 UTC, foi informado que Pages estava sofrendo degradação de desempenho

  • Normalização e mitigação

    • Às 16:25 UTC, foi informado que Git Operations estava operando normalmente
    • Às 16:28 UTC, foi informado que Actions e Packages estavam operando normalmente
    • Às 16:29 UTC, foi informado que Pages estava operando normalmente
    • Às 16:29 UTC, foi informado que a latência em toda a plataforma havia voltado ao normal e que a investigação da causa raiz e a prevenção de recorrências continuavam em andamento
    • Às 16:32 UTC, foi informado que Pull Requests estava operando normalmente
    • Às 16:34 UTC, foi informado que a degradação de desempenho que afetava Issues havia sido mitigada e que o serviço seguia em monitoramento para confirmar a estabilidade
    • Às 16:35 UTC, foi informado que a degradação de desempenho que afetava Codespaces havia sido mitigada e que o serviço seguia em monitoramento para confirmar a estabilidade
    • Às 16:35 UTC, foi informado que Webhooks estava operando normalmente

  • Resolução

    • Às 16:36 UTC, foi informado que a degradação de desempenho havia sido mitigada e que o serviço seguia em monitoramento para confirmar a estabilidade
    • Às 16:40 UTC, o incidente passou para o status resolvido
    • A análise detalhada da causa raiz será compartilhada assim que estiver disponível

Leituras relacionadas

1 comentários

 
GN⁺ 2 시간 전
Comentários do Hacker News

  • O GitHub divulgou números impressionantes de aumento de uso, dizendo que isso se deve ao crescimento da codificação com agentes, mas em algum momento vai ter que mudar o rate limiting, reduzir o uso da camada gratuita ou encontrar outra forma de diminuir a carga
    Parece óbvio que a infraestrutura não está conseguindo acompanhar esse crescimento, e é improvável que o GitHub vá simplesmente absorver esse aumento de custos. Fico curioso para ver o que vai acontecer com o GitHub daqui para frente

    • Em 3 de abril, a COO do GitHub já havia dito que a atividade da plataforma estava disparando
      Em 2025, houve 1 bilhão de commits, mas agora já são 275 milhões por semana, o que, mesmo com crescimento linear, dá um ritmo de 14 bilhões neste ano. O GitHub Actions também passou de 500 milhões de minutos por semana em 2023 para 1 bilhão por semana em 2025, e nesta semana já chegou a 2,1 bilhões de minutos
      Disseram que estão forçando muito a expansão de CPU, o aumento de escala dos serviços e o reforço das funcionalidades centrais do GitHub
      https://x.com/kdaigle/status/2040164759836778878
      Também há um post recente no blog sobre disponibilidade: https://github.blog/news-insights/company-news/an-update-on-...
      Os problemas de escalabilidade que os engenheiros do GitHub estão enfrentando parecem realmente bem complicados
    • Observando ao longo de décadas, há sistemas que tornam cada operação barata e sistemas que escalam horizontalmente com muito esforço; com frequência, os primeiros vencem os segundos com folga
      Por exemplo, o GitHub parece ter implementado a página /pulls do repositório como uma consulta de busca, e a caixa de pesquisa já preenchida era uma pista; isso quase ficou confirmado quando os pull requests deixaram de carregar durante uma falha recente no backend de busca. Mas isso também poderia ter sido implementado com uma chamada de API comum para buscar apenas os pull requests abertos, e essa API existe e não falhou
      Se o GitHub se concentrar em encontrar e otimizar os 95% principais tipos de operação, como carregamento de páginas e as chamadas de API associadas, talvez só com simplificação já consiga reduzir a carga do backend em mais de 5 vezes
      O visualizador de diff também parece ter bastante margem para melhorar. Boa parte da ineficiência terrível provavelmente está no frontend, que não carrega diretamente o backend, mas as funções normais da linha de comando git são muito rápidas
    • Parece que estamos chegando perto do ponto sem retorno. A menos que separem a infraestrutura gratuita da paga, não sei se vão conseguir sair do buraco que cavaram só com escalabilidade horizontal
      Assim como um produto precisa ser 10x melhor para fazer alguém trocar, quando o produto atual fica 10x pior o concorrente ganha 10x de vantagem de graça, mesmo sem fazer nada
    • Uma semana depois de o GitHub publicar isso no blog, e um dia depois de executivos do GitHub repetirem isso nos comentários do HN, virou senso comum quase instantaneamente que a queda de confiabilidade desde 2019 não se devia à integração com a Microsoft em 2019, mas a alguma coisa que só apareceu em 2023
      Relações públicas funcionam. A conclusão virou que o GitHub está falhando porque faz sucesso demais
    • Sou fortemente a favor de realocar toda a capacidade dos servidores do LinkedIn para o GitHub

  • Segundo https://mrshu.github.io/github-statuses, a disponibilidade dos últimos 90 dias do GitHub é de 84,92%
    Não faço ideia de como isso pode ser considerado minimamente aceitável

    • Esse site parece superestimar o tempo de indisponibilidade. Mesmo filtrando só as falhas major e critical dignas de primeira página no HN, continua ruim, mas não tão ruim quanto 84,92%
      https://isgithubcooked.com/?severities=major.critical
    • Não é aceitável. Muitas coisas inaceitáveis acontecem hoje em dia, e ainda assim parece que todo mundo aceita como se não fosse grande coisa
    • Nem two eights eles estão conseguindo entregar, quanto mais three nines

  • O desempenho já chegou a um nível difícil de aceitar. Não há uma semana em que o trabalho não seja interrompido por causa do GitHub

    • Os agentes de IA de fato mudaram as características de escalabilidade da internet inteira
      Antes, o GitHub podia presumir que um número limitado de pessoas usaria a plataforma de forma humana e com padrões observáveis, e provavelmente escalava e otimizava gargalos de UI/UX com base nisso
      Mas agora todo mundo tem um bot rodando 24 horas por dia, às vezes vários, e isso está sobrecarregando muitos serviços. Especialmente serviços que hoje são centrados em agentes, como o GitHub
    • Já estava em nível inaceitável há meses, e agora está perto da fase em que é preciso procurar alternativas ativamente
    • Já estamos num ponto em que dá para comemorar se passar um dia inteiro sem incidente, quanto mais uma semana
      Toda segunda-feira de manhã, no horário do Pacífico, eu já nem sei mais quantas vezes isso se repetiu
    • Na Europa está bem melhor. Eu já tinha terminado meu trabalho algumas horas antes desta falha começar, e não lembro de grandes incidentes nos últimos meses a ponto de parar meu trabalho
      Houve uma vez recente em que fui afetado à noite ao mexer em um projeto pessoal
    • Acho que o nível inaceitável já ficou muito para trás

  • Agora os posts de GitHub fora do ar estão competindo na primeira página do HN, toda semana, com mais um novo post exagerado sobre LLM
    Estou pensando em migrar todos os meus projetos pessoais para o Codeberg. A estabilidade do GitHub é um motivo, mas também gosto da ideia de uma alternativa que não esteja rigidamente presa a uma big tech

    • O spam dizendo que o Claude Code é praticamente magia era o pior de todos, mas parece que por um tempo perdeu espaço para os posts sobre o status do GitHub. Talvez agora estejamos em uma fase mais quieta da publicidade do Claude
    • E, ainda assim, você ainda não migrou; esse é o problema de uma plataforma dominante. Um pouco de inconveniência e inércia já bastam para fazer com que ninguém vá embora
      Mesmo sem abuso monopolista, e aqui estamos falando da Microsoft

  • Engraçado que quase tudo parece degradado, exceto o Copilot. A piada se escreve sozinha

    • Comparada às funcionalidades que estão degradadas agora, toda a funcionalidade do Copilot representa só uma utilidade parcial
    • O Copilot provavelmente é totalmente independente do lado de repositórios de código do GitHub e deve rodar em uma infraestrutura completamente diferente, sem forte dependência do monólito em Rails

  • Está ficando estranho e um pouco triste perceber que estou começando a desenvolver um sexto sentido para detectar quando o GitHub vai ter incidente
    Há cerca de uma hora, cliquei em “Resolve Conversation” em um pull request e falhou algumas vezes; a mensagem de erro apareceu fora da tela, na parte de baixo da página, então eu não vi de início. Tive que recarregar a página várias vezes para que o servidor refletisse a nova ação
    Comentei com um colega que parecia que o GitHub tinha algum problema em outro serviço e que isso tinha se espalhado para os comentários de PR, e que talvez evoluísse para uma falha maior

    • Acabei de ver exatamente os mesmos sinais em comentários de revisão de PR. Verifiquei a página de status, estava verde, e imaginei que isso não duraria muito; e acertei

  • Precisam reduzir a camada gratuita
    Fiz 4.000 commits nos últimos 2,5 meses, e isso só no main. Também subo diariamente um monte de artefatos para testes de regressão
    O custo foi de 0 dólar

    • Sinceramente, odeio a camada gratuita desses produtos SaaS
      Quando o Google, por um curto período, ofereceu um serviço Git pago por uso no GCP, eu usava aquilo. Porque eu queria ter algo meu. Mas todo mundo usava o GitHub “gratuito” e, como muitos outros serviços do Google, esse também parece ter sido encerrado
      Então hoje eu uso o GitHub de graça, mas preferiria pagar por repositório e por uso a um grande provedor de nuvem
    • Se fizerem isso, os projetos open source que ainda não saíram vão migrar
    • Olhando só para o lado do repositório, isso deve equivaler a uns 2 minutos de uso de CPU
    • O GitHub deveria cobrar um imposto sobre código lixo. Coautor com Claude? Paga. Muitos travessões nos comentários? Paga. Muito código escrito em pouco tempo? Paga

  • Está chegando a um nível realmente ridículo. A página de status às vezes é ignorada quando até o Copilot aparece como “indisponível”, mas vale notar que a disponibilidade de pull requests está em 95,5%, abaixo até dos 96,4% do Copilot
    Não sei como esperam que eu comente “LGTM” se eu nem consigo acessar o PR

  • Pelo menos as pessoas estão aprendendo a usar o comando git remote