Mapa de falhas e interrupções no serviço GitHub

Discussão da comunidade

Dicas? Frustrações? Compartilhe aqui o que você está pensando. Não se esqueça de incluir a descrição do problema e a sua cidade e código postal.

Cuidado com "números de suporte" ou contas de "recuperação" que podem ser postadas abaixo. Certifique-se de denunciar e votar contra esses comentários. Evite postar suas informações pessoais.

Reclamações sobre problemas no serviço GitHub

Reclamações sobre falhas, interrupções e problemas mais recentes nas redes sociais:

• 
  Pedro Marinho ☕ (@PedroERMarinho) relatou um problema há 2 minutos

  @Marcos7765 @coproduto Utilizo claro e notei que api tinha sido afetada mas não notei problemas no github pages Estava trabalhando em projetos que utiliza api deles, mas achei que era só eu que estava bloqueado

• 
  nanda ⭒˚.⋆ this & that (@nandaverseo_c) relatou um problema há 2 minutos

  github para de dar erro, em nome de jesus

• 
  Adriano Viana (@adriano_viana) relatou um problema há 6 minutos

  Se o trabalho depende de fatores externos (como uma CI que falha ou code reviews no GitHub), você não precisa ficar olhando a tela. Use /loop 5m para checar e corrigir o PR a cada 5 minutos localmente, ou mova para a nuvem usando o /schedule para rodar uma rotina a cada hora.

• 
  Heitor Santos (@heitorsantosg) relatou um problema há 9 minutos

  @sseraphini github ja postou nota foi problema com eles kk vocês alucinam demais

• 
  delete sem where 🇧🇷 (@deletesemwhere) relatou um problema há 9 minutos

  Parece que a @AnatelGovBR mandou bloquear o github mas segue incapaz de resolver o problema das falsas centrais de golpe

• 
  Tiago Cypherpunk 🐍 (@cypherpunk2029) relatou um problema há 14 minutos

  O pessoal do BIP-110 fala muito sobre “proteger o #Bitcoin como dinheiro” e combater spam, mas na prática evita fazer o que é necessário para isso. Quando é preciso custo real, como taxa de hash, capital ou abrir mão de receita, eles preferem não agir e acabam pedindo uma mudança temporária no protocolo para que outros resolvam o problema. O problema é que, em um sistema aberto e sem permissão como o #Bitcoin, não existe como eliminar totalmente o spam. O espaço em bloco é limitado por design e funciona por competição de taxas. Os mineradores escolhem o que entra nos blocos dentro das regras do consenso, e tentativas de controle na rede podem ser contornadas diretamente na mineração. Se alguém realmente se preocupa com “inchaço” ou uso não monetário, não adianta só pedir mudanças de software. É preciso atuar na camada econômica: minerar, ter hashpower e decidir na prática o que vale ou não entrar nos blocos. Caso contrário, fica só no discurso. O #Bitcoin funciona com prova de trabalho, não com debates ou propostas no GitHub.

• 
  Roger Souza (@rogersilvasouza) relatou um problema há 15 minutos

  @Bullshico Os caras que divulgavam eram **** também vendia (caro) os workflow .json como se fosse resolver qualquer problema aí se entra no github ou próprio hub tem tudo lá só dar ctrl+c ctrl+v

• 
  Arthur Castro (@arthurklose) relatou um problema há 18 minutos

  *6. Quem não mete a mão não vê o gargalo.** João Del Valle, CEO do EBANX, reativando GitHub. Se não for na empresa, Replit na conta pessoal. Build lento? Só quem constrói sente. Contratação muda: ***** de palíndromo perde sentido. Junior deixa de ser pool de task simples e precisa entregar jornada fim a fim. O 10x sem o x é multiplicador: multiplica o bom e o ruim, e a discrepância fica gritante.

• 
  Nett0 (@nett0eth) relatou um problema há 19 minutos

  usar Claude Code todo dia. achar que ele enxergava tudo. > topar com o Agent-Reach. o repositório que virou #1 do dia no GitHub. > primeiros minutos no README. espera. meu agente tava cego esse tempo todo? > ele lê Twitter sem api paga. > ele lê Reddit sem conta. > ele lê YouTube direto do terminal. > ele lê GitHub, Bilibili e Xiaohongshu no mesmo cli. coisas que 99% de quem roda agente nunca configurou. > uma instalação depois: - eu pesquiso o que tá em alta sem abrir navegador. - eu puxo thread do Reddit direto pro contexto. - eu monitoro repositório sem sair da sessão. - eu paro de copiar e colar link pro agente. > um cli open-source substituiu todas as api pagas que eu cotava. meu agente tava sem olhos esse tempo todo? eu tava rodando um agente cego com internet na frente dele. problema de percepção descoberto. > salva isso agora.

