GitHub 장애 이력을 서비스·심각도별로 필터링한 'Is GitHub Cooked?' 추적기

GitHub 상태 이력에 필터를 붙인 아이디어는 다른 사이트에서도 본 적 있음. 기여 그래프처럼 장애를 달력에 표시하는 방식 자체가 새롭진 않다고 봄.

사이트 만든 사람인데, 2026년 2월에 만들었음. 장애 달력 아이디어는 예전에 정적 이미지로 본 적 있지만 이 사이트를 베낀 건 아님.

장애 없는 시간이 업무 시간 밖에 몰려 있으면 전체 가동률은 별 의미 없을 수 있음. 미 동부 9시부터 5시까지 기준으로 보면 장애 없는 시간이 60%쯤일 거라고 봄.

'정상 업무 시간'을 미 동부 시간으로 잡는 건 너무 미국 중심적임. 유럽, 인도, 중국, 라틴아메리카 사용자에게는 다른 시간대가 업무 시간임.

호주에서 매일 GitHub 쓰는데 왜 다들 가동률로 불평하는지 아직 잘 모르겠음.

페이지를 그냥 정적인 'Yes' 한 단어로 만들어도 상당 시간은 맞았을 것 같음.

AI 때문에 빌드와 푸시가 늘어난 규모를 생각하면 GitHub에도 어느 정도 동정심은 듦. 신규 사용자나 사이트 접근을 의도적으로 막지 않는 점은 좋게 봄.

돈 내는 고객 입장에서는 동정할 일이 아님. 상용 서비스가 약속한 수준으로 동작하지 않고, 가용성이 9 하나뿐이면 받아들이기 어려움.

Microsoft가 AI 사용량을 직접 늘리도록 밀어놓고 트래픽을 이유로 드는 건 설득력 없음. 무료 사용자 트래픽이 엔터프라이즈 고객 작업을 멈추게 하면 안 됨.

내가 GitHub에 돈을 내는데 다운타임으로 일이 멈춤. 감당 못 할 주문을 계속 받는 식이면 신규 요청을 제한하거나 처리 용량부터 늘려야 함.

Microsoft는 작년에 순이익 1,340억 달러를 냈고 시가총액도 거의 4조 달러임. 해결할 자원이 없어서가 아니라 우선순위를 두지 않는 것처럼 보임.

장애 공개 방식은 그래도 다른 대형 사업자보다 낫다고 봄. 실제로 문제가 있는데 상태 페이지를 전부 초록색으로 유지하는 곳도 많음.

GitHub 엔지니어에게는 공감하지만 GitHub라는 회사에는 공감하지 않음. 코드 푸시, 풀, PR 협업은 돈 내는 고객에게 기본 기능이고 멈추면 안 됨.