Intercom: Leere Database Routing Map verursacht vollständigen US-Serviceausfall

Am 9. Januar 2026 erlebte Intercom einen kritischen Ausfall in der US-Hosting-Region, der etwa 71 Minuten dauerte. Der Incident führte zu einer vollständigen Nichtverfügbarkeit des Service und verhinderte, dass Kunden auf die Intercom Inbox, den Messenger und APIs zugreifen konnten. Die Ursache war ein Software-Bug innerhalb des Database Routing Layers (Vitess/PlanetScale), der fälschlicherweise eine leere Routing-Konfiguration (VSchema) anwandte und so die Anwendung effektiv von ihren Daten-Shards trennte.

Unternehmen und Produkt

Intercom ist eine führende AI-first Kundenservice-Plattform, die Unternehmen Tools für Chat, Support-Automatisierung und Customer Engagement bietet. Mit über 25.000 Kunden:innen verarbeitet Intercom massive Mengen an Echtzeitdaten, um Instant Messaging und Support-Workflows zu unterstützen.

‍

Um diese Skalierung zu bewältigen, nutzt Intercom PlanetScale – eine Datenbank-Plattform basierend auf Vitess, einem Open-Source-Datenbank-Clustering-System für die horizontale Skalierung von MySQL. Dieser Aufbau erlaubt es Intercom, Daten über viele Datenbank-Knoten (Shards) zu verteilen, wobei ein „VSchema“ (Routing-Map) der Anwendung genau mitteilt, wo sich spezifische Kundendaten befinden.

Was passiert ist

Der Ausfall wurde während einer Standard-Administrationsmaßnahme zum Verschieben von Tabellen für Testzwecke ausgelöst. Unter normalen Umständen ist dies eine sichere Routineaufgabe. Eine Logik-Regression in einer kürzlich bereitgestellten Version von Vitess (v22) änderte jedoch grundlegend die Art und Weise, wie das System mit fehlgeschlagenen Operationen umging.

‍

Als der Befehl zum Verschieben der Tabellen aufgrund flüchtiger Netzwerkprobleme fehlschlug, wurde die Vitess-Rollback-Logik ausgelöst. Bei Sharded Keyspaces entschied das System fälschlicherweise, dass es eine „vorherige“ Routing-Map erneut anwenden müsse, die es jedoch gar nicht gespeichert hatte. Infolgedessen wurde ein leeres VSchema auf die Produktionsumgebung angewendet. Ohne eine gültige Map konnte der Datenbank-Proxy-Layer (VTGates) Abfragen nicht mehr an die richtigen Shards weiterleiten. Die Anwendung blieb zwar online, konnte aber keine Datenbank-Operationen mehr ausführen, was zu einem Totalausfall aller Intercom-Services in den USA führte.

Timeline

• Wann begann der Incident? 9. Januar 2026, 19:39 UTC.
• Wie wurde der Incident erkannt und eskaliert? Um 19:40 UTC lösten „Inbox Heartbeat“-Anomalie-Alarme aus, die die Ingenieure im Bereitschaftsdienst und einen Incident Commander innerhalb von 60 Sekunden nach Eintreten der Auswirkungen alarmierten.
• Wann wurde der Incident behoben? 20:50 UTC, nachdem PlanetScale-Ingenieure manuell einen gültigen VSchema-Snapshot eingespielt hatten.

‍

TTD (Time to Detect): 1 Minute.

TTR (Time to Resolve): 71 minutes.

Wer war betroffen?

Alle Kunden:innen und Endnutzer:innen in der US-Region von Intercom waren betroffen. Dies umfasste die Unfähigkeit, Nachrichten zu senden oder zu empfangen, Help Center zu laden oder die Intercom API zu nutzen. Kunden:innen in anderen Regionen (z. B. Europa/Australien) wurden davon nicht beeinflusst.

Wie Intercom reagierte

Das Engineering-Team von Intercom nahm sofort Kontakt mit PlanetScale auf, um den Data Layer zu untersuchen. Sobald identifiziert wurde, dass die Routing-Map gelöscht worden war, arbeiteten die PlanetScale-Ingenieure daran, einen VSchema-Snapshot von einer Stunde vor dem Incident einzuspielen. Sobald die gültige Konfiguration an die Proxy-Flotte verteilt war, wurde die Konnektivität sofort wiederhergestellt. Nach der Wiederherstellung leitete Intercom einen Rollback der gesamten Datenbank-Infrastruktur auf die vorherige stabile Version (v21) ein, um eine Wiederholung zu verhindern.

Wie Intercom kommunizierte

Intercom pflegte eine aktive Kommunikation über die Statusseite des Unternehmens. Innerhalb von 24 Stunden nach dem Incident veröffentlichten sie einen hochgradig transparenten technischen Bericht, der den spezifischen Vitess Pull Request detailliert beschrieb, der die Regression verursacht hatte, sowie ihren Plan zur Härtung der Topologie-Resilienz.

Wichtige Erkenntnisse für andere Teams

• Rollback-Logik validieren: In komplexen Sharded-Systemen kann ein „sicherer“ Rollback gefährlicher sein als der ursprüngliche Fehler. Stellen Sie sicher, dass „Undo“-Operationen genauso streng getestet werden wie „Do“-Operationen.
• Schema-Integritätsprüfungen: Implementieren Sie Schutzmaßnahmen, um das Anwenden von „leeren“ oder radikal veränderten Routing-Maps in der Produktion zu verhindern. Eine Prüfung auf eine „minimale gültige Größe“ für ein VSchema hätte diese Verteilung verhindern können.
• Explizite Upgrade-Trigger: Intercom stellte fest, dass eine separate Wartungsaktion (Branch Unfreezing) unbeabsichtigt ein ausstehendes Versions-Upgrade auslöste. Infrastructure Pipelines sollten für Major-Versionsänderungen eine explizite Bestätigung erfordern.

Zusammenfassung

Ein Logikfehler in Vitess v22 führte dazu, dass die Datenbank-Routing-Map von Intercom während einer fehlgeschlagenen Routineaufgabe mit einer leeren Konfiguration überschrieben wurde. Dies führte zu einem 71-minütigen totalen US-Ausfall. Der Service wurde durch das manuelle Einspielen eines VSchema-Snapshots wiederhergestellt.

Wie ilert helfen kann

Infrastrukturausfälle auf Datenbankebene erfordern eine schnelle Erkennung und koordinierte Reaktion. ilert hilft Teams bei der Bewältigung solcher SEV-1 Events durch:

‍

• Heartbeat Monitore: Nutzen Sie Heartbeat-Checks, um sicherzustellen, dass Kernkomponenten (wie der „Inbox Heartbeat“ von Intercom) aktiv Daten verarbeiten.
• Bereitschaftseskalation: Alarmieren Sie automatisch die richtigen Datenbank- und SRE-Teams via Voice, SMS oder Chat, wenn regionale Anomalien erkannt werden.‍
• Incident Postmortems: Nutzen Sie die Postmortems-Funktionen von ilert, um diese technischen Deep-Dives zu dokumentieren und wichtige Erkenntnisse mit Ihrer Organisation zu teilen.