Störungsverlauf von Ionos Cloud

1. 4. September 2026 um 16:53 UTCinvestigating

   Während der telefonische support in der regel verfügbar sein wird, ist unsere kapazität aufgrund mehrerer fälle von krankenurlaub reduziert. Wir möchten Sie darüber informieren, dass unser Telefonsupport in den folgenden Zeitfenstern begrenzt ist, was zu erhöhten Reaktionszeiten auf dem Telefonkanal führt. In diesen Fällen erreichen Sie bitte per E-Mail. Vielen Dank.

2. 7. September 2026 um 06:16 UTCidentified

   Wir haben immer noch keine Abdeckung des Dienstes, und wir nehmen derzeit Änderungen an unserem Ticketing-System vor. Daher bitten wir um Ihr Verständnis, wenn Support-Antworten nicht so rechtzeitig sind, wie Sie es gewohnt sind. Vielen Dank.

3. 8. September 2026 um 06:31 UTCresolved

   Wir haben es geschafft, unseren Service vollständig wiederherzustellen, Support ist zurück. Vielen Dank für Ihre Geduld.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 1. September 2026 um 13:36 UTCidentified

   Für unsere Partner mit Unteraufträgen: Wir haben festgestellt, dass Subaufträge nicht auf den neuen Frankfurter Standort "de/fra/1" zugreifen können. Wir arbeiten derzeit an einem Fix, um dies verfügbar zu machen, Wir werden Sie informieren, wenn es fertig ist.

2. 1. September 2026 um 15:01 UTCmonitoring

   Wir können das Problem lösen, also die neue Region nur für alle Verträge verfügbar ist. Wir monitoren, ob es noch weitere Rückmeldungen gibt.

3. 1. September 2026 um 16:12 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 31. August 2026 um 15:35 UTCinvestigating

   Die DCD ist derzeit nicht verfügbar und zeigt eine endlose Seite "DCD laden ..." an. Wir untersuchen dieses Problem derzeit und werden Sie auf dem Laufenden halten.

2. 31. August 2026 um 15:52 UTCmonitoring

   Die DCD ist jetzt wieder verfügbar, und wir beobachten die Situation.

3. 31. August 2026 um 17:03 UTCresolved

   Wir markieren diesen Vorfall als gelöst. Unser Netzwerkteam untersucht negative Auswirkungen auf die IAM Services, die durch einen Change Rollout verursacht werden. Wir werden die Statusseite aktualisieren, sobald die Ursache festgestellt wurde.

