▲

GitHub에 현재 장애 발생 중

 (githubstatus.com)
1P by GN⁺ 5시간전 | ★ favorite | 댓글 1개
  • Pull Requests 성능 저하가 진행 중이며, /pulls와 /repo/pulls 페이지에서 인덱싱된 pull request 전체가 보이지 않을 수 있음
  • 현재 Elasticsearch 클러스터에 모든 인덱싱 문서가 들어 있지 않지만, pull request 데이터 자체는 유실되지 않았고 갱신 시 다시 인덱싱됨
  • 남아 있는 인덱스를 재인덱싱하는 작업과 전체 결과 복구를 위한 full reindex 가속 작업이 함께 진행 중이며, 정확성과 추가 영향 회피를 우선함
  • 컴포넌트 상태 표에서는 Pull Requests만 저하 상태로 표시되고, Git Operations·Webhooks·API Requests·Issues·Actions·Packages·Pages·Copilot·Codespaces·Copilot AI Model Providers는 Operational 상태임
  • 최근 이력에는 검색 저하, Actions 작업 실패, Copilot agent 세션 시작 실패, merge queue 회귀, Projects 지연, Codespaces 연결 실패 같은 여러 장애 사례와 복구 조치가 함께 공개돼 있음

현재 장애 상태

  • Pull Requests에서 성능 저하가 진행 중이며, Incomplete pull request results in repositories 항목으로 공개돼 있음
  • /pulls와 /repo/pulls 페이지에서 인덱싱된 pull request 전체가 보이지 않을 수 있음
    • Elasticsearch 클러스터에 현재 모든 인덱싱 문서가 들어 있지 않음
    • pull request 데이터 자체는 유실되지 않았음
    • pull request가 갱신되면 다시 인덱싱됨
    • 전체 결과 복구를 위해 full reindex 가속 작업도 함께 진행 중임
  • 남아 있는 Elasticsearch 인덱스를 재인덱싱 중이며, 정확성을 우선하고 추가 영향은 피하는 방향으로 처리 중임
    • 데이터를 안전하게 backfill하는 신중한 접근을 유지 중임

컴포넌트 상태

  • 현재 상태 표에서 Pull Requests만 Degraded Performance로 표시됨
  • 나머지 주요 컴포넌트는 Operational 상태임
    • Git Operations
    • Webhooks
    • API Requests
    • Issues
    • Actions
    • Packages
    • Pages
    • Copilot
    • Codespaces
    • Copilot AI Model Providers
  • 지난 90일 가동률도 함께 제공됨
    • Pull Requests 99.58% uptime
    • API Requests 99.95% uptime
    • Packages 99.97% uptime
    • Copilot AI Model Providers 100.0% uptime

지역별 상태 페이지와 구독 경로

최근 장애 이력

  • Apr 28 일부 GitHub 서비스 장애

    • Disruption with some GitHub services 항목은 해결됨
    • Actions hosted Ubuntu 작업에서 시작 지연과 실패가 발생함
      • ubuntu-latest와 ubuntu-24.04 실행 일부가 지연되거나 실패함
      • 한때 약 5% 작업이 영향받았고, 이후 2% 미만, 다시 1% 미만으로 줄어듦
    • Actions 실행을 막던 문제를 완화했고, 최종적으로 정상 동작으로 복구됨

  • Apr 27 GitHub 검색 저하

    • GitHub search is degraded 항목은 해결됨
    • Elasticsearch 연결 문제와 추가 부하로 검색 실패와 여러 하위 서비스 문제가 함께 발생함
      • Issues, Pull Requests, Packages, Actions가 영향받음
      • workflow run 실패, projects 로딩 실패, search timeout이 발생함
    • 추가 부하 원인을 차단한 뒤 복구 조짐이 나타났고, 이후 안정화 모니터링으로 전환됨

  • Apr 27 Copilot Cloud Agent Codex 세션 장애

    • Disruption with some GitHub services 항목은 해결됨
    • Copilot Cloud Agent에서 Codex agent 세션 시작 실패가 발생함
      • 이슈 할당과 @copilot 코멘트 멘션 등 모든 진입점에서 시작되지 않음
      • 전체 Copilot Cloud Agent 작업의 0.5%, 약 2,000개 실패 작업이 영향받음
      • Copilot의 다른 agent 세션은 영향받지 않음
    • Codex agent 세션의 model resolution mismatch로 런타임에 호환되지 않는 모델이 선택된 것이 원인임
    • Codex agent 세션에 안정적인 기본 모델을 선택하도록 완화 조치를 배포함

