# GitHub의 과거 가동 시간 > Clean Markdown view of GeekNews topic #28081. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28081](https://news.hada.io/topic?id=28081) - GeekNews Markdown: [https://news.hada.io/topic/28081.md](https://news.hada.io/topic/28081.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-01T11:32:52+09:00 - Updated: 2026-04-01T11:32:52+09:00 - Original source: [damrnelson.github.io](https://damrnelson.github.io/github-historical-uptime/) - Points: 1 - Comments: 1 ## Topic Body - 2016년부터 2026년까지의 **GitHub 월별 가동 시간**을 시각화한 페이지 - 모든 데이터는 **공식 상태 페이지**에서 수집된 기록 기반 - **평균 가동률(Average)** 과 **세부 중단 내역(Breakdown)** 을 구분해 볼 수 있는 구조 - 페이지 내에서 **원본 데이터 소스(View source)** 로 직접 접근 가능 - 장기적인 **서비스 안정성 추이**를 한눈에 확인할 수 있는 시각화 자료 - 별도의 분석이나 해설 없이 **데이터 시각화 중심으로 구성된 형태** ## Comments ### Comment 54314 - Author: neo - Created: 2026-04-01T11:32:52+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47591928) - 2018년 이전의 데이터가 실제로 **정확한지** 궁금했음 예전에도 여러 번 장애가 있었던 걸로 기억함 아마도 그 시점부터 현재의 **uptime 추적 시스템**을 사용하기 시작한 것일 수도 있음 - 데이터는 공식 **status 페이지**에서 가져온 것임 다만 이 페이지는 관측용이라기보다는 **마케팅/커뮤니케이션용**에 가까웠던 것 같음 - 개인적으로는 이 [대체 상태 페이지](https://mrshu.github.io/github-statuses/)가 더 낫다고 생각함 “The Missing GitHub Status Page”라는 이름으로, 최근 90일간의 **가용성 비율**을 종합적으로 보여줌 현재는 90.84%로, 며칠 전의 90.00%보다 약간 나아졌음 - 최근 상황이 꽤 **거칠었음** GitHub Actions의 2026년 2월 가용률이 98%로, 단일 ‘9’ 수준임 체감상 50번 중 1~2번(약 2%) 정도 실패한 것 같음 - 이런 **종합 수치**는 그리 합리적인 지표가 아닌 듯함 예를 들어 OpenAI가 다운돼서 CoPilot이 작동하지 않을 때, 그걸 GitHub의 다운타임으로 볼 수 있을까 하는 의문이 있음 - 사실 두 페이지는 같은 통계를 다르게 보여주는 것뿐임 OP가 Microsoft 인수 이후의 결과를 강조하려는 방식으로 제시한 것 같음 - “90%면 거의 **5주간의 다운타임**”이라는 계산이 나옴 농담이지만, GitHub도 이제 그 정도의 ‘유급 휴가’를 누릴 자격이 생긴 셈임 - 기능이 도입된 **시점을 표시하지 않은** 채 데이터를 보여주는 건 편향적임 예를 들어 GitHub Actions는 2019년 8월에 출시됐으니, 그 이전에 다운타임이 없던 건 당연함 - “Breakdown”에서 “Actions”을 클릭하면 해당 항목을 숨길 수 있음 - 세부 페이지를 보면 개별 서비스의 규모는 줄어들지만, **전체적인 추세는 동일**하게 나타남 - 더 나쁜 건, 존재하지도 않았던 시기에도 “100% uptime”으로 표시된다는 점임 - 나도 몇 주 전에 **Claude**로 같은 그래프를 만들어봤음 Microsoft 인수 전후로 급격한 하락이 있을 거라 예상했지만, 실제로는 오래전부터 **불규칙한 장애 패턴**이 이어지고 있었음 인수 전이 더 안정적이었다는 서사는 흥미롭지만, 당시엔 Actions 같은 제품이 없었음 존재하던 서비스(API, Git ops, Pages 등)는 오히려 **관측성 개선**으로 설명할 수 있을 듯함 - Actions 출시 이후 운영과 가용성 측면에서 **악몽 같은 상황**이 시작된 느낌임 이후 문제들이 Issues나 PR 같은 안정적이던 영역으로 번졌음 - 개인적으로는 GitHub Actions 자체가 사라져야 한다고 생각함 Git은 원래 한 가지 일을 잘하도록 설계된 도구인데, 여기에 **불필요한 기능을 덕지덕지 붙인 것**이 큰 실수였음 - 사람들이 이유를 찾고 있다면, 이 [The New Stack 기사](https://thenewstack.io/github-will-prioritize-migrating-to-a...)가 설명이 될 수 있음 - 완전히 동의함. 우리 팀의 **Azure 장애**와 GitHub 장애는 거의 동시에 발생함 이제는 일종의 밈처럼 되어버림 - 다만 6년 넘게 이어진 **낮은 가용성**을 이 이유 하나로 설명하기는 어렵다고 생각함 테스트를 별도 환경에서 충분히 하고, 짧은 기간에 Azure로 이전했어야 했음 - 현재 **PR 병합 기능이 작동하지 않음** 관련 상태는 [GitHub Status Incident 페이지](https://www.githubstatus.com/incidents/ml7wplmxbt5l)에서 확인 가능함 - 예전에는 **유니콘 에러 페이지**를 자주 봤던 기억이 있음 아마 그때는 상태 페이지가 자주 갱신되지 않았던 것 같음 - 유니콘은 웹 페이지 전용 오류였던 듯함 Git API 같은 서비스는 별도로 고장 나기도 하고, 상태 페이지에는 **시간차를 두고 반영**되곤 했음 - 지금은 GitHub의 **다운타임 기록이 내 개인 서버보다 더 나쁜** 것 같음 나는 실험하느라 자주 재부팅하거나 서비스를 멈추는데도 말임 - 그래도 우리는 여전히 돈을 내고 있음 품질 저하가 있어도 **QoS 수준**이 유지된다고 믿는 듯함 - 내 작은 VPS조차 GitHub보다 **측정 가능한 수준으로 안정적**임 - 나는 GitHub을 옹호하는 사람은 아니지만, 그 그래프는 **축이 왜곡되어 있음** 99.5% 이하 구간만 확대되어 있어서 실제보다 훨씬 나쁘게 보임 - 하지만 0부터 그리면 좋은 서비스와 나쁜 서비스의 차이가 안 보임 기업용 SLA가 99.9%인데, 그래프의 하단은 그보다 **5배 많은 다운타임**을 보여줌 즉, 나쁘게 보이는 게 아니라 실제로 나쁜 것임 - 그래프에는 **부하(load)** 요소가 반영되지 않음 Microsoft 인수 전에는 개인 저장소가 하나로 제한되어 있었던 것도 고려해야 함 - uptime 차트를 0부터 그릴 필요는 없음 99%대 범위만 보여주는 게 합리적임 로그 스케일은 오히려 과하다고 생각함 - GitHub Pages로 웹사이트를 배포하고 있어서, **정적 호스팅 가용성**을 따로 조사해봤음 [이 블로그 분석](https://alexsci.com/blog/static-hosting-uptime/)에 따르면 GH Pages는 이 부문에서 꽤 좋은 성적을 보임 다만 그 공은 **Fastly CDN**이 가져가야 할 듯함