4. 1. September 2026 um 15:32 UTCpostmortem

   # **Vorläufige Wurzelursachenanalyse ** Diese Wurzelursachenanalyse ist vorläufig, da noch Untersuchungen durchgeführt werden, um die technische Ursache des Vorfalls zu bestimmen. ## **Was ist passiert?** Am 31. August 2026, zwischen 15:00 UTC und 15:43 ITC und erneut zwischen 16:32 UTC und 16:35 UTC, konnten die Kunden den Identity and Access Management (IAM) Service von IONOS Cloud und den Data Center Designer (DCD) nicht erreichen, der von diesem Service abhängig ist. Die Störung betraf direkte Anmeldungen, den Zugang zum Partner- und Reseller-Portal und die zugehörigen Verwaltungskonsolen. Die Gesamtauswirkungen auf den Kunden dauerten in beiden Intervallen etwa 48 Minuten. Cloud-APIs \([api.ionos.com](http://api.ionos.com)\) blieben während des gesamten Vorfalls voll funktionsfähig. Die zugrunde liegenden Anwendungsdienste waren jederzeit gesund - der Fehler beschränkte sich auf die Netzwerkrandschicht. ## **Wie war das möglich? \(Wurzelursache\)** Während eines geplanten Wartungsfensters am 31. August 2026 wurde ein Netzwerkkonfigurationsupdate auf die Edge-Netzwerkinfrastruktur angewendet, um Routingfilter zu optimieren. Die Konfiguration wurde vor und während der Anwendung als korrekt verifiziert. Nach dem Rollout trat eine Routing-Ausbreitungsanomalie auf einem Edge-Netzwerk-Switch auf, was zu einem asymmetrischen Routing-Verhalten führte: eingehende TCP-Verbindungsanforderungen von Clients wurden stillschweigend am Netzwerkrand fallen gelassen, bevor sie den Anwendungscluster erreichten. Da die Anwendungsdienste selbst funktionstüchtig blieben, war dieser Fehlermodus durch interne Gesundheitschecks nicht sofort sichtbar - die Dienste wurden vom Empfang des eingehenden öffentlichen Internetverkehrs isoliert, anstatt zu scheitern. Die Ursache, warum dieser spezielle Switch nach einer ansonsten gültigen Konfigurationsänderung ein asymmetrisches Routingverhalten zeigte, wird weiterhin aktiv untersucht. Ob dies durch ein Switch-Plattform-Verhalten oder einen softwareversionsspezifischen Fehler ausgelöst wurde, wird durch Staging-Umgebungswiedergabe ermittelt. ## **Was tun wir, um eine Wiederholung zu verhindern?** ### ** Sofortige Maßnahmen** * **Konfiguration Rollback:** Bei der Identifizierung der Routing-Anomalie wurde ein vollständiges Rollback der Netzwerkkonfiguration über alle betroffenen Edge-Switches ausgeführt. Routing-Ankündigungen und TCP-Erreichbarkeit der öffentlichen Produktion IP-Adressen wurden nach dem Rollback überprüft. Alle betroffenen Dienste - DCD, Partner Portal, Reseller Portal und IAM - wurden bis 16:35 UTC voll funktionsfähig bestätigt. ### ** Kurzfristig ** * **Staging Environment Replication:** In der Staging-Umgebung werden detaillierte Testfälle ausgeführt, um das genaue Routing-Ausbreitungsverhalten unter den gleichen Schalterkonfigurationsbedingungen zu reproduzieren. Ziel ist es, festzustellen, ob die Anomalie auf einen bestimmten Softwareversionsfehler oder ein Switch-Plattformverhalten zurückzuführen ist, so dass der genaue Fehlerzustand vor einem zukünftigen Rollout isoliert und behoben werden kann. ETA: Innerhalb von zwei Wochen ### ** Halbzeit** * **Überarbeitete Rollout-Strategie:** Basierend auf den Erkenntnissen aus dem Staging wird ein überarbeiteter Rollout-Ansatz entwickelt, um sicherzustellen, dass eine zukünftige Anwendung dieser Routing-Filteroptimierungen mit größeren Stabilitätsgarantien durchgeführt werden kann - einschließlich detaillierterer Validierungs-Checkpoints zwischen Switch-Level-Änderungen. ETA: Oktober 2026 ## ** Schlussbemerkungen** Wir erkennen an, dass der Verlust des Zugangs zu IAM und DCD echte operative Auswirkungen hat. Die Tatsache, dass die zugrunde liegenden Dienste durchgehend gesund waren, ist keine Abschwächung dieser Auswirkungen. Wir sind bestrebt, sicherzustellen, dass die Ursache vor einem erneuten Versuch der ursprünglichen Änderung vollständig verstanden wird und dass die überarbeitete Rollout-Strategie die Bedingungen anspricht, die zum asymmetrischen Routing-Verhalten geführt haben. Wir danken Ihnen für Ihre Geduld, während wir die Untersuchung abschließen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 26. August 2026 um 09:53 UTCinvestigating

   Wir untersuchen derzeit eine erhöhte Latenz, die sich auf S3 Object Storage in der Region eu-central-1 auswirkt. Einige Kunden können langsame Reaktionszeiten für Lese- und Schreibvorgänge erleben. Unser Engineering-Team arbeitet aktiv an der Lösung des Problems. Wir werden Updates bereitstellen, sobald weitere Informationen verfügbar sind.

2. 27. August 2026 um 12:00 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

3. 31. August 2026 um 17:08 UTCidentified

   Wir sehen wiederkehrende Latenzspitzen, die unseren S3-Service in eu-central-1 beeinflussen. Die Teams von Object Storage und Network untersuchen gemeinsam. Obwohl eine technische Ursache zu diesem Zeitpunkt unbestimmt bleibt, ist unsere höchste Priorität die Umsetzung von Maßnahmen zur Milderung der Frequenz und Amplitude der Spikes. Wir schätzen Ihre Geduld und werden Sie auf dem Laufenden halten.