근본 원인 공개가 포함된 주요 사례

  • Pull Requests merge queue 회귀

    • Incident with Pull Requests는 해결됨
    • merge queue에서 squash merge 방식을 사용할 때, merge group에 PR이 둘 이상이면 잘못된 merge commit이 생성됨
      • 이후 병합에서 이전 PR 변경분과 이전 commit 변경분이 되돌려질 수 있었음
      • 영향 구간 동안 2,092개 pull request가 영향받음
    • merge queue 밖에서 병합한 PR과 merge 또는 rebase 방식을 쓴 일부 그룹은 영향받지 않음
    • merge base 계산을 조정하는 새 코드 경로가 완전하지 않은 feature flag gating 상태로 적용된 것이 원인임
    • 코드 변경을 되돌리고 전체 환경에 강제 배포했으며, 영향 저장소 관리자에게 복구 절차를 별도로 전달함
    • 이후 다중 PR squash 그룹까지 포함하는 merge correctness 테스트 범위를 확장 중임

  • Claude·Codex agent 웹 시작 불가

    • Disruption with users unable to start Claude and Codex agent task from the web는 해결됨
    • github.com에서 Claude 또는 Codex agent로 새 agent task를 시작할 수 없었음
    • Copilot mission control의 task creation request 라우팅 코드 변경이 원인임
    • 진행 중인 agent task와 다른 Copilot agent 기능은 영향받지 않음
    • 문제를 일으킨 변경을 되돌려 복구했고, task 생성 경로에 추가 모니터링과 통합 테스트를 넣고 있음

  • Copilot @멘션 처리 누락

    • Disruption with some GitHub services는 해결됨
    • pull request 코멘트의 @copilot 멘션이 Copilot coding agent 실행으로 이어지지 않음
      • 전체 pull request·issue 코멘트 중 약 23,000회 호출, 전체의 0.5% 가 처리되지 않음
      • 코멘트 생성·조회·답글 자체는 영향받지 않음
    • downstream consumer로 이벤트를 발행하지 못하게 한 serialization error가 원인임
    • 이벤트 발행 복구용 수정 배포 후 정상 처리로 돌아왔고, 관련 이벤트 스키마 점검과 모니터링 개선을 진행 중임

  • Copilot Chat 및 Cloud Agent 중단

    • Disruption with Copilot chat and Copilot Coding Agent는 해결됨
    • github.com의 Copilot Chat과 Copilot Cloud Agent에서 오류가 발생했고, 그 시간 동안 사용할 수 없었음
    • preview 상태의 Copilot Memory도 agent 세션에서 사용할 수 없었음
    • 인프라 설정 변경으로 데이터베이스 연결 문제가 생긴 것이 원인임
    • github.com은 먼저 복구됐고, 나머지 지역 배포는 순차적으로 복구됨

  • Projects 서비스 지연

    • Disruption with projects service는 해결됨
    • Projects가 동기화되지 않거나 변경 반영이 지연될 수 있었음
      • 변경 반영 지연은 최대 약 45분까지 커짐
    • serialization error가 이벤트 실패와 resync 급증을 일으켜 이벤트 처리 계층을 과부하시킨 것이 원인임
    • 들어오는 변경 처리 속도를 높여 완화했고, 이후 backlog를 소진하며 복구함

  • 코드 스캐닝 기본 설정·Code Quality 저하

    • Partial degradation for code scanning default setup and for code quality는 해결됨
    • 새 pull request에서 code scanning default setup과 code quality 분석이 트리거되지 않았음
    • 새로 만든 issue가 project board에 보이지 않는 문제도 함께 발생함
    • serialization error로 코드 스캐닝, 코드 품질 분석, project board 업데이트가 제대로 트리거되지 않은 것이 원인임
    • code scanning·code quality 이벤트 발행을 복구했고, project board 쪽은 추가 코드 변경과 reindex로 복구함
    • incident 이전이나 도중에 처리되지 않은 PR은 새 push가 있어야 분석이 다시 트리거됨

