Am 12. Juni 2025 kam es bei Supabase zu einem erheblichen Ausfall, der das gesamte Angebot der Plattform und vieler Dienste weltweit beeinträchtigte. Die zentrale Ursache wurde in der Infrastruktur eines der wichtigsten Upstream-Anbieter gefunden, wodurch die Verfügbarkeit von HTTP- und WebSocket-Endpunkten massiv eingeschränkt wurde. Dieser Vorfall ist von großer Bedeutung für Nutzer und Unternehmen, die auf Supabase als Backend- und Entwicklungsplattform vertrauen, und bietet wichtige Erkenntnisse zur Resilienz moderner Cloud-basierter Systeme. Der Ausfall begann gegen 18:05 Uhr UTC und endete etwa um 20:30 Uhr UTC, dauerte also rund zweieinhalb Stunden. Während dieser Zeit erlebten Supabase-Anwender weltweit eine stark eingeschränkte Funktionalität bei Zugriffen über die API-Gateway-Komponente, die für das Routing von HTTP- und WebSocket-Verkehr verantwortlich ist.
Besonders betroffen waren zentrale Dienste wie Authentifizierung, Storage, Edge Functions, Daten-APIs und teilweise auch die Dashboard-Bedienoberfläche. Zusammen mit einer Beeinträchtigung der Realtime-Verbindungen und eingeschränkter Logging- sowie Observability-Fähigkeiten führte dies zu einem spürbaren Qualitätseinbruch. Interessanterweise waren direkte Zugriffe auf PostgreSQL-Datenbanken und Connection-Pooler von diesem Vorfall nicht betroffen und konnten weiterhin stabil genutzt werden. Der technische Auslöser für den Zwischenfall liegt in einer Fehlfunktion des Cloud-Providers Cloudflare, der für viele der internen Routing- und Proxy-Aufgaben von Supabase zuständig ist. Insbesondere gab es einen Bug in der Worker KV Storage Infrastruktur, einer verteilten Schlüssel-Wert-Datenbank, die eine wichtige Rolle beim reibungslosen Betrieb von Cloudflare-Services spielt.
Das Versagen dieser Schlüsselkomponente führte zu einem Kaskadeneffekt, der zahlreiche Services blockierte und somit das API Gateway quasi lahmlegte. Da das Gateway als zentraler Einstiegspunkt für den überwiegenden Teil des HTTP- und WebSocket-Verkehrs fungiert, führte dies zu einer weitreichenden Degradierung der gesamten Plattform. Zu Beginn der Störung wurde intern bereits um 18:17 Uhr UTC ein Alarm ausgelöst, der auf die deutlichen Verzögerungen und Fehler in WebSocket und HTTP-Verbindungen hinwies. Kurz darauf, um 18:28 Uhr UTC, wurde der Incident offiziell erklärt. Die Supabase-Teams stellten fest, dass selbst der Zugriff auf das Provider-Dashboard zu diesem Zeitpunkt nicht möglich war, was eine direkte Fehleranalyse erschwerte. Ein Support-Ticket wurde unverzüglich geöffnet, um gemeinsam mit dem Anbieter die Ursache zu identifizieren und eine Schätzung zur Behebung zu erhalten. Die Entwicklungen in den folgenden Stunden waren geprägt von vielen Herausforderungen.
Die Management-API von Supabase, welche interne Verwaltungsfunktionen steuert, zeigte globale Timeouts. Besonders belastend war die Zeit zwischen 18:45 und 19:05 Uhr UTC, in der ein erhöhtes Anfrageaufkommen durch wiederholte Verbindungsversuche die interne Middleware-Datenbank teilweise beeinträchtigte. Um dem entgegenzuwirken, wurden Sofortmaßnahmen ergriffen, um die Stabilität wiederherzustellen. Unterstützend wurde außerdem ein sogenannter Bypass-Proxy versucht, um das Gateway vorübergehend umgehen zu können, jedoch lieferte diese Maßnahme nur begrenzte Verbesserungen. Ab etwa 20:09 Uhr UTC begannen die Systeme des Upstream-Providers sich zu erholen, was eine schrittweise Rückkehr zu stabilen Verbindungen ermöglichte. Innerhalb von 20 Minuten konnten die Teams bei Supabase wiederholen, was während der Ausfallzeit nicht ausgeführt werden konnte, und kontrollierten den gesamten Plattformbetrieb auf etwaige Restprobleme.
Um 20:30 Uhr wurden die Dienste langsam wieder stabil, und nach sorgfältiger Prüfung wurde schließlich um 21:18 Uhr der Status „Monitoring“ gesetzt – ein Indikator dafür, dass zwar die Dienste wieder liefen, die Situation aber weiterhin beobachtet wurde. Um 22:05 Uhr folgte die finale Schließung des Incidents mit der Bestätigung der vollständigen Wiederherstellung. Der Vorfall zeigte deutlich auf, wie stark Supabase noch von der Infrastruktur des Cloudflare-Providers abhängig ist und wie eine Schwachstelle in dieser einen großen Teil der eigenen Dienstleistung beeinträchtigen kann. Die Blackbox-Funktionalität externer Cloud-Elemente birgt dabei besondere Risiken, die auch große, dezentrale Systeme betreffen können. Im Fall von Supabase führte dies zu einem unerwarteten Totalausfall zentraler Komponenten, obwohl nicht alle Teile des Systems gleich betroffen waren. Die Learnings aus diesem Vorfall sind vielfältig.
Zum einen beabsichtigt Supabase, kritische Dienste künftig von solchen Single Points of Failure zu entkoppeln und eine Migration auf resilientere, ggf. multi-provider-basierte Architekturen voranzutreiben. Die API-Gateway-Struktur selbst soll neu gestaltet werden, um eine stärkere Isolation und Fehlerresistenz zu gewährleisten. Weiterhin plant das Unternehmen, die Logging- und Überwachungssysteme so zu verbessern, dass sie auch während Ausfällen von Upstream-Systemen möglichst zuverlässig Informationen liefern und Warnungen generieren können. Ein besonderer Schwerpunkt wird auch auf der internen Kommunikation während Vorfällen liegen. Supabase möchte die kommunikative Transparenz nach außen und innerhalb der Teams verbessern, um schneller und präziser Informationen weiterzugeben. Außerdem sollen engere und frühere Kommunikationskanäle mit Upstream-Providern etabliert werden, sodass kritische Probleme künftig zeitnaher erkannt und adressiert werden können.
Spezielle Circuit Breaker und Alerting-Mechanismen für sogenannte Management-APIs und andere sensible Bereiche werden justiert, um übermäßige Last und mögliche Folgeausfälle zu vermeiden. Für die Nutzer des Dienstes bedeutet dies, dass für sie aktuell keinerlei Maßnahmen erforderlich sind, da der Vorfall vollständig behoben wurde und alle Services wieder normal laufen. Dennoch ist es für Entwickler und Unternehmen, die auf Supabase vertrauen, wichtig, solche Ereignisse zu kennen und für den Ernstfall entsprechende Notfallpläne und Monitoring-Systeme zu implementieren. Eine Diversifizierung der Abhängigkeiten sowie eine sorgfältige Prüfung kritischer Systemkomponenten können dazu beitragen, Risiken zu minimieren. In der Gesamtschau präsentiert sich der Supabase-Ausfall am 12. Juni 2025 als exemplarisches Szenario für moderne Cloud-Infrastrukturen, die zunehmend komplex und verflochten sind.
Die Abhängigkeit von externen Cloud-Lösungen bringt sowohl enorme Vorteile in Skalierbarkeit und Flexibilität als auch potenzielle Risiken durch zentrale Ausfallpunkte mit sich. Die Herausforderung besteht darin, diese Dienste so zu orchestrieren, dass sie auch im Fall von Upstream-Problemen belastbar bleiben und die Verfügbarkeit für Endbenutzer möglichst wenig leiden muss. Supabase hat sich nach dem Vorfall klar zu einer langfristigen Strategie bekannt, um diese Fragilität zu reduzieren. Neben der technologischen Weiterentwicklung und Systemoptimierung soll auch die Partnerschaft mit Cloud-Anbietern intensiver gestaltet werden, um künftig proaktiv auf mögliche Fehlerquellen reagieren zu können. Dadurch wird das Unternehmen seine Plattform dauerhaft robuster gestalten und das Vertrauen der weltweiten Entwickler-Community erhalten.
Der offene Umgang mit diesem Vorfall und die ausführliche Berichterstattung helfen dabei, die Transparenz gegenüber den Nutzern zu erhöhen und den Blick auf notwendige Infrastrukturverbesserungen zu lenken. Sie zeigen auch, wie entscheidend es ist, Cloud-basierte Services ganzheitlich zu verstehen und kontinuierlich weiterzuentwickeln – nicht nur aus technischer, sondern auch aus organisatorischer Perspektive. Insgesamt überzeugt Supabase durch den professionellen Umgang mit einer komplexen Krisensituation und legt wichtige Grundlagen für eine zukunftsfähige, ausfallsichere Entwicklungsplattform. Anwender profitieren von der konsequenten Umsetzung der Lessons Learned und können sich auf eine stabilere Umgebung ihrer Cloud-Projekte und APIs freuen. Die Erfahrungen aus dem Juni 2025 werden dabei als wertvolle Referenz für die Gestaltung künftig zuverlässigerer Dienste dienen.