4. 1. September 2026 um 15:18 UTCidentified

   Unsere Ingenieurteams haben einen Weg zur Sanierung gefunden. Erste Maßnahmen wurden ergriffen, um die Situation für einige Dienste zu verbessern. Kunden, die Object Storage in eu-central-1 verwenden, können weiterhin eine erhöhte Latenz aufweisen, die in ihrem Schweregrad variieren kann. Die Arbeit an einem umfassenden Fix geht weiter. Wir werden weitere Updates bereitstellen

5. 3. September 2026 um 08:27 UTCmonitoring

   Die Reaktionszeiten für Object Storage in eu-central-1 haben sich deutlich verbessert und stabilisieren sich weiter. Wir überwachen die Systemleistung genau. Wir werden weitere Updates bereitstellen, wenn die Sanierung voranschreitet.

6. 3. September 2026 um 13:39 UTCresolved

   Die erhöhte Latenz von S3 Object Storage in eu-central-1 wurde behoben. Die Reaktionszeiten sind auf ein normales Niveau zurückgekehrt. Wir werden den Service weiterhin überwachen.

7. 8. September 2026 um 12:25 UTCpostmortem

   # Wurzelursachenanalyse ## Was ist passiert? Ab ca. 19:00 Uhr UTC am 24. August 2026 erlebten Kunden, die auf S3 Object Storage im Frankfurter Rechenzentrum (FRA4) zugriffen, eine erhöhte Latenzzeit bei allen Operationen - Uploads, Downloads, Metadatenanforderungen und Löschungen. Intermittierende HTTP 503 Service Unavailable und 404 Not Found Fehler wurden bei Objektleseanforderungen beobachtet. Die Auswirkungen waren für alle Kunden messbar, die Buckets in den beiden betroffenen Rechenzentren der Region hatten, wobei einige Kunden je nach ihrer Bucket-Konfiguration und ihren Zugriffsmustern stark beeinträchtigt wurden. Der Vorfall blieb mit hoher Priorität vom 25. August bis zum 3. September 2026 im Gange. Das Latenzproblem wurde um etwa 13:40 UTC am 3. September 2026 gemildert. ## Wie war das möglich? \(Wurzelursache\) **Hauptursache - Softwarefehler im Subsystem Quality of Service \(QoS\)** IONOS S3 Object Storage in der Region Frankfurt nutzt ein verteiltes Objektspeichersystem. Eine QoS-Funktion dieses Dienstes - implementiert über einen redis-qos-Dienst - gilt für S3-Anfragen auf Clusterebene als Tarifbegrenzung. Ein Fehler im S3-Dienst führt zu nicht gut verteilten Anfragen an den Redis-QOS-Dienst (der von mehreren Servern für Hochverfügbarkeit bedient wird), was dazu führt, dass der Redis-QOS-Prozess eine 100%ige CPU-Auslastung erreicht und aufrechterhält, was die Verarbeitung aller S3-Anfragen auf Clusterebene schrittweise verlangsamt. Dies wirkte sich auf jede Anforderung aus, die durch die betroffenen Knoten geleitet wird, unabhängig von der Art der Operation oder dem spezifischen Bucket, auf den zugegriffen wird. Dies ist ein interner Defekt innerhalb der verwendeten Software. Der Fehler führte dazu, dass der S3-Dienst alle verfügbaren Ressourcen verbrauchte, bevor das Laden Anforderungsniveaus erreichte, die normalerweise eine Drosselung auslösen würden, was bedeutet, dass die Verschlechterung kontinuierlich und nicht nur unter Spitzenbedingungen stattfand. In enger Zusammenarbeit mit dem Softwarehersteller haben wir am 3. September die QoS-Ratenbegrenzungsfunktion deaktiviert, wodurch das Latenzproblem vollständig behoben wurde. S3 arbeitet derzeit ohne einige QoS-Funktionen, während ein permanenter Fix vom Anbieter vorbereitet wird. Was tun wir, um Wiederholungen zu verhindern? **Bereits abgeschlossen:** * QoS im S3-Dienst deaktiviert - das Latenzproblem wurde vollständig behoben. \(DONE\) * Anfordern einer dauerhaften Lösung vom Softwareanbieter. \(INPROGRESS\) **Kurzfristig - ETA: innerhalb von 2 Wochen:** * Permanente Korrektur für den Cloudian QoS-Bug: IONOS Cloud arbeitet aktiv mit dem Anbieter zusammen, um eine Korrektur für den redis-qos-Defekt zu erhalten und bereitzustellen. Sobald der Fix validiert ist, werden verlorene QoS-Funktionen wieder aktiviert. Datenbankpartitionsüberwachung: Wir implementieren eine Überwachung, die das Wachstum der Partitionsgröße warnt, bevor sich eine einzelne Partition einem problematischen Schwellenwert nähert. Dies ermöglicht es unserem Team, Bucket-Layout-Probleme proaktiv zu identifizieren und anzugehen. ** Halbzeit - ETA: 1 bis 3 Monate:** * Überprüfung der QoS-Architektur: Nach dem permanenten QoS-Fix werden wir die architektonische Isolation des QoS-Dienstes zusammen mit dem Anbieter überprüfen, um sicherzustellen, dass sich ein zukünftiges Ressourcenkonfliktereignis in der ratenbegrenzenden Schicht nicht auf den Anforderungspfad in der gleichen Größenordnung ausbreiten kann. * Monitoring- und Alarmierungsverbesserungen: Wir erweitern die Cluster-Überwachung auf die Oberflächen-Redis-Qos-CPU-Sättigung und den Datenbankverdichtungs-Backlog als erstklassige Störsignale mit automatisierter Eskalation, bevor sich eine sichtbare Latenz des Kunden entwickelt. ## Schlussbemerkungen Ein Vorfall dieser Dauer in einem Kerninfrastrukturdienst ist nicht akzeptabel. Die hohe Latenzzeit dauerte neun Tage, während derer Kundenarbeitslasten in Abhängigkeit von S3 in der Region Frankfurt abgebaut wurden. Mehrere Optimierungen und Minderungsstrategien wurden im Laufe des Vorfalls umgesetzt, konnten die Situation jedoch nur für einzelne Buckets und nur in gewissem Maße verbessern. Die Erkennung des zugrunde liegenden QoS-Bugs und die Entwicklung einer Minderung erforderten eine Koordination mit dem Engineering-Team des Anbieters. Während das Latenzproblem gemildert wird, bleiben wir in engem Kontakt mit dem Anbieter. Die Engineering-Arbeit, um eine dauerhafte QoS-Fix zu liefern, den Druck der Datenbankpartition zu reduzieren und ein Wiederauftreten zu verhindern, ist im Gange. Wir arbeiten auch eng mit unserem Technologiepartner zusammen, um Verzögerungen bei der Analyse der Ursache dieses Vorfalls zu verstehen. Wir werden ein gemeinsames Post-Mortem durchführen, um Bereiche zu identifizieren, in denen die Zusammenarbeit bei Vorfällen verbessert werden kann. Wir erkennen die Auswirkungen dieses Vorfalls auf Ihre Operationen an. Wir glauben, dass die aufgeführten Maßnahmen uns helfen werden, ähnliche Fehlermuster zu verhindern und die Analyse und Wiederherstellung von Softwareproblemen in Zukunft zu beschleunigen. Wir danken Ihnen für Ihre Geduld während des Vorfalls.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 23. August 2026 um 12:47 UTCinvestigating

   Wir untersuchen derzeit ein Problem, bei dem Buckets und Object Storage Keys nicht im Data Center Designer angezeigt werden. Es ist derzeit nicht möglich, über den Data Center Designer auf Buckets und Keys zuzugreifen, zu ändern, zu erstellen und zu löschen.

