{"id":"IL-0262","org":"GitHub","date":"2026-08-17","docs":[],"title":{"en":"Requests through one GitHub datacenter failed or slowed after its load balancer nodes ran out of network flows","ko":"한 데이터센터의 로드 밸런서가 과부하에 걸려 GitHub 의 인증 경로와 이 데이터센터를 지나는 여러 서비스가 오류와 느린 응답을 냈다"},"domain":["networking"],"impact":{"scope":"Issues and pull requests (pages and API) and other services routed through the same datacenter's load balancers: REST and GraphQL APIs, Actions, Copilot, sign-in and authentication, webhooks API; impact for approximately 6 hours 44 minutes; no data lost","users":"about 29K organizations saw at least one failed or slow request; over roughly 4.8M failed or slow requests in total","region":"one GitHub datacenter"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"GitHub named the core weakness as the service-mesh sidecar that did not scale up, together with its retry behavior, and clients that were not bound enough to keep a partial degradation from amplifying into a broader overload.","ko":"GitHub 는 핵심 약점을 두 가지로 봤다. 서비스 메시 사이드카가 확장되지 않은 것과 재시도 동작이다. 클라이언트에 충분한 제한이 없어서 일부 구간의 성능 저하가 더 넓은 과부하로 커지는 것을 막지 못했다."},"related":[],"sources":[{"url":"https://github.blog/news-insights/company-news/github-availability-report-august-2026/","kind":"blog","archived":"https://web.archive.org/web/20261113132610/https://github.blog/news-insights/company-news/github-availability-report-august-2026/"},{"url":"https://www.githubstatus.com/incidents/zkxwbgr0cnmx","kind":"official-status","archived":"https://web.archive.org/web/20261102181055/https://www.githubstatus.com/incidents/zkxwbgr0cnmx"}],"summary":{"en":"A new traffic peak pushed one GitHub datacenter's load balancers towards and then past their limits. A service-mesh sidecar hit its concurrency limit and failed to scale up; GitHub's follow-up is to make autoscaling policies account for the sidecar's concurrency and capacity, not just the host service. As requests backed up, several load-balancer nodes exhausted their network flow limits, which degraded the shared gateway authentication path. Issues, pull requests, the APIs, Actions, Copilot and other services routed through that datacenter began returning errors and slow responses. A latent client retry bug amplified traffic to one internal authentication endpoint, slowing recovery for the Copilot Token Service; GitHub names its retry behavior, together with clients that were not bound enough, as what let the partial degradation grow into a broader overload.\n\nAutomated monitoring opened an incident and the affected products were marked degraded on the public status page. Engineers traced the failure to network saturation on the datacenter's load balancers, shifted some traffic to another datacenter and reduced gateway retries. Stopping the load-balancer processes on the saturated nodes and blocking the retry-triggering requests to the most affected internal endpoint brought broad and immediate recovery. Remaining authentication errors from client retry amplification were stabilised by ramping traffic back up gradually, and the incident was resolved after a sustained period of healthy telemetry. No data was lost. The report gives the incident as lasting 7 hours and 35 minutes, with impact for approximately 6 hours 44 minutes.","ko":"사고는 2026년 8월 17일 13시 40분 UTC 에 시작해 7시간 35분 동안 이어졌고, 그중 서비스가 영향을 받은 시간은 약 6시간 44분이었다. 트래픽이 새 최고치를 찍으면서 한 데이터센터의 로드 밸런서가 한계를 넘었다. 서비스 메시 사이드카 하나가 동시 처리 한도에 닿았지만 확장되지 않았고, 요청이 밀리자 로드 밸런서 노드 여러 대가 네트워크 flow 한도를 다 썼다. 그 결과 공용 게이트웨이의 인증 경로가 나빠졌고, 그 데이터센터를 지나는 이슈, 풀 리퀘스트, API, Actions, Copilot, 로그인과 인증, webhooks API 가 오류와 느린 응답을 냈다. 숨어 있던 클라이언트 재시도 버그는 내부 인증 엔드포인트 하나로 가는 트래픽을 크게 부풀려 Copilot Token Service 의 복구를 늦췄다.\n\n자동 모니터링이 오류 증가를 잡아 사고 대응이 시작됐고, 상태 페이지에 영향받은 제품이 degraded 로 표시됐다. 엔지니어들은 원인을 한 데이터센터 로드 밸런서의 네트워크 포화로 짚고, 트래픽 일부를 다른 데이터센터로 옮기며 게이트웨이 재시도를 줄였다. 포화된 노드의 로드 밸런서 프로세스를 멈추고 가장 영향을 많이 받은 내부 엔드포인트로 가는 재시도를 일으키는 요청을 막자 서비스 전반이 곧바로 회복됐다. 남은 인증 오류는 트래픽을 천천히 다시 올리며 잡았고, 정상 지표가 한동안 이어진 뒤 사고를 종료했다. 가장 심할 때 들어온 요청의 56.07% 가 실패하거나 느렸고, 약 29,000 개 조직이 영향을 받았다. 데이터 손실은 없었다."},"trigger":{"en":"A new peak in traffic pushed the load balancers of one GitHub datacenter past their limits.","ko":"트래픽이 새 최고치를 찍으면서 한 데이터센터의 로드 밸런서가 한계를 넘었다. 서비스 메시 사이드카 하나가 동시 처리 한도에 닿았는데도 확장되지 않았다."},"severity":"unknown","symptoms":["high-error-rate","high-latency"],"timeline":{"detected_after":null,"resolved_after":"7h 35m"},"date_kind":"incident","detection":{"en":"Automated monitoring detected the elevated errors and an incident was opened; the affected products were marked degraded on the public status page.","ko":"자동 모니터링이 오류 증가를 잡아 사고 대응이 시작됐다. 영향받은 제품은 공개 상태 페이지에 degraded 로 표시됐다."},"components":["on-premises-load-balancer","service-mesh"],"root_cause":"capacity","remediation":[{"text":{"en":"Shifted some traffic to another datacenter","ko":"트래픽 일부를 다른 데이터센터로 옮기기 시작했다."}},{"text":{"en":"Reduced gateway retries to relieve the pressure on the load balancers","ko":"부담을 덜려고 게이트웨이의 재시도를 줄였다."}},{"text":{"en":"Stopped the load-balancer processes on the saturated nodes","ko":"포화된 노드의 로드 밸런서 프로세스를 멈췄다."}},{"text":{"en":"Blocked the retry-triggering requests to the most affected internal endpoint","ko":"재시도를 일으키는 요청 가운데 가장 영향을 많이 받은 내부 엔드포인트로 가는 요청을 막았다. 이 조치와 로드 밸런서 프로세스 중지로 서비스 전반이 곧바로 회복됐다."}},{"text":{"en":"Ramped traffic back up gradually to stabilise the remaining authentication errors","ko":"클라이언트 재시도가 트래픽을 부풀려 인증 오류가 남아 있었다. 엔지니어들은 트래픽을 천천히 다시 올리면서 이 오류를 가라앉혔다."}}],"action_items":[{"text":{"en":"Correct autoscaling policies so they account for service-mesh sidecar concurrency and capacity, not just the host service","ko":"오토스케일링 정책이 호스트 서비스만이 아니라 서비스 메시 사이드카의 동시 처리 수와 용량도 따지도록 고친다."}},{"text":{"en":"Audit request, concurrency and scaling limits for the service mesh across the affected services","ko":"영향받은 서비스 전반에서 서비스 메시의 요청 한도, 동시 처리 한도, 스케일링 한도를 점검한다."}},{"text":{"en":"Review retry and backoff limits across gateways and clients","ko":"일부 구간의 성능 저하가 더 넓은 과부하로 커지지 않도록 게이트웨이와 클라이언트 전반의 재시도와 백오프 한도를 다시 살핀다."}},{"text":{"en":"Fix the client retry behavior that amplified authentication traffic","ko":"사고 동안 인증 트래픽을 부풀린 클라이언트 재시도 동작을 고친다."}},{"text":{"en":"Improve load-balancer capacity monitoring","ko":"로드 밸런서 용량 모니터링을 개선한다."}},{"text":{"en":"Strengthen regional failover safeguards","ko":"리전 페일오버 안전장치를 강화한다."}}],"contributing":["retry-storm"],"recurrence_of":null,"symptoms_text":{"en":"On 17 August 2026 from 13:40 UTC, GitHub issues and pull requests returned errors and slow responses on their pages and in the API. Automated monitoring detected the raised errors, and many other services that route through the same datacenter's load balancers, including the REST and GraphQL APIs, Actions, Copilot, sign-in and authentication, and the webhooks API, also showed errors and latency.\n\nAt the peak, 56.07% of front-door requests to the affected services failed or were slow at the edge. Across the window about 29K organizations saw at least one failed or slow request, over roughly 4.8M failed or slow requests in total. Retrying often worked, but during the worst stretches a large share of attempts failed.\n\nThe overload started in one datacenter when a new traffic peak pushed its load balancers past their limits. A service-mesh sidecar reached its concurrency limit and did not scale up, requests backed up, and several of the datacenter's load-balancer nodes exhausted their network flow limits. That degraded the shared gateway authentication path, so authentication became slow and failed across the many services behind that datacenter. A latent client retry bug then sharply raised traffic to one internal authentication endpoint and slowed recovery of the Copilot Token Service.\n\nEngineers traced the failure to network saturation on the load balancers of the single datacenter. They began shifting some traffic to another datacenter and reducing gateway retries to relieve the pressure. Broad and immediate recovery came when the load-balancer processes on the saturated nodes were stopped and the requests that triggered retries to the most affected internal endpoint were blocked.","ko":"자동 모니터링이 오류 증가를 잡아 사고 대응이 시작됐다. 이슈와 풀 리퀘스트의 페이지와 API 가 오류를 내거나 느리게 응답했고, 같은 데이터센터의 로드 밸런서를 지나는 다른 서비스들도 오류와 지연을 보였다.\n\n영향은 이슈와 풀 리퀘스트에서 가장 잘 보였다. 같은 데이터센터의 로드 밸런서를 거치는 REST API, GraphQL API, Actions, Copilot, 로그인과 인증, webhooks API 도 오류와 지연을 냈다. 공용 게이트웨이의 인증 경로가 나빠지면서 이 서비스들 전반에서 인증이 느려지거나 실패했다.\n\n가장 심할 때 영향받은 서비스로 들어온 요청의 56.07% 가 엣지에서 실패하거나 느렸다. 사고 동안 약 29,000 개 조직이 실패하거나 느린 요청을 한 번 이상 겪었다. 실패하거나 느린 요청은 모두 약 480만 건이었다. 다시 시도하면 대개 됐지만, 가장 나쁜 구간에는 시도의 상당수가 실패했다.\n\n과부하는 번져 나갔다. 서비스 메시 사이드카가 동시 처리 한도에 닿았는데도 확장되지 않았고, 요청이 밀리자 로드 밸런서 노드 여러 대가 네트워크 flow 한도를 다 썼다. 클라이언트의 재시도 버그가 내부 인증 엔드포인트 하나로 가는 트래픽을 크게 부풀려 Copilot Token Service 의 복구를 늦췄다.\n\n엔지니어들은 장애를 한 데이터센터 로드 밸런서의 네트워크 포화로 좁혔다. 먼저 트래픽 일부를 다른 데이터센터로 옮기고 게이트웨이 재시도를 줄여 부담을 덜려 했다. 포화된 노드의 로드 밸런서 프로세스를 멈추고 재시도를 일으키는 요청을 막자 서비스 전반이 곧바로 회복됐다."},"updated_at":"2026-11-14T12:33:51.297392Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0262","org_slug":"github"}