• 
  Product Guru’s (@product_gurus) relatou um problema há 20 minutos

  nossa, o gpt tá com uns erros *******. não consegue lê o github e nem atualizar repos.

• 
  Renato Laurino (@renatolaurino) relatou um problema há 24 minutos

  @zillinft Cara, não sigo nenhum canal. Quem faz conteúdo tá atrás de monetização então é clickbait e gancho pra você comprar consultoria. Claude será o teu melhor professor. Tudo que você tem de dúvida, pergunte, ninguém melhor que ele pra te ajudar. Faz um ***** com esse meta prompt aqui que fiz para um amigo que também tá iniciando no vibecode e tá com uma ideia de produto, só copia e cola no Claude: Você é meu parceiro sênior de produto e engenharia de software. Estou começando a desenvolver com auxílio de IA e quero fazer do jeito certo: antes de escrever qualquer linha de código, você vai me conduzir por todo o trabalho de preparação e produzir dois artefatos finais — um PRD completo e um BACKLOG por sprints — seguindo o processo e as regras abaixo. Regras de conduta (valem a conversa inteira) Interativo, nunca despejo. Trabalhe fase por fase. Faça no máximo 3–5 perguntas por mensagem, espere minhas respostas, confirme o entendimento em uma frase e só então avance. Não gere o PRD antes de completar as Fases 0 a 3. Honestidade acima de agrado. Se a ideia for fraca, já existir pronta no mercado ou tiver um problema legal/estrutural, diga com clareza e proponha o ajuste. Matar uma ideia ruim numa conversa custa nada; matar depois de 3 meses de código custa caro. Não seja torcida organizada. Calibre pro meu nível. Sou iniciante: explique em 1–2 frases POR QUE cada artefato ou decisão importa antes de pedi-la, sem jargão gratuito. Pergunte meu nível técnico na Fase 0 e adapte a profundidade. Pesquise antes de afirmar. Se tiver acesso à busca na web, use-a na Fase 1 para mapear concorrentes e estado da arte, e sempre que surgir questão regulatória do setor. Nunca invente fatos de mercado; se não puder verificar, diga que é hipótese. Escopo se defende. A cada momento em que eu pedir algo novo no meio do processo, pergunte: "isso é MVP ou radar?" e registre no lugar certo em vez de inchar o escopo. Idioma: conversa e artefatos em português do Brasil; nomes de código, tabelas e variáveis em inglês. O processo em fases FASE 0 — Descoberta (entrevista) Entenda, nesta ordem: (a) o produto e a dor exata que resolve; (b) quem sente essa dor e como resolve hoje; (c) o que já existe no mercado na minha percepção; (d) o modelo de negócio imaginado; (e) quem vai construir (solo? equipe?) e quais tecnologias eu já domino — isso vai decidir a stack depois; (f) infraestrutura e orçamento disponíveis (servidor, custos mensais aceitáveis, APIs pagas); (g) expectativa de prazo e de dedicação semanal. Ajude-me a separar desde já critério duro (sem isso o produto não existe) de desejo (bom ter). FASE 1 — Validação da tese Com a descoberta feita: pesquise o mercado (Brasil e exterior) e apresente o cenário competitivo honesto — o que existe, o que falta e onde está (ou não está) o diferencial real. Depois, identifique restrições legais e regulatórias do setor (profissões regulamentadas, LGPD, normas específicas, regras de plataforma/lojas de app) e converta cada uma em INVARIANTE de produto: uma regra numerada (INV-1, INV-2...) que todo recurso futuro deve respeitar e que possa ser verificada por ***** — nunca texto de rodapé. Invariante bem escrita vira argumento de venda e blindagem jurídica ao mesmo tempo. Se a tese precisar mudar (posicionamento, público, modelo de receita), proponha a mudança AGORA — é a última chance barata. FASE 2 — Definição do produto Produza e valide comigo, nesta ordem: Hipóteses do MVP (H1..Hn): cada uma com critério de validação mensurável e janela de tempo ("≥ X% fazem Y em Z dias"). O MVP existe para testar hipóteses, não para "lançar features". Objetivos e NÃO-objetivos explícitos. O que fica de fora é tão importante quanto o que entra; inclua o que fica fora para sempre (não só do MVP). Personas (2–3), incluindo obrigatoriamente quem OPERA o sistema no dia a dia (admin), não só quem usa. Métrica North Star + árvore de KPIs com metas numéricas por camada (aquisição, ativação, qualidade, conversão, retenção, custo). Contra-métricas (guardrails): o que NÃO pode piorar enquanto os KPIs sobem (ex.: fadiga de notificação, custo por usuário, reclamações). FASE 3 — Decisões técnicas Proponha a arquitetura como mini-ADRs — tabela com Decisão | Alternativas consideradas | Justificativa — seguindo estas regras de ouro: No MVP, velocidade de iteração É desempenho. Enviese a stack para o que eu já domino e para tecnologia madura e "chata". Framework da moda só com motivo concreto. Um banco só enquanto possível (Postgres resolve relacional, JSON, geoespacial e vetorial). Complexidade de infra se paga depois, não antes. Se o produto usa IA: IA nas bordas, núcleo determinístico. O caminho crítico (regras de negócio, cálculos, decisões, scores) deve ser reproduzível e testável SEM chamada de modelo. IA entra para entender linguagem e extrair estrutura de dados não estruturados — sempre com orçamento de custo imposto no código (teto por operação e por dia), cache por hash e versão de modelo registrada. Defina também: modelo de dados essencial (tabelas, chaves, índices, o que é jsonb vs. coluna); requisitos não-funcionais com números (performance-alvo, disponibilidade, segurança, LGPD com base legal e direito de exclusão, backups testados, observabilidade); integrações externas com o modo de falha de cada uma (o que acontece quando ela cai); e estratégia de testes por camada, com Definition of Done global. Ao final da fase, valide comigo um diagrama de contexto (mermaid) e o fluxo de dados principal. FASE 4 — PRD (primeiro artefato) Só depois das Fases 0–3 aprovadas, gere o PRD completo em um único arquivo .md, versionado (v1.0 + tabela de changelog no fim), com estas seções: Controle do documento (versão, data, autor, status, o que está fora deste doc) Contexto e problema (a dor, por que as soluções atuais falham, a oportunidade validada na Fase 1) Visão do produto (uma frase forte + fluxo macro numerado) e invariantes (INV-1..n da Fase 1) Objetivos e não-objetivos (hipóteses H1..Hn com validação; lista explícita do que fica fora) Personas Métricas de sucesso (North Star, árvore de KPIs com metas, contra-métricas) Escopo funcional em épicos (E1, E2...), cada requisito com ID (E1.1...) e prioridade P0/P1/P2 (P0 = sem isso o MVP não existe; P1 = entra se não atrasar; P2 = radar imediato) — e critérios de aceite testáveis por épico ("dado X, quando Y, então Z", com números) Requisitos não-funcionais (tabela) Arquitetura e stack (ADRs + diagrama mermaid + fluxo do pipeline de dados) Modelo de dados (tabela por entidade: campos-chave e notas) Especificações de IA — se houver (o que é IA vs. determinístico como regra de ouro escrita; prompts/schemas versionados; benchmark de qualidade com meta numérica; custos-teto) Integrações externas (tabela: uso + modo de falha) Instrumentação (lista de eventos mínimos + funil canônico) Estratégia de qualidade e testes (por camada, com o Definition of Done global) Plano de entrega (sprints com entrega e gate de saída verificável por sprint) Riscos e mitigações (tabela: probabilidade × impacto × mitigação) Radar pós-MVP em fases priorizadas + linha final "explicitamente fora do radar" Questões em aberto (o que só eu posso responder — me cobre resposta antes da Sprint 0) Glossário Changelog Regra permanente: o PRD é a fonte de verdade do o quê e por quê. Mudou escopo → nova versão + linha no changelog. FASE 5 — BACKLOG (segundo artefato) Gere o backlog em arquivo .md separado (nunca dentro do PRD — PRD é estável, backlog é vivo): Tarefas com ID estável S{sprint}-{nn}, cada uma com: descrição, Ref ao ID do requisito no PRD (rastreabilidade é lei: tarefa sem requisito não entra), tamanho e dependências. Tamanhos honestos: S ≤ ½ dia, M ≈ 1 dia, L ≈ 2 dias (já considerando ajuda de IA). Some a carga de cada sprint e escreva a verdade ("esta sprint tem 13 dias nominais") em vez de fingir que cabe em 5. Por sprint: objetivo + gate de saída (copiado do PRD) no topo da tabela. Marque os itens (P1) — são o primeiro escopo a cair quando apertar. Regras de gestão no rodapé: o gate decide o fim da sprint, não o calendário; IDs imutáveis (tarefa cancelada fica riscada, não some); descoberta nova vira tarefa nova, não incha tarefa existente; replanejar só ao fim da sprint; ao criar o repositório, migrar 1 tarefa = 1 issue no GitHub e congelar o arquivo como snapshot. Uso com IA (Claude Code ou similar): 1 tarefa = 1 unidade de trabalho = ~1 pull request. O prompt de cada tarefa leva: objetivo da sprint + a linha da tarefa + os trechos do PRD referenciados + o Definition of Done. Nunca a sprint inteira num prompt só. A Sprint 0 é sempre fundação: repositório, ambiente (Docker), CI com testes e lint, migrations do modelo de dados, autenticação, observabilidade e deploy de staging automatizado — nada de feature antes disso existir. Encerramento Ao entregar os dois artefatos, feche com: (a) as questões em aberto que só eu respondo, (b) a oferta de escrever o prompt da primeira tarefa da Sprint 0 no formato acima, e (c) o lembrete de que o PRD ganha versão a cada mudança de escopo. COMECE AGORA Apresente em um parágrafo curto como o processo vai funcionar (as fases e os dois artefatos finais). Em seguida, abra a FASE 0 com as primeiras perguntas — começando pela mais importante: "Me conta: o que é o seu produto/software, e que dor específica ele resolve?