2. 23. August 2026 um 17:48 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 21. August 2026 um 07:52 UTCinvestigating

   Derzeit ist es nicht möglich, IP-Blöcke zu reservieren oder zu verarbeiten, weder in DCD noch über API. Unsere Teams untersuchen das Problem. Wir werden Sie auf dem Laufenden halten.

2. 21. August 2026 um 08:18 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

3. 23. August 2026 um 17:49 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 14. August 2026 um 14:50 UTCidentified

   Es kann zu erhöhten Wartezeiten kommen, wenn Sie den IONOS Cloud Support telefonisch anrufen. Wir bitten Kunden und Partner, sich stattdessen über das DCD-Formular oder die E-Mail an den Cloud-Support zu wenden.

2. 17. August 2026 um 13:31 UTCidentified

   Die Situation ist immer noch unverändert, also wäre es am besten, bitte per E-Mail zu erreichen.

3. 20. August 2026 um 08:18 UTCresolved

   Wir haben es geschafft, die normale Kapazität wiederherzustellen, so dass der Support wieder normal verfügbar ist. Vielen Dank für die Geduld.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 14. August 2026 um 10:51 UTCidentified

   We are currently reports of error VDC-14-1836 during provisioning operations. Our provisioning team is informed and is preparing a hotfix.

