Der erste landesweite Code Rot. Für uns ein Nichtereignis – weil wir vorbereitet waren.

Zugangsdaten, auf die Sie nicht zugreifen können, sind Zugangsdaten, die Sie nicht haben. Für einen Tresor ist dauerhafte Erreichbarkeit – jederzeit, von überall – keine Funktion; sie ist die ganze Aufgabe.

Diese Woche haben die Niederlande erstmals landesweit „Code Rot" wegen extremer Hitze ausgerufen – ein 40-°C-Ereignis, das das Land seit Beginn der Aufzeichnungen im Jahr 1901 nicht erlebt hatte [1][2]. Bis Freitag war die Hitze bis zu der Ebene vorgedrungen, über die fast niemand nachdenkt, bis sie ausfällt: das Rechenzentrum. Unser Anbieter in Amsterdam, Leaseweb, hat genau das Richtige getan und uns früh gewarnt – die Einrichtung lief heiß, sie hatte begonnen, Teile der eigenen Infrastruktur abzuschalten, um Wärme abzuführen, und die Maschine, die wir dort betreiben, könnte die nächste sein. Wir haben nachgesehen: gesund, normal in Betrieb. Danach sind wir zurück an die Arbeit. Nicht weil wir sicher waren, dass Amsterdam durchhalten würde – sondern weil es das nicht muss.

Ein heißes Rechenzentrum in Amsterdam darf nicht unser Problem sein

Die Maschine in Amsterdam ist einer von zwei Ankerknoten in unserer Anmeldeverwaltung – dem Gehirn hinter den Kulissen, das unsere Flotte betreibt und koordiniert. Und vor allem anderen der entscheidende Punkt in einfacher Sprache: Das ist nicht der Tresor, der Ihre Zugangsdaten speichert und bereitstellt. Diese laufen auf einer vollständig getrennten, unabhängigen Ebene – einem völlig anderen globalen System –, das diese Hitze nie berührt hat. Das Verwaltungs-Gehirn und die Tresore, mit denen Ihre Agenten tatsächlich sprechen, sind zwei verschiedene Welten: Ein schlechter Tag für das eine ist schlicht kein schlechter Tag für das andere. Wir halten dieses Verwaltungs-Gehirn nur nach demselben Standard wie alles andere – nie ein Single Point of Failure. Deshalb gibt es zwei Ankerknoten, mit Absicht – einer in Amsterdam (Leaseweb), einer in Osaka (Ablenet). Zwei Kontinente. Zwei Anbieter. Zwei Stromnetze. Zwei Klimazonen. Ein 40-°C-Nachmittag in den Niederlanden hat keine physische Auswirkung auf eine Maschine in Japan: anderes Wetter, anderes Netz, gänzlich andere Fehlerdomäne. (Nebenbei: Während Amsterdam unter landesweitem Code Rot auf 40 °C stieg, lag Osaka mitten in der Regenzeit bei etwa 29 °C – elf Grad kühler, eine halbe Welt entfernt, in einem völlig unabhängigen Wettersystem. Dieser Abstand ist das Design.) Die beiden Ankerknoten laufen fortlaufend synchron, sodass keiner je weit hinter dem anderen zurückliegt. Wenn eine Hitzewelle, eine Netzstörung oder ein Anbieter-Vorfall Amsterdam offline nähme, ist der schlimmste Fall eine kurze, begrenzte Umschaltung auf die andere Seite des Planeten – kein Ausfall.

Ausfallsicherheit ist keine Funktion eines Zugangsdatentresors. Sie ist das Produkt.

Ein Zugangsdatentresor ist das tragendste Element eines Stacks: Jede App, jede Pipeline und jeder Agent authentifiziert sich darüber. Wenn er antwortet, funktioniert alles; wenn er es nicht kann, steht alles gleichzeitig still. Diese Asymmetrie ist der Grund, warum Ausfallsicherheit nichts ist, das man später nachrüstet. Sie wollen nicht am heißesten Tag seit einem Jahrhundert herausfinden, ob Ihr einziges Rechenzentrum, in Ihrer einzigen Stadt, an Ihrem einzigen Netz, die Hitze aushält. Sie entscheiden das an einem kühlen Tag, indem Sie es ablehnen, das Unternehmen auf ein einzelnes Klima zu setzen. Wir haben diese Entscheidung vor langer Zeit getroffen: Keine einzelne Region, kein einzelner Anbieter, kein einzelnes Netz und kein einzelnes Wettersystem darf je die ganze Geschichte sein.

Die ehrliche Version

Nichts macht Infrastruktur unverwundbar. Wetter fällt aus, Netze fallen aus, Anbieter fallen aus – und wer Ihnen etwas anderes erzählt, will Ihnen etwas verkaufen. Was Sie tatsächlich wählen können, ist, ob der Ausfall einer dieser Komponenten Sie mit herunterzieht. Wir haben zwei Hemisphären gewählt, damit die Antwort nein lautet. Diese Woche hat diese Entscheidung in denkbar wörtlichster Weise geprüft – und der Test war langweilig: Amsterdam hat durch die Hitze weiter bedient, und selbst wenn nicht, hätte das Design die Antwort bereits in Osaka bereitgehalten.

Bauen Sie für den Katastrophenfall an dem Tag, an dem er nicht eintritt

Das ist die ganze Disziplin. Der kühle Tag ist der, an dem Sie für den heißen bauen; der heiße Tag ist der, an dem Sie still froh sind, es getan zu haben. Diese Woche war ein heißer Tag – ein Rekordtag – und für uns war es ein Nichtereignis. Genau das soll es sein.

Das gebührende Lob: Leaseweb hat die Hitze so bewältigt, wie es gute Betreiber tun – frühe Warnung, schützende Maßnahmen, kein Drama. Die besten Anbieter melden sich, bevor es ein Problem gibt. Unsere Aufgabe ist nur sicherzustellen, dass ein schlechter Tag an einem Standort nie der einzige Standort war.

Clavitor (@clavitorai) ist der Zugangsdatentresor, gebaut für KI-Agenten – und gegen sie. clavitor.ai

Quellen

[1] NL Times — Dutch heatwave now official; historic Code Red hot-weather alert (first-ever national code red for extreme heat; longest June heatwave since records began in 1901): https://nltimes.nl/2026/06/25/dutch-heatwave-now-official-historic-code-red-hot-weather-alert-debated

[2] DutchReview — NL temperatures to reach up to 40 degrees (peak inland temperatures approaching 40°C): https://dutchreview.com/news/netherlands-up-to-40-degrees-then-plummet-to-21-degrees-25062026/