Abrechnung in Euro aus Deutschland. Weitere Sprachen und Währungen sind derzeit nicht verfügbar.
Systemstatus
Diese Seite wurde aus derselben Messung gespeist, die bei ENTRONYX CLOUD auch über SLA-Gutschriften entscheidet — das SLA ist unsere Verfügbarkeitszusage. Wir veröffentlichen hier auch Werte, die uns Geld kosten. Ein Vorfall ist eine Störung, die wir öffentlich führen. Er erscheint, sobald drei unabhängige Prüfpunkte eine Abweichung melden.
Jeder Zustand wird mit Symbol und Wortlaut ausgewiesen, nicht allein über Farbe. Ein Balken im Verfügbarkeitsband entspricht einem Tag; seine Höhe sinkt mit dem Schweregrad.
2 von 6 Diensten weichen vom Normalbetrieb ab, 1 von 5 Standorten sind betroffen. Details je Dienst weiter unten.
4 betriebsbereit · 1 auffällig
Normalbetrieb
Block Storage: erhöhte Schreiblatenz auf Pool 3 und 7
Normalbetrieb
Normalbetrieb · Kühlkreis 2 seit 06:12 im Handbetrieb, ohne Auswirkung
Normalbetrieb
Gemessen von 14 externen Prüfpunkten außerhalb unseres Netzes. Ein Tag gilt als gestört, sobald mindestens drei Prüfpunkte gleichzeitig eine Abweichung melden.
Bare Metal, Cloud-Instanzen, GPU-Knoten, Kubernetes-Worker
Alle Hypervisor-Cluster im Sollbereich. Kein Provisionierungsstau.
Object Storage, Block Storage, Backup-Ziele, Cold Archive
fra2: erhöhte Schreiblatenz auf zwei Block-Storage-Pools nach Austausch eines Controllers. Lesepfad unbeeinträchtigt.
Backbone, Transit, Peering, vRack, DDoS-Filter
18,4 Tbit/s Kapazität, Spitzenlast bei 41 %. Alle Ringe geschlossen.
api.entronyx.cloud, S3-Endpunkte, Terraform-Provider
P95 der Antwortzeit bei 118 ms über alle Endpunkte.
Weboberfläche, Abrechnung, Ticketsystem, Zwei-Faktor-Anmeldung
Wartungsfenster: Umstellung der Rechnungsansicht auf die neue Belegarchiv-API. Anmeldung und Ticketsystem laufen.
Autoritative Zonen, Resolver, Reverse-DNS
12 Anycast-Standorte erreichbar. Kein Standort aus dem Verbund genommen.
Ein Balken je Tag. Die Höhe des Balkens sinkt mit dem Schweregrad — die Aussage hängt nicht allein an der Farbe.
Angekündigt
Ein Wartungsfenster ist ein vorher angekündigter Zeitraum, in dem wir an einer Anlage arbeiten. Arbeiten ohne erwartete Unterbrechung kündigen wir fünf Kalendertage vorher an, Arbeiten mit erwarteter Unterbrechung 14 Tage vorher. Einzelne Fenster an Ihren dedizierten Ressourcen — Anlagen, die nur Sie nutzen — verschieben wir auf Wunsch um bis zu 14 Tage.
02.09.2026, 02:00–04:00 MESZ
Kundenpanel · alle Regionen
Das Belegarchiv wird auf einen eigenen Dienst mit Volltextsuche über alle Rechnungen und Gutschriften umgestellt. Die Migration umfasst 4,1 Mio. Belege.
Erwartete Auswirkung: Rechnungsansicht und PDF-Download sind bis zu 40 Minuten nicht erreichbar. API, Compute, Netzwerk und Storage sind nicht betroffen.
09.09.2026, 01:00–05:00 MESZ
hel1 · Brandabschnitt A
Vorgeschriebene Prüfung nach EN 50600 mit vollständiger Lastübernahme durch die Netzersatzanlage. Die USV überbrückt den Umschaltvorgang.
Erwartete Auswirkung: Keine erwartete Auswirkung auf laufende Systeme. Server mit nur einem angeschlossenen Netzteil sind während der Umschaltung theoretisch gefährdet — betroffene Kunden wurden einzeln informiert.
16.09.2026, 23:00 – 17.09.2026, 03:00 MESZ
Backbone · Nordstrecke (hel1 ↔ ber1 ↔ fra1)
Einbau zusätzlicher Transponder und Umschaltung der Wellenlängen. Der Ring wird dafür einseitig geöffnet, der Verkehr läuft über die Gegenrichtung.
Erwartete Auswirkung: Latenz zwischen hel1 und fra1 steigt für die Dauer des Fensters um bis zu 9 ms. Kein Paketverlust erwartet, keine Unterbrechung.
Vorfallchronik
Jeder Eintrag nennt zuerst die betroffene Zone — den Bereich, in dem die Störung blieb, also einen Standort, einen Dienst oder eine Transitstrecke, das heißt eine Verbindung in ein fremdes Netz. Danach folgen Zeitleiste, Auswirkung, Ursache, Behebung und die Frage, ob eine Gutschrift ausgelöst wurde. Wir schreiben die Chronik so, wie wir sie intern führen — inklusive der Stellen, an denen wir selbst der Grund für die Verzögerung waren.
fra2 · Block Storage Pool 3, 7 und 11 · rund 2.900 Volumes
Schreibvorgänge auf den betroffenen Pools erreichten Latenzen bis 4.200 ms, in der Spitze liefen Datenbank-Transaktionen in die Zeitüberschreitung. Lesezugriffe blieben durchgängig unter 3 ms. Kein Datenverlust: der Journal-Layer hat alle bestätigten Schreibvorgänge gehalten, die Prüfsummenläufe nach der Behebung waren fehlerfrei.
Ein Firmware-Update auf 96 NVMe-Regalen aktivierte eine Hintergrund-Garbage-Collection, deren Standardparameter für unsere Schreibprofile zu aggressiv gesetzt sind. Der Hersteller hat die Änderung im Release-Hinweis nicht als verhaltensrelevant markiert; unsere Vorprüfung im Labor lief mit einem Lastprofil, das die Bedingung nicht ausgelöst hat.
Rücknahme der Firmware auf allen betroffenen Regalen in Wellen zu je 8 Regalen, danach kontrollierter Rebuild der Pools. Ab 19:40 lagen die Latenzen wieder unter 12 ms, bis 21:52 waren alle Rebuilds abgeschlossen.
Ehrliche Nachbetrachtung: Zwei Dinge sind hier schiefgelaufen, die nichts mit dem Hersteller zu tun haben. Erstens hatten wir für Storage-Firmware keinen Canary-Ring — der Rollout ging in einem Schritt auf die gesamte Pool-Gruppe. Seit dem 18.08. laufen Firmware-Änderungen über einen Canary von 4 % der Regale mit 72 Stunden Beobachtung. Zweitens haben wir diesen Vorfall erst um 14:48 auf der Statusseite geführt, 41 Minuten nach der ersten internen Alarmierung; Kunden haben in dieser Zeit Tickets geschrieben und keine Antwort bekommen. Die Schwelle für einen Statuseintrag liegt jetzt bei 10 Minuten bestätigter Abweichung und wird automatisch aus der Alarmierung ausgelöst, nicht mehr manuell entschieden.
Gutschrift von 25 % der Monatsgebühr für alle betroffenen Volumes wurde ohne Antrag auf der Rechnung 09/2026 erteilt.
Alarm: P99-Schreiblatenz Pool 3 überschreitet 500 ms.
Statuseintrag veröffentlicht, Ursache noch unklar.
Zusammenhang mit dem Firmware-Rollout bestätigt, Rollout gestoppt.
Beginn der Rücknahme, erste Welle von 8 Regalen.
Latenzen wieder im Normbereich, Rebuild läuft.
Alle Pools synchron, Vorfall geschlossen.
hel1 · ausgehender Transit über einen von vier Upstreams
Für Ziele, die über diesen Upstream erreicht wurden, lag der Paketverlust zwischen 4 % und 11 %. Betroffen waren überwiegend Ziele im Baltikum und in Nordeuropa. Verkehr innerhalb des ENTRONYX-Backbones sowie über DE-CIX, BCIX und FICIX war zu keinem Zeitpunkt betroffen.
Der Upstream hat eine angekündigte Wartung an einem Linecard-Chassis früher begonnen als kommuniziert. Die BGP-Sitzung flappte statt sauber abzubauen, wodurch unsere Route-Selection zwölf Minuten lang zwischen zwei Pfaden pendelte.
Manuelles Herabsetzen der Local Preference für den betroffenen Upstream, Umleitung auf die verbleibenden drei Transitverträge. Der Verkehr lief anschließend ohne Verlust; die Sitzung wurde am 03.07. um 11:00 kontrolliert zurückgenommen.
Die Route-Selection dämpft Sitzungen jetzt automatisch, wenn innerhalb von fünf Minuten mehr als zwei Zustandswechsel auftreten (BGP Damping mit angepassten Schwellwerten).
Unterhalb der Gutschriftschwelle: Die Netzverfügbarkeit lag im Juli bei 99,994 % und damit über dem zugesagten Wert.
Synthetische Messpunkte melden Verlust auf Pfaden über AS-Pfad 3.
Statuseintrag veröffentlicht.
Local Preference gesenkt, Verkehr wird umgeleitet.
Messpunkte wieder grün, Vorfall geschlossen.
api.entronyx.cloud · alle Regionen · POST, PUT, PATCH, DELETE
Sämtliche schreibenden API-Aufrufe wurden mit HTTP 502 beantwortet. Lesende Aufrufe und der S3-Datenpfad blieben verfügbar. Das Kundenpanel zeigte in der Folge leere Ressourcenlisten, weil es beim Laden auf einen schreibenden Session-Endpunkt zugreift. Bestehende Instanzen, Netzwerke und Storage liefen unverändert weiter — betroffen war ausschließlich die Steuerungsebene.
Eine Konfigurationsänderung am Ratelimiter wurde mit einem Schwellwert von 0 statt 3.000 Anfragen pro Minute ausgerollt. Die Änderung passierte die Prüfung, weil unser Schema den Wert 0 als „unbegrenzt“ interpretiert hat, der Limiter selbst aber als „nichts erlaubt“.
Rücknahme der Konfiguration über den vorherigen Revisionsstand. Die Wiederherstellung dauerte 90 Sekunden ab Erkennung der Ursache.
Das Konfigurationsschema kennt kein 0 mehr; unbegrenzt wird explizit als null geführt. Zusätzlich gilt für die Steuerungsebene seit dem 25.06. ein Progressive Rollout über drei Ringe mit automatischem Abbruch bei einer Fehlerrate über 1 %.
14 Minuten entsprechen im Juni 99,968 % API-Verfügbarkeit. Der Wert liegt über der Zusage von 99,95 %, eine Gutschrift ist daher nicht ausgelöst worden.
Fehlerrate der Schreibendpunkte springt auf 100 %.
Statuseintrag veröffentlicht, Steuerungsebene betroffen.
Ursache identifiziert, Rücknahme gestartet.
Fehlerrate zurück auf Grundrauschen, Vorfall geschlossen.
Autoritatives DNS · 11 von 12 Anycast-Standorten
Änderungen an DNS-Einträgen wurden an elf Standorten mit bis zu 40 Minuten Verzögerung übernommen. Bestehende Einträge wurden durchgehend korrekt beantwortet, es gab keine NXDOMAIN-Antworten und keine Signaturfehler.
Beim planmäßigen Wechsel des Zone Signing Key lief die Neusignierung von 61.000 Zonen auf denselben Knoten wie der Transferdienst. Die CPU-Sättigung hat die Transfers ausgebremst.
Signierung auf dedizierte Knoten verlagert und der Wechsel in Chargen zu 5.000 Zonen fortgesetzt.
Keine Gutschrift: Die Namensauflösung selbst war zu keinem Zeitpunkt gestört.
Transferverzögerung an elf Standorten festgestellt.
Statuseintrag veröffentlicht.
Signierung auf separate Knoten verlagert.
Alle Standorte synchron, Vorfall geschlossen.
Ältere Vorfälle bewahren wir 36 Monate auf und stellen sie auf Anfrage zur Verfügung. Vorfälle mit Sicherheitsbezug erscheinen nicht in dieser öffentlichen Chronik; betroffene Kunden werden nach dem Verfahren aus Sicherheit und Compliance direkt unterrichtet.
Benachrichtigung
Sie können sich über neue Vorfälle und geplante Wartung unterrichten lassen — wahlweise für alle Dienste oder nur für die Standorte und Produkte, die Sie tatsächlich nutzen. Die Auswahl treffen Sie im Kundenpanel unter „Benachrichtigungen“.
Für Vorfälle der Stufe „kritisch“ versenden wir zusätzlich eine Nachricht an alle hinterlegten technischen Kontakte, unabhängig von den gewählten Einstellungen.
Atom-Feed — ein maschinenlesbarer Nachrichtenstrom — über alle Vorfälle und Wartungsfenster, filterbar nach Region und Dienst.
/status.atom
Ein Webhook ist ein automatischer Aufruf Ihrer Adresse (HTTP-POST) bei jeder Zustandsänderung. Der Nutzdatenteil ist mit HMAC-SHA256 signiert, damit Sie prüfen können, dass die Meldung von uns stammt.
Panel → Benachrichtigungen
Geplante Wartungsfenster als iCalendar-Abonnement — ein Kalender, den Ihr Team-Kalendersystem einbindet und laufend abruft.
/status.ics
Störung gefunden?
Bevor Sie ein Ticket schreiben: Diese Seite klärt, ob wir die Störung bereits kennen. Läuft bei uns alles im Sollbereich und bei Ihnen nicht, helfen Ressourcen-ID, Zeitstempel mit Zeitzone und ein Auszug aus dem Protokoll am meisten.