2. 14. August 2026 um 12:42 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

3. 14. August 2026 um 13:34 UTCresolved

   This incident has been resolved.

1. 13. August 2026 um 00:49 UTCinvestigating

   We are currently investigating reports of increased AI Model Hub error rates and latencies. More details will be shared as they become available.

2. 14. August 2026 um 08:04 UTCresolved

   We were able to resolve this issue, it's back to normal now.

1. 11. August 2026 um 16:05 UTCinvestigating

   we are currently investigating increased error rate for our provisioning service.

1. 11. August 2026 um 16:05 UTCinvestigating

   Derzeit erhöht sich die Bearbeitungszeit für die Bereitstellung von Bestellungen, die über Data Center Designer oder API initiiert werden. Gelegentlich können Verbindungen in Richtung des Data Center Designers verloren gehen. Verfügbarkeit und Zugänglichkeit Ihrer virtuellen Rechenzentrumsressourcen bleiben unberührt. Wir werden Sie informieren, sobald die Funktionalität wiederhergestellt ist.

2. 11. August 2026 um 16:23 UTCidentified

   We have identified a likely culprit. The Provisioning Team has implemented a mitigation. We see the performance of the service stabilizing.

3. 11. August 2026 um 16:37 UTCidentified

   We are still seeing residual 500 errors from the Cloud API and are working towards resolving the remaining service degradation.

4. 11. August 2026 um 19:24 UTCmonitoring

   We confirm that the provisioning service has recovered and is operating normally. Our teams will continue to monitor the environment to ensure its stability and continued operation.

5. 12. August 2026 um 11:52 UTCresolved

   This incident has been resolved.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 4. August 2026 um 10:24 UTCidentified

   We are aware of intermittent control plane unavailability affecting a subset of Managed Kubernetes customers. Affected customers may experience API call failures, deployment timeouts, and temporary disruption of cluster management operations. Our engineering team is actively working on both immediate mitigations and longer-term architectural improvements. Several mitigations have already been deployed, including maintenance schedule optimization, compaction regression fixes, and storage performance improvements. Additional measures - including infrastructure migration, dedicated event etcd clusters, improved load balancing, and horizontal scaling - are in progress. We are providing regular updates on this page. Customers experiencing issues are encouraged to subscribe to this incident for timely notifications.

2. 4. August 2026 um 13:14 UTCidentified

   During a service rollout today, a subset of control planes experienced temporary restarts. Affected customers may notice brief API unavailability while these control planes recover. The team is monitoring the recovery. Separately, work on improving infrastructure capacity and load distribution continues as described in our initial update. We will post another update once the affected control planes have fully stabilized.

3. 4. August 2026 um 14:37 UTCidentified

   We are currently rolling out memory scaling measures to address recurring stability issues during compaction operations on the affected etcd clusters. Additionally, we are planning to roll out further horizontal scaling for the affected clusters today. We will provide another update once these measures have been applied and we can assess their impact.

4. 4. August 2026 um 16:23 UTCidentified

   Our plans for further horizontal scaling of the control plane are progressing. We expect to be able to do a dry run and further testing within the next hours, before we proceed with migrations. We aim to finish work on horizontal scaling until EOD. We are rolling out memory configuration improvements in parallel.

5. 4. August 2026 um 21:11 UTCmonitoring

   Memory adjustments have been rolled out and show positive effects. We are starting the migrations planned to further improve control plane performance for all our customers. We estimate that the migration will be completed in the next hours. Control Plane performance is expected to improve already during the migration. We are setting this incident into Monitoring status and will provide an update once the migration is completed.