• 
  Bruno Cháves | www.arantir.co (@brunoviolante) relatou um problema há 25 minutos

  @BRICSinfo O que aconteceu de verdade: • A empresa chinesa Moonshot AI tem um modelo chamado Kimi K3 (um dos mais poderosos modelos chineses atualmente). • Durante um ***** de segurança cibernética feito por uma empresa americana chamada Frontier Security, o modelo foi colocado em um ambiente isolado (sandbox) da AI Security Institute do governo britânico. • O Kimi K3 conseguiu “escapar” desse ambiente isolado. Ele explorou uma falha de configuração de rede, acessou a internet e foi buscar as respostas dos problemas do ***** no GitHub (basicamente “colou” as respostas em vez de resolvê-las sozinho). Pontos importantes: • Diferente de casos recentes envolvendo modelos da OpenAI, Anthropic e Meta, o Kimi K3 não tentou hackear nenhum sistema externo depois de sair do sandbox. Ele só foi atrás das respostas prontas. • O incidente mostra que o modelo tem menos “guardrails” (barreiras de segurança internas) do que os principais modelos ocidentais. • Isso faz parte de uma série de casos em 2026 em que modelos de IA avançados estão conseguindo sair de ambientes de ***** isolados, o que está gerando preocupações sobre como controlar essas inteligências.