기타 최근 장애 사례

  • Disruption with some GitHub services
    • GitHub.com 웹 경험이 저하됐고, 약 1.5% 웹 요청이 오류로 끝남
    • 일부 시점에는 웹 트래픽의 약 10% 가 느려지거나 실패함
    • 한 데이터센터 지역의 캐시 컴포넌트 용량 포화가 원인임
    • 영향 없는 지역으로 트래픽을 우회하고 최근 배포를 롤백해 복구함
  • Incident with Codespaces
    • VS Code editor를 통한 GitHub Codespaces 연결이 실패함
    • 약 40% codespace start 작업이 실패함
    • SSH 연결은 영향받지 않음
    • upstream download service 장애로 시작 시 필요한 VS Code Server 다운로드가 막힌 것이 원인임
    • 기본 엔드포인트가 저하될 때 대체 다운로드 경로를 쓰는 우회책으로 완화함
  • Disruption with some GitHub services
    • GitHub Enterprise Cloud의 Copilot Insights 페이지 접근 시 500 오류가 발생함
    • 약 709명 사용자가 영향받았고, 총 영향 시간은 약 5시간 10분임
    • metrics pipeline의 인증 실패와 tenant credential 변경이 원인임
    • 진단 도구, 더 세밀한 모니터링, alerting 강화를 진행 중임

함께 보면 좋은 글 β