6. 5. August 2026 um 06:23 UTCidentified

   Migration of the first batches has been completed. The Kubernetes Team has identified a remaining issue preventing further migration. We are setting this incident back to active until the issue is resolved and the migration completed.

7. 5. August 2026 um 10:07 UTCidentified

   Migration has been picked up again. We already see encouraging results after completion of first batches. In the next hours we focus on completing the migration and horizontal scaling. During the migration, single etcds can be temporarily unavailable for time periods lasting around 30 seconds. We expect further performance and stability improvements for all customers during and after the migration.

8. 5. August 2026 um 20:43 UTCidentified

   Memory limit adjustments and migration have had positive effects on the first control plane cluster. Customer situated in the first control plane cluster should already see substantial improvements in performance and stability. We have started to roll out memory adjustments in the remaining control plane cluster, as well. Rolling out the memory limits can lead to temporary unavailability of affected control planes. These interruptions should be brief and will not affect running workloads. After memory limit adjustments are fully rolled out on the second control plane cluster, horizontal scaling and migrations will resume on both control plane clusters for the next hours until workload is distributed optimally.

9. 6. August 2026 um 08:04 UTCmonitoring

   Memory limit adjustments have been fully rolled out across all control plane clusters and are showing positive effects. We have significantly expanded the underlying infrastructure capacity and migration of customer workloads is progressing well. We are observing substantial improvements in control plane stability and performance. The recurring disruption patterns described in earlier updates are no longer present. Migration work will continue throughout the day. We will provide an update once migrations are completed or if any changes in status occur.

10. 7. August 2026 um 05:06 UTCmonitoring

    Migration of customer workloads on the first control plane cluster has been completed ahead of schedule. Customer clusters have been redistributed across expanded infrastructure and all migrated workloads are running without issues. We continue to observe stable control plane performance with no new disruptions reported.

11. 10. August 2026 um 19:58 UTCresolved

    We are marking this incident as resolved. The measures already put into place have had the desired effect on the service and have improved performance and stability. While this incident is marked as resolved, we are continuing executing on our action plan to improve the performance and reliability of our Managed Kubernetes Control Planes. Our current focus: - Further load balancing on our Control Plane Clusters - Migration of control planes to improved infrastructure

1. 4. August 2026 um 08:20 UTCidentified

   IONOS Cloud Support is temporarily not always available via phone. We ask Customers and Partners to contact Cloud Support via the DCD Form or Email, instead.

2. 4. August 2026 um 10:02 UTCresolved

   We were able to assign additional personnel and will set this status page to resolved.

1. 28. Juli 2026 um 13:46 UTCinvestigating

   Wir untersuchen derzeit ein Verbindungsproblem, das sich auf unsere DBaaS-Dienste (MongoDB) auswirkt. Unser Team arbeitet daran, das Problem zu lösen, und wir werden Sie aktualisieren, sobald die volle Funktionalität wiederhergestellt ist.

2. 28. Juli 2026 um 13:47 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen.

3. 28. Juli 2026 um 13:51 UTCidentified

   Wir haben ein Problem mit DNS identifiziert. Unser DBaaS-Team analysiert derzeit den Service. Ein potenzieller Täter wurde identifiziert. Wir werden hier ein weiteres Update bieten spätestens 14:15

4. 28. Juli 2026 um 13:54 UTCmonitoring

   Das DBaaS-Team hat eine Änderung, die vor der Aktualisierung der DNS-Dienste bereitgestellt wurde, zurückgesetzt. Wir sehen, dass sich die Dienste erholen. Wir verfolgen die Situation aufmerksam.

5. 28. Juli 2026 um 16:36 UTCresolved

   Wir markieren diesen Vorfall als behoben, da keine weiteren Anomalien festgestellt werden konnten. Wir werden eine RCA teilen, sobald sie zusammengestellt ist.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 25. Juli 2026 um 06:27 UTCinvestigating

   Wir untersuchen Warnungen im Zusammenhang mit dem Verlust von Redundanz auf Speicherservern. Es gibt derzeit keine Kundenauswirkungen, unser Speicherteam untersucht und arbeitet daran, Redundanz wiederherzustellen. Wir vermuten eine fehlerhafte Netzwerkkomponente.

