{"id":"IL-0227","org":"Heroku","date":"2025-06-10","docs":[],"title":{"en":"Most Heroku dynos in Private Spaces lost outbound connectivity after an automated OS update restarted host networking","ko":"의도하지 않은 자동 OS 업데이트가 호스트 네트워킹을 다시 시작해 Heroku dyno 의 외부 연결이 끊기고 많은 고객이 최대 24시간 서비스 중단을 겪었다."},"domain":["networking"],"impact":{"scope":"Heroku applications: most dynos in Private Spaces without outbound connectivity, intermittent logins, application failures, the Heroku Dashboard and the Heroku Status Page","users":"many customers, with up to 24 hours of downtime","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Heroku's post-mortem names three areas: production lacked immutability controls, so an automated process could change it; communication was too slow, made worse by a status page that went down with the platform; and gaps in tooling and process made recovery take longer than it should have.","ko":"사후 분석은 세 가지 개선 영역을 짚었다. 운영 환경을 함부로 바꾸지 못하게 막는 불변성 통제가 부족해 자동 프로세스가 운영 환경에 계획에 없던 변경을 할 수 있었다. 상태 페이지가 사고의 영향을 받으면서 고객이 가장 필요로 할 때 제때 공지하지 못했다. 도구와 절차의 빈틈 때문에 엔지니어가 문제를 빨리 진단하고 해결하지 못해 복구가 필요 이상으로 오래 걸렸다."},"related":[],"sources":[{"url":"https://www.heroku.com/blog/summary-of-june-10-outage/","kind":"blog","archived":"https://web.archive.org/web/20261102123403/https://www.heroku.com/blog/summary-of-june-10-outage/"}],"summary":{"en":"Beginning at 06:00 UTC on 10 June 2025, Heroku customers had a service disruption that meant up to 24 hours of downtime for many of them; it was not a security incident, and no customer data was lost. The networking service on Heroku's hosts relied on a legacy script that applied the correct routing rules only on initial boot. When the automated update restarted the service, the routes were not applied again, and every dyno on the host lost outbound network connectivity. Heroku's internal tools and the Heroku Status Page ran on the same affected infrastructure, so the outage also hampered Heroku's response and its communication with customers. Heroku names a lack of immutability controls, which let an automated process change production, and gaps in tooling and process, which slowed diagnosis.\n\nFrom 12:56 UTC the team restarted internal instances in rotation, which gave some relief, and from 13:58 UTC it posted updates to the @herokustatus account on X. Heroku asked an upstream vendor to invalidate the token used for the automated updates; this was confirmed at 17:30 UTC and completed at 19:18 UTC, so no further hosts were hit, and the automated upgrade service was disabled. The Heroku Dashboard was fully restored by 20:59 UTC, a fleetwide dyno recycle started at 22:01 UTC, and after downstream systems caught up the incident was declared resolved at 05:50 UTC on 11 June.","ko":"2025-06-10 06:00 UTC 부터 Heroku 고객이 서비스 중단을 겪었고, 많은 고객에게 중단은 최대 24시간 이어졌다. 보안 사고가 아니었고 고객 데이터도 잃지 않았다. 세 가지 문제가 겹쳤다. 꺼져 있어야 할 자동 운영체제 업데이트가 운영 인프라에서 돌아 호스트의 네트워킹 서비스를 다시 시작했다. 네트워킹 서비스는 올바른 라우팅 규칙을 첫 부팅 때만 적용하는 오래된 스크립트에 기대고 있었다. 그래서 재시작 뒤 경로가 다시 적용되지 않았고, 그 호스트에 있는 모든 dyno 의 외부 연결이 끊겼다. Heroku 의 내부 도구와 Heroku Status Page 가 같은 인프라에서 돌아, 애플리케이션이 망가지는 동안 대응과 고객 소통도 함께 막혔다.\n\n06:00 부터 간헐적 로그인 문제와 dyno 네트워킹 오류가 나타났고, 08:26 에 Private Spaces 의 dyno 대부분이 외부 HTTP 요청을 보내지 못한다는 것이 확인됐다. 팀은 정상 호스트와 비정상 호스트를 비교해 11:54 에 빠진 네트워크 경로를 찾았고, 13:11 에 예상하지 못한 네트워크 서비스 재시작을 알았으며, 13:42 에 시스템 패키지 자동 업그레이드를 촉발 원인으로 짚었다.\n\n원인 조사와 함께 12:56 부터 내부 인스턴스를 돌아가며 다시 시작했고, 13:58 에 X 의 @herokustatus 계정으로 공지를 올리기 시작했다. 업스트림 벤더를 통해 자동 업데이트에 쓰는 토큰을 무효화해 19:18 에 더는 다른 호스트가 영향받지 않게 했다. Heroku Dashboard 는 20:59 에 완전히 복구됐고, 22:01 에 남은 서비스를 안정시키려고 전체 dyno recycle 을 시작했다. 그 뒤 Private Spaces 복구와 밀린 작업 처리가 길게 이어졌고, 6월 11일 05:50 에 사고가 해결로 선언됐다."},"trigger":{"en":"An automated operating system update ran on Heroku's production infrastructure when it should have been disabled, and it restarted the hosts' networking services.","ko":"꺼져 있어야 할 자동 운영체제 업데이트가 운영 인프라에서 돌아 호스트의 네트워킹 서비스를 다시 시작했다. 올바른 라우팅 규칙은 첫 부팅 때만 도는 오래된 스크립트가 넣은 것이었다. 그래서 서비스가 다시 시작된 뒤 경로가 다시 적용되지 않았고, 그 호스트에 있는 모든 dyno 의 외부 네트워크 연결이 끊겼다."},"severity":"unknown","symptoms":["network-unreachable","service-unavailable","high-error-rate"],"timeline":{"detected_after":null,"resolved_after":"23h 50m"},"date_kind":"incident","detection":{"en":"Customers reported intermittent logins, and Heroku's monitoring detected widespread errors with dyno networking. Heroku's own tools and the Heroku Status Page were affected as well.","ko":"06:00 UTC 부터 서비스 성능이 크게 떨어지자 고객이 간헐적인 로그인 문제를 알렸고, 모니터링이 dyno 네트워킹에서 넓은 범위의 오류를 잡았다. Heroku 의 자체 도구와 Heroku Status Page 도 함께 영향을 받았다."},"components":["host-routing"],"root_cause":"upgrade-breaking-change","remediation":[{"text":{"en":"Restarted internal instances in rotation, which gave some relief","ko":"UTC 12:56 부터 내부 인스턴스를 돌아가며 다시 시작해 증상을 어느 정도 덜었다."}},{"text":{"en":"Had an upstream vendor invalidate the token used for the automated updates","ko":"업스트림 벤더에 요청해 자동 업데이트에 쓰는 토큰을 무효화했다. 17:30 에 확인됐고 19:18 에 끝나, 더는 다른 호스트가 영향받지 않았다."}},{"text":{"en":"Disabled the automated upgrade service","ko":"사고 중인 6월 10일에 자동 업그레이드 서비스를 껐다."}},{"text":{"en":"Recycled dynos across the whole fleet","ko":"Heroku Dashboard 가 20:59 에 완전히 복구된 뒤, 22:01 에 남은 서비스를 안정시키려고 전체 dyno recycle 을 시작했다."}}],"action_items":[{"text":{"en":"Put permanent controls in place so no system change happens outside the controlled deployment process","ko":"다음 주 초에 영구적인 통제 장치를 넣어, 앞으로는 통제된 배포 절차 밖에서 시스템 변경이 일어나지 않게 한다."}},{"text":{"en":"Audit all base images for similar risks","ko":"모든 베이스 이미지에 비슷한 위험이 있는지 감사한다."}},{"text":{"en":"Make network routing survive graceful restarts of the networking service","ko":"네트워크 서비스가 다시 시작돼도 문제없도록 네트워크 라우팅을 개선한다."}},{"text":{"en":"Build fully independent backup communication channels","ko":"최악의 상황에서도 제때 공지할 수 있도록 운영 인프라와 완전히 독립된 백업 소통 채널을 만든다."}},{"text":{"en":"Overhaul incident response tooling, including tools that run queries across the whole fleet","ko":"엔지니어가 문제를 더 빨리 진단하고 전체 호스트에 대규모로 질의할 수 있도록 새 도구를 만들고 기존 도구를 개선한다."}},{"text":{"en":"Streamline break-glass procedures for rapid access to critical systems","ko":"비상시 팀이 핵심 시스템에 빨리 접근할 수 있도록 break-glass 절차를 간소화한다."}},{"text":{"en":"Improve monitoring to detect complex issues earlier","ko":"복잡한 문제를 훨씬 일찍 잡도록 모니터링을 강화한다."}}],"contributing":["unpinned-version","circular-dependency","limited-debug-access"],"recurrence_of":null,"symptoms_text":{"en":"From 06:00 UTC on 10 June 2025, Heroku services degraded badly: customers reported intermittent logins, applications failed, and Heroku's monitoring detected widespread errors with dyno networking. Heroku's own tools and the Heroku Status Page were affected as well, which delayed communication with customers and left many of them without accurate status updates. Only at 13:58 UTC did the team find a workaround to post updates to the @herokustatus account on X.\n\nBy 08:26 UTC the investigation confirmed the core problem: most dynos in Private Spaces could not make outbound HTTP requests. The team ruled out an upstream provider issue and placed the failure in Heroku's own infrastructure, and comparing healthy and unhealthy hosts showed missing network routes at 11:54 UTC.\n\nOnly at 13:11 UTC did the team learn of an unexpected restart of the network service, and at 13:42 UTC it found the trigger, an automated upgrade of a system package. Many customers had up to 24 hours of downtime. After service came back, delayed work kept arriving for hours: status emails from early in the incident were delivered late, Heroku Connect syncing had to catch up, and the Heroku release phase had a long backlog that took a few hours to clear. The incident was declared resolved at 05:50 UTC on 11 June.","ko":"2025-06-10 06:00 UTC 부터 Heroku 서비스의 성능이 크게 떨어졌다. 고객은 로그인이 됐다 안 됐다 한다고 알렸고, 모니터링은 dyno 네트워킹에서 넓은 범위의 오류를 잡았다.\n\nHeroku 의 내부 도구와 Heroku Status Page 도 같은 인프라에서 돌아 함께 영향을 받았다. 고객은 정확한 상태 정보를 볼 수 없었고, Heroku 팀이 고객에게 상황을 알리는 일도 크게 늦어졌다. 팀은 13:58 에야 X 의 @herokustatus 계정으로 공지를 올리는 우회 방법을 찾았다.\n\n08:26 에 Private Spaces 의 dyno 대부분이 외부로 HTTP 요청을 보내지 못한다는 것이 핵심 문제로 확인됐다. 이 문제 때문에 로그인이 간헐적으로 실패했고, 애플리케이션이 실패했으며, Heroku 팀의 공지가 늦어졌다.\n\n팀은 영향이 dyno 네트워킹에 한정된 것을 보고 영향받은 호스트를 분석했다. 업스트림 제공자 문제가 아니라 Heroku 인프라 안의 문제라고 판단했다. 이어 정상 호스트와 비정상 호스트를 비교해 11:54 에 네트워크 경로가 빠져 있는 것을 찾았다. 13:11 에 네트워크 서비스가 예상하지 못하게 다시 시작된 것을 알았고, 13:42 에 시스템 패키지의 자동 업그레이드를 촉발 원인으로 짚었다. 많은 고객이 최대 24시간 동안 서비스 중단을 겪었다.\n\n서비스가 돌아온 뒤에도 밀린 일이 오래 남았다. 사고 초기에 보낸 상태 이메일이 뒤늦게 전달됐고, Heroku Connect 동기화가 따라잡아야 했으며, Heroku release phase 는 밀린 작업을 처리하는 데 몇 시간이 걸렸다. 사고는 6월 11일 05:50 에 해결로 선언됐다."},"updated_at":"2026-11-14T05:53:44.443653Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0227","org_slug":"heroku"}