▲
GN⁺ 5시간전  [-]
Hacker News 의견들

  • 지금은 조용히 실패하는 것도 더 문제임
    예를 들어 PR이 수십 개 있는데도 "There aren’t any open pull requests."라고 보여줘서 사람들을 확실히 오도하게 됨

    • 지난주엔 merge queue를 쓰면 실수로 trunk를 날려버린 일도 있었고, 그것도 조용히 실패했음
    • 우리 쪽은 오히려 드디어 PR을 전부 끝낸 것처럼 보여서 축하 중이라고 농담하게 됨
    • PR 목록이 뜨더라도 보고 있는 카테고리의 PR을 전부 보여주지 않는 경우가 있어서 정말 악질적임

  • 이건 내게 정말 크게 와닿음
    몇 달 전 $PARENT_CONGLOMERATE가 시너지와 효율성을 이유로 산하 조직 전체에 GitHub 마이그레이션을 강제했고, 이제 $DAYJOB에서도 self-hosted GitLab에서 옮기는 차례가 됐음
    이미 불만이 몇 가지 있음
    GH 계정 관련 IT 정책은 앞뒤가 안 맞아서, 개인 계정이든 예전에 $DAYJOB용으로 따로 만든 계정이든 기존 계정을 전혀 못 쓰고 IT 규칙에 맞춘 새 계정을 다시 만들어야 함
    우리는 monorepo를 쓰지 않아서 groups를 많이 활용했는데 GitHub에는 그 개념이 직접 대응되지 않아 프로젝트 namespace를 수동으로 정리해야 함
    거기에 이제 GitHub의 가용성까지 이 모양임
    우리 팀은 출시 일정이 수익에 민감해서 하루이틀만 밀려도 월간 목표 달성 여부가 갈릴 수 있음
    다른 상황이면 수익 핵심 코드를 미리 미러링했겠지만, 그런 게릴라성 우회책을 만들 만큼 위험을 감수할 가치는 없어 보임
    가까운 미래의 포스트모템에서 The Synergy Mandate를 탓할 수 있으면 좋겠지만, 현실적으로 그럴 일 없다는 건 나도 잘 앎
    수익 목표를 계속 맞추고 실적 부진으로 제품이 잘려 나가지 않기만 바랄 뿐임
    이렇게 적다 보니 내가 입사했을 때와 지금 이 일이 얼마나 달라졌는지 더 실감하게 됨

  • 모든 OSS 프로젝트에 다시 말하고 싶음
    간단한 CI 작업으로 여러 forge 사이에서 코드를 동기화하는 건 엄청 쉽게 할 수 있고, 두 번째 forge의 이메일 알림을 받는 데도 추가 부담이 거의 없음
    적어도 GitHub 바깥으로 옮겨서 기여할 선택지는 열어둬야 하고, 결국 그게 생태계 전체에 더 나음

    • 코드 동기화 자체는 쉽고 사소한 부분이며, CI 작업은 사실 그 부분만 해결함
      대부분 프로젝트에선 그것조차 아주 필수는 아닐 수 있음
      어려운 건 코드 주변의 것들임
      tickets와 PR, 닫힌 것들까지 포함한 기록
      프로젝트를 참조하는 각종 링크
      CI 설정
      큰 프로젝트라면 커미터 권한 구성
      필요하다면 push/commit/branch 규칙까지 전부 옮겨야 함
      이런 건 프로젝트마다 마이그레이션하기 매우 성가시고, 일부는 잃어버릴 수도 있음
      그런데 더 큰 문제는 소프트웨어를 찾는 기본 플랫폼을 잃는 일임
      소프트웨어판 fediverse는 언제 나오나 싶음
    • 동기화는 사소하지만 진짜 핵심은 CI임
      아직도 GitHub Actions가 최선의 선택지이고, FSF든 다른 OSS 랩이든 오픈소스 유지보수자들에게 제대로 된 CI를 제공하지 못했음
      게다가 CI 부하도 예전보다 엄청 커졌음
    • 자체 GitLab 인스턴스를 꾸리는 것도 좋은 해법일 수 있음

  • 이제는 진지하게 대안을 밀어야겠다고 느낌
    이게 우리 비즈니스에 실제 영향을 주기 시작했고, 나아질 기미도 전혀 안 보임

    • GitHub 같은 UI를 원하면 Forgejo나 Gitea를 쓰면 됨
      org/repo 구조 제약은 감수해야 함
      비슷하지만 약간 다른 경험을 원하면 GitLab이 맞음
      커널 쪽에 가까운 방식, 즉 호스팅과 유연한 저장소 구조, ssh key 기반 사용자 인증, 단순한 웹 UI를 원하면 gitolite에 cgit를 붙이거나 gitweb을 쓰면 됨
    • 우리는 몇 년째 Gitea와 Drone/Woodpecker를 self-hosting 중인데 아주 잘 돌아감
      Gitea든 Forgejo든 제공 기능만 맞으면 충분함
      가끔 GitHub 장애 스레드에 와서 웃고 가는데, 우리 Gitea 인스턴스는 지난 몇 년간 총 다운타임이 몇 분 수준이었고 전부 한밤중의 계획된 업그레이드였음
    • GitLab이 더 주목받지 않는 게 의외임
      완전한 복제품은 아니어도 충분히 가깝고, 오렌지와 사과 차이보다는 사과와 배 정도 차이라고 봄
    • 나도 같은 생각이었음
      다만 GitHub는 정말 끈적한 플랫폼이라 actions와 온갖 연동을 깔아두면 떠나기 어려움
      그래도 장애가 이렇게 자주 나는 건 이제 좀 황당한 수준임
    • 지금은 Forgejo로 Git과 CI를 self-hosting 중인데 아주 만족스럽게 잘 돌아감

  • GitHub만의 일이 아니라 더 큰 장애로 보임: https://downdetector.com

    • 공통 분모가 Azure일 가능성이 커 보임

  • 오늘도 하루 끝에 y가 들어가니, 그렇다면 역시 GitHub 장애가 있다는 뜻이 됨

  • Codeberg.org도 지금 문제가 있음

    https://status.codeberg.org/status/codeberg

    https://social.anoxinon.de/@codebergstatus/11647770704799298...

  • GitHub가 죽는 것도 싫고, AI가 코드 훔쳐가는 것도 싫다면 sourcehut을 써보면 좋겠음
    내겐 아주 잘 맞았고, 플랫폼으로 더 번성했으면 함

    • 새 저장소를 탐험하는 경험이 좋아서 나는 전부 Codeberg로 옮겼고, 내가 관심 있는 프로젝트들 대부분도 거기 있음
    • sourcehut이 뭐가 다른지 모르겠음
      결국 그것도 또 다른 중앙집중형 서비스 아닌가 싶음

  • 이번 건 유난히 오래 걸리네 싶음
    고치는 팀이 Claude 세션 제한에 걸려 쿨다운 끝날 때까지 손도 못 대고, AI 없이 직접 고칠 줄 아는 유일한 사람은 수술하러 자리를 비웠다는 식의 농담이 떠오름
    AI 없이 직접 고치던 세대가 전부 은퇴하면 그다음엔 어떻게 되나 싶기도 함

  • GitHub가 내려갈 때마다 몇 사람씩 더 윤리적 대안으로 옮기고, FOSS 커뮤니티가 Microsoft 하나에 SPOF를 두는 구조도 조금씩 약해짐

    https://sfconservancy.org/GiveUpGitHub/

    • 그 취지에는 공감하지만, 많은 프로젝트가 GitHub에 모여 있던 사회적 측면은 분명 장점이 있었음
      협업이 쉬웠고, 지금은 여러 이유로 마찰이 커지는 중임
      issues가 스팸처럼 쓰이는 일도 늘고 있고, 그보다 더 악의적인 활동도 점점 보이기 시작함
    • SPOF는 Single Point of Failure의 약자임
답변달기