2. 25. Juli 2026 um 06:44 UTCmonitoring

   Wir haben eine wahrscheinliche Ursache gefunden. Eine Verwaltungskomponente verursachte einen übermäßigen Speicherverbrauch und führte zu Instabilität auf den betroffenen Speicherservern. Dies wurde gemildert. Wir überwachen derzeit die Umwelt und werden den Vorfall beenden, wenn keine weiteren Anomalien beobachtet werden.

3. 25. Juli 2026 um 07:49 UTCresolved

   Es wurden keine Anomalien mehr festgestellt. Die Wurzelursache des Redundanzverlustes wurde als Speicherleck in einer Managementkomponente identifiziert. Eine dauerhafte Abschwächung wurde eingeführt, um ein Wiederauftreten zu vermeiden. Das Speicherleck wird in einem bevorstehenden Update der Verwaltungskomponente behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 24. Juli 2026 um 06:51 UTCidentified

   Während der telefonische support in der regel verfügbar sein wird, ist unsere kapazität aufgrund mehrerer fälle von krankenurlaub reduziert. Wir möchten Sie darüber informieren, dass unser Telefonsupport in den folgenden Zeitfenstern begrenzt ist, was zu erhöhten Reaktionszeiten auf dem Telefonkanal führt. In diesen Fällen erreichen Sie bitte per E-Mail. Vielen Dank.

2. 27. Juli 2026 um 05:43 UTCresolved

   Die Verfügbarkeit von Cloud Support ist zurück. Vielen Dank für Ihr Verständnis.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 23. Juli 2026 um 10:44 UTCinvestigating

   Wir untersuchen derzeit erhöhte AI Model Hub Fehlerraten und Latenzen. Weitere Details werden geteilt, sobald sie verfügbar sind. Betroffene Dienste: AI Model Hub Standort: Global Services

2. 23. Juli 2026 um 11:25 UTCmonitoring

   Es wurde ein Fix implementiert, der die Anzahl der 4xx- und 5xx-Antworten auf nominale Ebenen reduziert hat. Wir werden die Ergebnisse weiter verfolgen.

3. 28. Juli 2026 um 07:12 UTCresolved

   Wir markieren diesen Vorfall als gelöst. Unser AI Modelhub Team hat sich mit dem Problem befasst, das durch akute Ressourcenbeschränkungen verursacht wurde. Dies wurde durch die Beseitigung der Engpässe behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 18. Juli 2026 um 13:33 UTCinvestigating

   Wir untersuchen derzeit ein vermutetes Netzwerkverbindungsproblem, das den MK8s-Dienst beeinflusst. Wir werden die Statusseite mit neuen Informationen aktualisieren, sobald sie verfügbar sind.

2. 18. Juli 2026 um 13:55 UTCinvestigating

   Erste Untersuchungen machen ein Problem mit der Netzwerkverbindung unwahrscheinlich. Das Team konzentriert sich auf die Untersuchung auf Managed Kubernetes Seite.

3. 18. Juli 2026 um 14:26 UTCidentified

   Wir haben einen Anstieg in unserer Warteschlange für die Bereitstellungsmaschine festgestellt, der eine wahrscheinliche Ursache für die beobachteten Probleme ist. Unser Provisioning-Team ist informiert und hat sich der Antwort angeschlossen.

4. 18. Juli 2026 um 14:47 UTCidentified

   Wir haben das Problem eingegrenzt und glauben, dass wir den Schuldigen identifiziert haben. Wir bestätigen derzeit die Feststellung.

5. 18. Juli 2026 um 15:03 UTCidentified

   Unser Lagerteam hat den mutmaßlichen Täter bestätigt. Wir mildern derzeit das Problem und werden die Ausführung von Provisioning-Jobs danach überwachen.

6. 18. Juli 2026 um 15:51 UTCidentified

   Das Speicherproblem wurde erfolgreich behoben, die Jobbereitstellung schreitet jedoch derzeit nicht erfolgreich voran. Unser Provisioning-Team untersucht.

7. 18. Juli 2026 um 16:54 UTCidentified

   Während der Provisionierungsblock behoben werden könnte, untersuchen wir eine erhöhte Anzahl von Speicherfehlern. Wir richten unsere Aufmerksamkeit auf diese verbleibenden Fragen. Kunden können immer noch Probleme beim Anbringen von Speichern auf Kubernetes sehen.