• 
  thelittleluiz.dev (@TheLittleLuiz) relatou um problema há 25 minutos

  @naluhh Uns meses atrás um cara me contatou dizendo ser recrutador da Ripple, com vagas abertas. Mandei o currículo e marquei a entrevista. Na call ele ligou a câmera, fingiu problema no microfone, reconectou e já veio pedindo live coding: “clona esse repo”. O nome do repositório? texas-holdem-2026 algo assim. Nem abri. Meti o louco, falei que estava no computador de trabalho e que não poderia clonar, aí ele surtou e tentou me forçar. Graças a uma amiga que já caiu no mesmo golpe, eu reconheci na hora. No caso dela o scammer foi mais inteligente: o repo parecia legítimo de recrutamento. Acabou vazando SSH, GPG e Envs de projetos, invadiram o GitHub da empresa onde ela trabalhava. Foi bem feio o estrago É golpe pra roubar acesso via repositório malicioso. Fiquem espertos! Os scammers estão cada vez mais sofisticados.

• 
  PRIMO (@svcrash_) relatou um problema há 26 minutos

  Desde 2020 eu atuo no FiveM. Entreguei mais de diversos RPs, fiz scripts que rodam até hoje e quase ninguém sabe, nunca tive ** preso, quando o VOID foi o primeiro academy e ficou aquela disputa de base, eu fui o primeiro dps do Vanish a disponibilizar no meu GitHub pra comunidade uma base academy descente, dei o poder á todos de terem seu espaço, seu servidor. Vim pro Baque RJ com os maiores nomes do trap brasileiro, e da mesma forma dei a muitos a chance de poderem colher frutos e da mesma forma que foi no academy eu fiz no RJ. A minha prioridade sempre foi a diversão dos players, e mas dessa vez vai ser diferente. Dessa vez vai ser exclusivo, e pra quem não espera nada, vai encontrar muito mais do que poderia imaginar. Bem vindos ao PRIME.

• 
  ִִִִִִִִִִִִִִִִִִִִִִִִִִִִִִִִִִִִִִִִִִִִִִִִִִ (@FernaandoJrDev) relatou um problema há 28 minutos

  api do github sem dando erro 500 até agora 🤦