{"id":"IL-0373","org":"Heroku","date":"2024-07-27","docs":[],"title":{"en":"Heroku Postgres Essential-tier databases in the EU region ran out of memory and refused connections, twice in four days","ko":"EU 리전의 Heroku Postgres Essential 등급 데이터베이스가 메모리가 바닥나 두 번에 걸쳐 연결을 받지 못했다"},"domain":["database","observability"],"impact":{"scope":"33 Heroku Postgres clusters; some Essential-tier customers could not connect to their databases","users":"unknown","region":"EU (Dublin)"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://status.heroku.com/incidents/2678","kind":"official-status","archived":"https://web.archive.org/web/20251114162117/https://status.heroku.com/incidents/2678"}],"summary":{"en":"A third-party vendor deployed a monitoring change with a memory leak to the monitoring agent on Heroku's Postgres database clusters. Available memory on 33 clusters in the EU (Dublin) region fell steadily until the databases became inaccessible, and some Essential-tier customers could not connect. The first outage, found through customer support tickets nine hours after it began, was fixed only temporarily on 28 July by allocating more resources and restarting the clusters. A second outage began on 30 July. At 16:47 UTC that day a support engineer from the vendor joined and confirmed that a monitoring agent using up all available resources caused both outages. The technology team provisioned the previous version of the vendor's software, which did not have the leak, memory was reclaimed and the clusters returned to a healthy state, and Heroku was declared out of impact at 17:56 UTC on 30 July; the resolving status update gives the second impact window as 06:04 to 16:28 UTC. The vendor provided a temporary fix and was working on a permanent one.","ko":"제3자 업체가 배포한 모니터링 변경에 메모리 누수가 있었다. 이 모니터링 에이전트가 쓸 수 있는 자원을 다 써서 Heroku Postgres 데이터베이스 클러스터의 가용 메모리가 계속 줄었다. 2024년 7월 27일 22:31 UTC 부터 EU/Dublin 리전의 클러스터 33개가 요청을 처리하지 못했다. Essential 등급 고객 일부는 데이터베이스에 연결하지 못했다. Heroku Support 가 7월 28일 07:50 UTC 에 고객 지원 티켓을 받고 기술 팀을 호출했고, 기술 팀은 자원을 더 배정하고 클러스터를 재시작해 14:16 UTC 에 문제를 일시적으로 풀었다.\n\n7월 30일 06:04 UTC 에 Heroku Support 의 에스컬레이션으로 둘째 장애가 시작됐다. 16:47 UTC 에 제3자 업체의 지원 엔지니어가 합류해, 두 장애의 근본 원인이 모든 자원을 써 버린 모니터링 에이전트라고 확인했다. 기술 팀은 이 문제가 없는 제3자 서비스의 이전 버전을 프로비저닝하는 우회책을 적용했다. Postgres 데이터베이스 클러스터를 이전 안정 버전으로 바꾸자 메모리가 회수되어 클러스터가 건강한 상태로 돌아왔다. 사후 보고는 17:56 UTC 에 영향이 끝났다고 선언했다고 적었다. 반면 상태 페이지의 해결 공지는 영향 기간을 6:04 AM UTC 부터 4:28 PM UTC 까지로 적었다. 제3자 업체는 영구 수정을 만들고 있고, 그 사이 임시 수정을 제공했다."},"trigger":{"en":"A third-party vendor deployed a change to a monitoring agent that runs on Heroku's Postgres database clusters.","ko":"제3자 업체가 메모리 누수가 있는 모니터링 변경을 배포했다."},"severity":"unknown","symptoms":["memory-pressure","service-unavailable"],"timeline":{"detected_after":"9h 19m","resolved_after":"15h 45m"},"date_kind":"incident","detection":{"en":"Heroku Support paged the technology team at 07:50 UTC on 28 July based on customer support tickets. The second occurrence also reached the technology team as an escalation from Heroku Support.","ko":"첫 장애는 고객 지원 티켓으로 알았다. Heroku Support 가 7월 28일 07:50 UTC 에 고객 티켓을 받고 기술 팀을 호출했는데, 장애가 시작되고 9시간 19분 뒤였다. 둘째 장애도 Heroku Support 의 에스컬레이션과 고객 지원 티켓으로 알았다."},"components":["database","telemetry-agent"],"root_cause":"software-bug","remediation":[{"text":{"en":"Allocated more resources and restarted the Postgres clusters, which fixed the first outage temporarily","ko":"첫 장애 때 자원을 더 배정하고 Heroku Postgres 클러스터를 재시작해 7월 28일 14:16 UTC 에 문제를 일시적으로 풀었다."}},{"text":{"en":"Provisioned the previous version of the third-party monitoring software, which did not leak memory","ko":"둘째 장애 때 문제가 없는 제3자 서비스의 이전 버전을 프로비저닝하는 우회책을 적용했다. Postgres 데이터베이스 클러스터를 이전 안정 버전으로 바꾸자 메모리가 회수되어 클러스터가 건강한 상태로 돌아왔다."}},{"text":{"en":"The vendor applied an interim mitigation","ko":"제3자 업체가 임시 완화책을 적용했다."}}],"action_items":[{"text":{"en":"Add enhanced metrics collection for the third-party monitoring software","ko":"제3자 모니터링의 지표 수집을 강화했다."}},{"text":{"en":"Evaluate the vendor's fixed release of the monitoring software and roll it out if acceptable","ko":"제3자 업체가 메모리 누수를 고친 모니터링 소프트웨어 새 버전을 내면, 기술 팀이 그 버전을 평가하고 괜찮으면 Heroku 고객에게 내보낸다."}}],"contributing":["monitoring-blind-spot"],"recurrence_of":null,"symptoms_text":{"en":"From 22:31 UTC on 27 July 2024, 33 Heroku Postgres clusters in the EU (Dublin) region could not serve requests and ran into memory problems, and some Essential-tier customers could not connect to their databases. Customers trying to reach an affected database received out of memory errors.\n\nHeroku Support paged the technology team with customer support tickets at 07:50 UTC on 28 July; at that point 33 databases were inaccessible or out of memory. Adding resources and restarting the clusters brought them back by 14:16 UTC on 28 July, but the problem returned on 30 July, when Heroku Support escalated it to the technology team at 06:04 UTC.","ko":"EU/Dublin 리전에 있는 Heroku Postgres Essential 등급 고객 일부가 데이터베이스에 연결하지 못했다. 상태 페이지는 영향받은 고객이 데이터베이스에 접근하면 out of memory 오류를 받는다고 알렸다.\n\n2024년 7월 27일 22:31 UTC 부터 Heroku Postgres 클러스터 33개가 요청을 처리하지 못했다. 처음에는 접근할 수 없거나 메모리가 바닥난 데이터베이스가 33개였다. 클러스터의 쓸 수 있는 메모리가 계속 줄다가 결국 접근할 수 없게 됐다.\n\n첫 장애는 고객 지원 티켓으로 드러났고, Heroku Support 가 7월 28일 07:50 UTC 에 기술 팀을 호출했다. 기술 팀은 자원을 더 배정하고 클러스터를 재시작해 14:16 UTC 에 문제를 일시적으로 풀었다.\n\n같은 문제가 7월 30일에 다시 났다. 사후 보고는 06:04 UTC 에 기술 팀이 Heroku Support 의 에스컬레이션을 받으며 둘째 장애가 시작됐다고 적었다. 같은 보고는 16:47 UTC 에 둘째 발생을 알리는 고객 지원 티켓이 들어오기 시작했다고도 적었다. 상태 페이지는 16:59 UTC 에 문제를 알렸다."},"updated_at":"2026-11-14T12:34:02.542251Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0373","org_slug":"heroku"}