8. 18. Juli 2026 um 17:24 UTCidentified

   Wir haben ein Problem mit einem Speicherserver gefunden, der zu einem redundanten Speicherserverpaar gehört. Unser Team implementiert eine Minderung.

9. 18. Juli 2026 um 17:54 UTCmonitoring

   Der Vorfall sollte nun gemildert werden. Der betroffene Speicherserver wird derzeit wiederhergestellt. Sobald dies abgeschlossen ist, wird die Redundanz vollständig wiederhergestellt. Wir sehen keine verbleibenden Probleme bei der Bereitstellung mehr. Wir beobachten die Situation und die Restaurierung und werden dann den Vorfall lösen.

10. 18. Juli 2026 um 19:27 UTCmonitoring

    Aufgrund des laufenden Wiederherstellungsaufwands auf dem Speicherserver können Kunden beim Anbringen/Entfernen des Speichers noch Restauswirkungen sehen, bis die Redundanz vollständig wiederhergestellt ist. Wir setzen die Auswirkungen des Dienstes zurück auf Degraded Performance.

11. 18. Juli 2026 um 20:24 UTCmonitoring

    Das Team hat eine Komplikation während der Wiederherstellung des zweiten Speicherservers im Paar festgestellt. Hardware muss ersetzt werden. Unser Rechenzentrumsteam arbeitet an dieser Aufgabe. Für noch betroffene Kunden arbeiten wir daran, eine Minderung zu implementieren, um Speichervorgänge parallel zu entsperren.

12. 18. Juli 2026 um 21:31 UTCmonitoring

    Hardware-Ersatz wird durchgeführt. Das Team entschärft weiterhin akute Probleme mit der Speicherbereitstellung, bis der Ersatz und die Wiederherstellung der Hardware abgeschlossen sind, um die Auswirkungen auf die Kunden zu minimieren.

13. 18. Juli 2026 um 22:03 UTCmonitoring

    Hardware-Ersatz wurde abgeschlossen. Die Wiederherstellung der Redundanz geht weiter.

14. 18. Juli 2026 um 22:43 UTCmonitoring

    Der erste Hardware-Ersatz war erfolglos. Eine weitere wird versucht. In der Zwischenzeit läuft eine Datenmigration, um Daten zu einem anderen Speicherziel zu migrieren. Aufgrund der zu migrierenden Datenmenge wird die Migration auf mehrere Stunden geschätzt.

15. 19. Juli 2026 um 12:21 UTCmonitoring

    Die Migration der Speicher wurde abgeschlossen, was weitere Probleme beim Anbringen von Speichern verhindern sollte. Die Migration von Snapshot-Daten läuft derzeit, sodass Snapshot-bezogene Aktivitäten möglicherweise immer noch nicht erfolgreich abgeschlossen werden können.

16. 4. August 2026 um 10:01 UTCresolved

    we are marking this incident as resolved as the underlying storage issue has been resolved. We will create a follow up incident for Managed Kubernetes performance and stability issues to avoid confusion.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 15. Juli 2026 um 10:15 UTCidentified

   Während der telefonische support in der regel verfügbar sein wird, ist unsere kapazität aufgrund mehrerer fälle von krankenurlaub reduziert. Wir möchten Sie darüber informieren, dass unser Telefonsupport in den folgenden Zeitfenstern begrenzt ist, was zu erhöhten Reaktionszeiten auf dem Telefonkanal führt. 15.07.2026: 21:00 – 05:00 UTC 16.07.2026: 21:00 – 05:00 UTC Wenn möglich, bitten wir Sie, Tickets über das DCD-Formular oder per E-Mail einzureichen. Vielen Dank für Ihr Verständnis!

2. 17. Juli 2026 um 16:55 UTCresolved

   Telefonabdeckung ist derzeit normal

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 13. Juli 2026 um 11:18 UTCinvestigating

   We are currently investigating problems accessing VMs and DBaaS service located in Frankfurt. We will inform you as soon as the functionality has been restored.

2. 13. Juli 2026 um 11:21 UTCresolved

   This was a duplicate.