{"id":"IL-0304","org":"Intercom","date":"2026-01-09","docs":[],"title":{"en":"Intercom's US region was fully down for 71 minutes when its Vitess VTGates dropped all routes to the database shards","ko":"Intercom US 리전에서 Vitess 의 라우팅 설정 VSchema 가 빈 값으로 덮여 서비스 전체가 71분 동안 멈췄다"},"domain":["database"],"impact":{"scope":"All Intercom services in the US region were unavailable for 71 minutes","users":"Intercom customers hosted in the US region","region":"US"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://www.finstatus.com/us-hosting/incidents/01KEJ5AZFPGWKRV57MMEAR9M0W/write-up","kind":"official-status","archived":null}],"summary":{"en":"Intercom uses PlanetScale, built on Vitess, as its core database layer. At 18:56 UTC on January 9, 2026, a configuration in the database management pipeline read a 'branch unfreeze' action as a signal to go ahead with a pending upgrade to Vitess v22 that was scheduled for the following week, and the upgrade began rolling out at 19:00 UTC. At 19:30 UTC a MoveTables workflow, part of a standard administrative task to move tables for testing, failed because of transient networking issues in the provider's Kubernetes cluster.\n\nWhen a MoveTables command fails, Vitess attempts to revert its state. For unsharded keyspaces it keeps the previous VSchema in memory for this rollback, and for sharded keyspaces it saves nothing, because the operation is not expected to change the VSchema there. A regression in v22, introduced in Vitess Pull Request #17401, made the check for whether to reapply the old VSchema come out true for Intercom's sharded keyspace, so Vitess applied a previous VSchema it had never saved, which was empty. At 19:39 UTC the PlanetScale control plane read the empty VSchema and passed it to the VTGates, which dropped all routes.\n\nEngineers and an incident commander acknowledged the incident at 19:41 UTC and engaged PlanetScale at 19:48 UTC. At 20:50 UTC PlanetScale engineers reapplied a VSchema snapshot taken one hour before the incident and removed what the failed workflow had left behind; the control plane pushed the valid routing rules to the VTGates, which rebuilt their routing tables, and service recovered. From 21:00 UTC Vitess was rolled back to v21 over the following hours. Intercom found no evidence of data loss or corruption. The networking packet drops in the provider's Kubernetes cluster may have contributed by causing the workflow failure that set off the bug.","ko":"Intercom 은 Vitess 위에 만든 PlanetScale 을 핵심 데이터베이스 계층으로 쓴다. 2026년 1월 9일 18:56 UTC 에 데이터베이스 관리 파이프라인의 한 설정 때문에 'branch unfreeze' 동작이 다음 주로 잡혀 있던 v22 버전 업그레이드를 진행하라는 신호로 해석되었다. Intercom 은 이 동작이 의도한 것이 아니었다고 밝혔다. 19:00 UTC 에 버그가 있는 Vitess v22 업그레이드가 배포되기 시작했다.\n\n19:30 UTC 에 테스트용으로 테이블을 옮기는 MoveTables workflow 를 만들었고, 제공업체 Kubernetes 클러스터의 일시적인 네트워크 문제로 이 명령이 실패했다. MoveTables 가 실패하면 Vitess 는 상태를 되돌리려 한다. 샤딩되지 않은 keyspace 에서는 이전 VSchema 를 메모리에 담아 두지만, 샤딩된 keyspace 에서는 이 작업 중에 VSchema 가 바뀔 일이 없다고 보고 이전 상태를 남기지 않는다. 그런데 Vitess Pull Request #17401 로 v22 에 들어간 회귀 버그 때문에, 샤딩된 keyspace 에서도 이전 VSchema 를 다시 적용해야 한다는 조건이 참으로 판정되었다. 저장해 둔 적 없는 이전 VSchema 를 다시 적용하면서 운영 keyspace 토폴로지에 빈 값이 들어갔다.\n\n19:39 UTC 에 PlanetScale 컨트롤 플레인이 빈 VSchema 를 데이터베이스 프록시 계층인 VTGate 들에 전파했고, VTGate 들은 곧바로 모든 라우팅 경로를 버렸다. 쿼리를 올바른 샤드로 보내지 못해 US 리전의 Intercom 서비스 전체가 멈췄다. 20:50 UTC 에 PlanetScale 엔지니어가 장애 한 시간 전의 VSchema 스냅샷을 다시 적용하고 실패한 workflow 의 잔여물을 지웠다. 올바른 설정이 컨트롤 플레인을 거쳐 VTGate 들에 퍼지자 VTGate 들이 내부 라우팅 테이블을 다시 만들었고 서비스가 돌아왔다. 장애는 19:39 UTC 부터 20:50 UTC 까지 71분이었고, 고객 데이터가 사라지거나 손상된 증거는 없었다. 21:00 UTC 이후 Vitess 를 v21 로 롤백했다."},"trigger":{"en":"At 18:56 UTC a configuration in the database management pipeline treated a 'branch unfreeze' action as a signal to start a Vitess v22 upgrade planned for the following week. At 19:30 UTC a MoveTables workflow failed during transient networking issues in the provider's Kubernetes cluster, and the v22 rollback logic applied an empty VSchema.","ko":"테스트용으로 테이블을 옮기는 MoveTables 명령이 제공업체 Kubernetes 클러스터의 일시적인 네트워크 문제로 실패했다. 이 실패를 처리하는 과정에서 Vitess v22 의 롤백 로직 버그 때문에 운영 데이터베이스에 빈 VSchema 가 적용되었다."},"severity":"unknown","symptoms":["service-unavailable"],"timeline":{"detected_after":"1m","resolved_after":"1h 11m"},"date_kind":"incident","detection":{"en":"Inbox Heartbeat Anomaly alarms fired in the US region at 19:40 UTC and declared an incident; engineers and an incident commander acknowledged it at 19:41 UTC.","ko":"19:40 UTC 에 US 리전의 Inbox Heartbeat Anomaly 알람이 울려 장애가 선언되었다. 19:41 UTC 에 엔지니어들과 인시던트 커맨더가 장애를 확인하고 조사를 시작했다."},"components":["database","database-proxy"],"root_cause":"upgrade-breaking-change","remediation":[{"text":{"en":"PlanetScale engineers reapplied a VSchema snapshot from one hour before the incident","ko":"PlanetScale 엔지니어가 장애 한 시간 전에 찍어 둔 VSchema 스냅샷을 다시 적용해 라우팅 토폴로지를 되살렸다."}},{"text":{"en":"Removed the artifacts left behind by the failed MoveTables workflow","ko":"PlanetScale 엔지니어가 실패한 MoveTables workflow 가 남긴 잔여물을 지웠다."}},{"text":{"en":"Rolled Vitess back to v21","ko":"21:00 UTC 이후 Vitess 를 v21 로 롤백하기 시작했고, 그 뒤 몇 시간에 걸쳐 끝냈다."}}],"action_items":[{"text":{"en":"PlanetScale to deploy a fix for the Vitess v22 regression","ko":"PlanetScale 이 회귀를 일으킨 코드 경로를 찾았고 수정을 배포한다."}},{"text":{"en":"Pause further database upgrades for Intercom until the patch is verified","ko":"Vitess 수정 패치가 충분히 검증될 때까지 Intercom 인프라의 추가 데이터베이스 업그레이드를 멈춘다."}},{"text":{"en":"Find the source of the packet drops in the provider's Kubernetes networking","ko":"PlanetScale 이 장애 시작 때 Kubernetes 네트워크에서 패킷이 드롭된 원인을 찾는다."}},{"text":{"en":"Explore safeguards that protect the application from invalid topology updates","ko":"잘못된 토폴로지 갱신이 애플리케이션에 닿지 않게 막을 안전장치를 PlanetScale 과 함께 더 찾는다."}},{"text":{"en":"Review the pipeline configuration that let a branch unfreeze trigger a pending version upgrade","ko":"데이터베이스 'branch unfreeze' 가 대기 중이던 버전 업그레이드를 자동으로 시작하게 만든 파이프라인 설정을 PlanetScale 과 함께 검토한다."}},{"text":{"en":"Separate maintenance tasks from version upgrades more strictly so every deployment is intended","ko":"의도하지 않은 배포가 일어나지 않도록 유지보수 작업과 버전 업그레이드를 더 엄격하게 나눈다."}}],"contributing":["unpinned-version","overlapping-failures","automation-amplified"],"recurrence_of":null,"symptoms_text":{"en":"From 19:39 to 20:50 UTC on January 9, 2026, all Intercom services in the US region were unavailable to customers hosted there. Queries from the Intercom application could not reach the database shards, and Inbox Heartbeat Anomaly alarms fired in the US region at 19:40 UTC.\n\nIntercom's core database layer is PlanetScale, built on Vitess, and its proxy layer, the VTGates, routes each query to the right shard using the VSchema. An empty VSchema had been applied to the production keyspace, the PlanetScale control plane passed it to the VTGates, and the VTGates dropped all their routes, so the application lost all connectivity to its data. Queries could not be routed or run, but stored data was not changed.","ko":"2026년 1월 9일 19:40 UTC 에 US 리전의 Inbox Heartbeat Anomaly 알람이 울려 장애가 선언되었다. US 리전에 호스팅된 고객은 Intercom 서비스를 전혀 쓸 수 없었다.\n\n데이터베이스 프록시 계층인 VTGate 들이 빈 VSchema 를 받아들이자마자 모든 라우팅 경로를 버렸다. VSchema 는 샤딩된 데이터의 라우팅 정보를 담은 설정이고, VTGate 는 이 설정을 보고 쿼리를 올바른 샤드로 보낸다. 쿼리가 샤드에 닿지 못해 Intercom 애플리케이션과 데이터 계층 사이의 연결이 모두 끊겼다. 쿼리를 라우팅하고 실행하지 못했을 뿐, 저장된 데이터는 바뀌지 않았다.\n\n빈 VSchema 는 몇 단계를 거쳐 퍼졌다. 19:00 UTC 에 버그가 있는 Vitess v22 업그레이드가 배포되기 시작했다. 19:30 UTC 에 만든 MoveTables workflow 가 실패했고, v22 버그 때문에 이 실패를 처리하는 과정에서 빈 VSchema 가 토폴로지에 적용되었다. 19:39 UTC 에 PlanetScale 컨트롤 플레인이 빈 VSchema 를 읽어 VTGate 들에 전파하면서 운영 영향이 시작되었다.\n\n19:41 UTC 에 엔지니어들과 인시던트 커맨더가 장애를 확인하고 조사를 시작했고, 19:48 UTC 부터 PlanetScale 과 함께 조사했다."},"updated_at":"2026-11-14T12:33:55.812742Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0304","org_slug":"intercom"}