Störungsverlauf von Linode

1. 24. August 2026 um 21:52 UTCinvestigating

   Unser Team untersucht ein Problem, das den Object Storage Service in US-SEA betrifft. Während dieser Zeit können Benutzer intermittierende 5xx-Fehler mit diesem Dienst auftreten.

2. 25. August 2026 um 00:31 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen.

3. 25. August 2026 um 00:55 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

4. 25. August 2026 um 01:11 UTCresolved

   Wir haben keine zusätzlichen Probleme mit dem Object Storage-Service beobachtet und werden diesen Vorfall nun als behoben betrachten. Wenn Sie weiterhin Probleme haben, öffnen Sie bitte ein Support-Ticket für Hilfe.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 21. August 2026 um 17:23 UTCinvestigating

   Unser Team untersucht ein aufkommendes Serviceproblem, das uns-sea betrifft (Seattle, WA). Wir werden zusätzliche Updates teilen, da wir mehr Informationen haben.

2. 21. August 2026 um 21:59 UTCresolved

   Zu diesem Zeitpunkt konnten wir das Problem beheben und der Dienst hat den normalen Betrieb wieder aufgenommen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 14. August 2026 um 20:13 UTCinvestigating

   Unser Team untersucht ein Problem, das die Konnektivität in unserem IT-MIL-Rechenzentrum (Mailand) betrifft. Während dieser Zeit können Benutzer intermittierende Verbindungszeiten und Fehler für alle in diesem Rechenzentrum bereitgestellten Dienste auftreten. Wir werden zusätzliche Updates teilen, da wir mehr Informationen haben.

2. 14. August 2026 um 21:18 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen. Wir werden zusätzliche Updates teilen, da wir mehr Informationen haben.

3. 14. August 2026 um 21:30 UTCresolved

   Wir haben keine zusätzlichen Verbindungsprobleme in unserem IT-MIL-Rechenzentrum (Mailand) festgestellt und werden diesen Vorfall nun als behoben betrachten. Wenn Sie weiterhin Probleme haben, öffnen Sie bitte ein Support-Ticket für Hilfe.

4. 18. August 2026 um 19:02 UTCpostmortem

   Am 14. August 2026, beginnend um 17:30 UTC, wurden während einer Veranstaltung in unserem IT-MIL-Rechenzentrum mehrere Warnungen ausgelöst, die darauf hindeuteten, dass mehrere Hosts in diesem Rechenzentrum nicht mehr erreichbar waren. Akamai begann sofort, das Problem zu untersuchen und daran zu arbeiten, die betroffenen Wirte wiederherzustellen. Während des Impact-Fensters hätten Kunden intermittierende Verbindungszeiten und Fehler bei allen in diesem Rechenzentrum bereitgestellten Diensten erlebt. Wir haben die betroffenen Hosts wiederhergestellt und die Verbindungsprobleme am 14. August 2026 um 21:20 Uhr UTC behoben. Wir untersuchen noch immer die Ursache der Störung. Wir sind entschlossen, zukünftige Vorfälle zu verhindern und werden eine gründliche Untersuchung durchführen, warum die Gastgeber unerreichbar wurden, und Maßnahmen zur Verbesserung der Stabilität und Zuverlässigkeit durchführen. Diese Zusammenfassung gibt einen Überblick über unser aktuelles Verständnis des Vorfalls angesichts der verfügbaren Informationen. Unsere Untersuchung ist im Gange, und alle hierin enthaltenen Informationen können sich ändern.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 13. August 2026 um 21:13 UTCinvestigating

   Unser Team untersucht ein Problem, das die Erstellung von Linode Kubernetes Engine Enterprise (LKE-E)-Clustern im Rechenzentrum IAD2 in Washington betrifft. Dies ist eine Fortsetzung des zuvor gemeldeten Problems. Wir werden zusätzliche Updates teilen, da wir mehr Informationen haben.

2. 13. August 2026 um 23:02 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

3. 13. August 2026 um 23:24 UTCresolved

   Dieser Vorfall wurde behoben.

4. 18. August 2026 um 20:32 UTCpostmortem

   Zwischen 17:25 UTC und 22:50 UTC am 13. August 2026 erhielten Kunden von Linode Kubernetes Engine Enterprise (LKE-E), die versuchten, G7-dedizierte Linode-Instanzen in unserem Rechenzentrum in Washington (IAD2) bereitzustellen, 403 Fehlermeldungen bei der Bereitstellung. Aktive Workloads und laufende Instanzen waren von diesem Problem nicht betroffen. Unsere Untersuchung ergab, dass die gesamte physische Hardwarekapazität in IAD2 zwar ausreichend war, die Bereitstellungsanforderung jedoch einen Berechtigungsüberprüfungsfehler aufgrund eines anfänglichen Schwellenwerts für die Soft-Host-Zuweisung auslöste. Akamai löste das Problem, indem es das Linode-per-Host-Limit von 5 auf 20 in IAD2 erhöhte. Die vollen Einsatzmöglichkeiten wurden um 22:50 UTC wiederhergestellt und stabilisiert. Um Wiederholungen zu verhindern, werden wir eine spezielle Warnung für Berechtigungs- und Kapazitätsprobleme implementieren, die direkt mit Reaktionslaufbüchern für eine schnelle Behebung verbunden ist. Darüber hinaus bauen wir ein zentrales Kapazitätsübersichts-Dashboard auf, um die regionale Headroom proaktiv zu verfolgen. Diese Zusammenfassung gibt einen Überblick über unser aktuelles Verständnis des Vorfalls angesichts der verfügbaren Informationen. Unsere Untersuchung ist im Gange und alle hierin enthaltenen Informationen können sich ändern.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 13. August 2026 um 18:46 UTCinvestigating

   Unser Team untersucht ein aufkommendes Serviceproblem, das die API in allen Regionen betrifft. Wir werden zusätzliche Updates teilen, da wir mehr Informationen haben.

2. 13. August 2026 um 19:58 UTCmonitoring

   Ab 19:30 UTC konnte das Problem mit der API in allen Regionen behoben werden. Wir werden dies überwachen, um sicherzustellen, dass der Service stabil bleibt. Wenn Sie immer noch Probleme haben und kein Support-Ticket öffnen können, rufen Sie uns bitte an 855-454-6633 (+1-609-380-7100 Intl.), oder senden Sie eine E-Mail an [email protected].

3. 13. August 2026 um 19:59 UTCmonitoring

   Wir werden weiterhin auf weitere Probleme achten.

4. 14. August 2026 um 00:26 UTCresolved

   Dieser Vorfall wurde behoben.

5. 17. August 2026 um 17:38 UTCpostmortem

   Am 13. August 2026 um etwa 18:15 Uhr UTC beobachtete Akamai einen kurzen Serviceausfall, der [ api.linode.com ] (http://api.linode.com) betraf. Die gesamte Serviceunterbrechung dauerte ca. 3 Minuten und endete um 18:18 UTC. Nach der Wiederherstellung der anfänglichen Konnektivität hielt die erhöhte API-Response-Latenz bis 19:06 UTC an, was zu langsameren Reaktionszeiten und intermittierenden Verzögerungen für Kunden führte, die mit API-Diensten interagierten. Um die Auswirkungen auf die Leistung zu bewältigen, identifizierten die Akamai-Engineering-Teams eine Konfigurationsabweichung am sekundären Caching-Infrastrukturknoten, die verhinderte, dass er die volle Verkehrslast nach dem Failover absorbierte. Ingenieure haben eine kontrollierte Migration abgeschlossen und den Anforderungs-Caching-Datenverkehr zurück zum primären Host verschoben. Nach dieser Änderung sank die API-Latenz schnell auf ein normales Betriebsniveau. Die anfängliche Bedingung wurde durch einen unerwarteten Neustart des physischen Hosts des primären Caching-Knotens ausgelöst. Während redundante Infrastruktur aktiv war, war der sekundäre Knoten nicht in der Lage, den Failover-Datenverkehr nahtlos zu verarbeiten, was zu einer erweiterten Leistungsminderung führte. Unsere Engineering-Teams führen eine Nachuntersuchung der Failover-Mechanismen durch, um die Ausführungsgeschwindigkeiten zu optimieren und die Konfigurationseinstellungen auf redundante Knoten auszurichten, um sicherzustellen, dass Sekundärsysteme den Datenverkehr bei zukünftigen Ereignissen nahtlos bewältigen können. Diese Zusammenfassung gibt einen Überblick über unser aktuelles Verständnis des Vorfalls angesichts der verfügbaren Informationen. Unsere Untersuchung ist im Gange und alle hierin enthaltenen Informationen können sich ändern.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 13. August 2026 um 16:16 UTCinvestigating

   Unser Team untersucht ein Problem, das die Linode Kubernetes Engine (LKE) betrifft. Wir werden zusätzliche Updates teilen, da wir mehr Informationen haben.

2. 13. August 2026 um 16:30 UTCmonitoring

   Zu diesem Zeitpunkt konnten wir die Probleme mit dem LKE-Service beheben. Wir werden dies überwachen, um sicherzustellen, dass es stabil bleibt. Wenn Sie weiterhin Probleme haben, öffnen Sie bitte ein Support-Ticket für Hilfe.

3. 13. August 2026 um 17:54 UTCresolved

   Wir haben keine zusätzlichen Probleme mit dem LKE-Service beobachtet und werden diesen Vorfall nun als behoben betrachten. Wenn Sie weiterhin Probleme haben, öffnen Sie bitte ein Support-Ticket für Hilfe.

4. 17. August 2026 um 21:30 UTCpostmortem

   Ab etwa 14:50 UTC am 13. August 2026 konnten Kunden, die versuchten, Linode Kubernetes Engine Enterprise (LKE-E) Cluster im IAD2-Rechenzentrum bereitzustellen, dies nicht tun. Wir haben festgestellt, dass das Problem auf den Ausschluss von zwei Komponenten in IAD2 in einem kürzlichen Upgrade der Softwareversion zurückzuführen ist, was zu einer API-Mismatch führte. Wir haben die identifizierten Komponenten aktualisiert, um sie mit dem erwarteten Zustand zu synchronisieren. Dies milderte das Problem um etwa 16:00 UTC am 13. August 2026. Um zu verhindern, dass dieses Problem in Zukunft auftritt, überprüfen wir die Softwareaktualisierungsprozesse von LKE, um sicherzustellen, dass alle enthaltenen Komponenten Versionsupgrades abschließen, bevor sie während der Aktualisierung der Plattformsoftware wieder in Betrieb genommen werden. Diese Zusammenfassung gibt einen Überblick über unser aktuelles Verständnis des Vorfalls angesichts der verfügbaren Informationen. Unsere Untersuchung ist im Gange und alle hierin enthaltenen Informationen können sich ändern.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 14. August 2026 um 15:46 UTCresolved

   Am 13. August 2026, zwischen etwa 14:00-16:30 UTC, beobachteten wir intermittierende Ausfälle und Verzögerungen bei der Bereitstellung neuer LKE-E-Cluster in der Region Seattle (SEA1). Das Problem, das den LKE-E-Service in Seattle betrifft, wurde um ca. 16:30 UTC selbst korrigiert, und wir haben seitdem keine Wiederholung beobachtet. Wir untersuchen aktiv die Ursache. Wir werden den Dienst weiterhin auf Stabilität überwachen. Wenn Sie Probleme mit diesem Service haben, öffnen Sie bitte ein Support-Ticket für Unterstützung.

2. 21. August 2026 um 13:13 UTCpostmortem

   On August 13, 2026, between approximately 14:30 and 16:30 UTC, Akamai experienced an issue affecting Linode Kubernetes Engine Enterprise \(LKE-E\) cluster provisioning and deployment in the Seattle \(SEA1\) region. During this time, customers attempting to create new clusters encountered failures or delays. In some cases, clusters were created but nodes were not fully provisioned, while in others, the control plane responsible for managing the cluster could not be deployed. Akamai identified the issue through customer reports, which was then validated by reproducing the failures in Seattle-based test clusters. Other regions continued to operate normally, and no existing customer workloads were impacted. By around 16:30 UTC on August 13, 2026, cluster provisioning and deployment in the Seattle region returned to normal, allowing new cluster creations to proceed without issue. After recovery, we monitored the region for several days and began a technical investigation into the service disruption. Initial findings indicate a correlation between the issue and a recent network configuration update that occurred at approximately 14:30 UTC and was rolled back at approximately 14:45 UTC. Our current hypothesis suggests that a timing conflict during the cluster provisioning process may have triggered the failures. We are continuing to investigate the technical details to confirm the root cause. We are continuing to investigate the technical details behind this issue and are working to ensure it does not recur. We will also review the scope of affected data centers and track corrective actions. This summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing and any information herein is subject to change.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 10. August 2026 um 17:15 UTCinvestigating

   Unser Team untersucht ein Upstream-Problem, das sich auf Ubuntu-Bereitstellungen auswirkt. Dies kann sich auf die Möglichkeit auswirken, Paket- und Sicherheitsupdates auf allen Ubuntu-Systemen zu installieren.

2. 11. August 2026 um 23:35 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen. Die entsprechenden Fachexperten werden engagiert. Nachfolgende Updates rund um den Minderungsstatus werden veröffentlicht, wenn Fortschritte gemacht werden.

3. 12. August 2026 um 03:29 UTCidentified

   Wir haben die Ursache des Problems identifiziert und ein Fix wird umgesetzt. Wir werden ein Update bereitstellen, sobald die Lösung vorhanden ist.

4. 21. August 2026 um 18:40 UTCresolved

   Wir können bestätigen, dass das Problem am 20. August 2026 um 06:30 UTC gemildert wurde und der Dienst den normalen Betrieb wieder aufgenommen hat.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 31. Juli 2026 um 17:49 UTCinvestigating

   Unser Team untersucht den Paketverlust auf einigen Pfaden von den in-maa & in-bom-2-Rechenzentren in die US-Region. Während dieser zeit können benutzer verbindungszeiten und fehler bei diensten auftreten, die zwischen indien und den vereinigten staaten reisen. Wir werden zusätzliche Updates teilen, da wir mehr Informationen haben.

2. 31. Juli 2026 um 18:25 UTCidentified

   Unser Team hat die Ursache für Paketverluste in unseren US-Rechenzentren identifiziert. Wir arbeiten mit unserem Upstream-Anbieter zusammen, um dieses Problem zu beheben, und wir werden ein Update bereitstellen, sobald die Lösung vorhanden ist.

3. 4. August 2026 um 18:36 UTCidentified

   We are continuing to work with our upstream provider to resolve the packet loss affecting some paths between the in-maa and in-bom-2 data centers and the US region. We will share further updates as progress continues.

4. 5. August 2026 um 01:34 UTCresolved

   At this time the upstream provider has been able to correct the issue causing packet loss on some routes from the in-maa & in-bom-2 data centers into the US region and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

5. 5. August 2026 um 17:49 UTCpostmortem

   On July 31, 2026, at approximately 10:00 UTC, Akamai observed intermittent network losses affecting compute users accessing US locations from our India sites \(MAA and BOM\). Customers’ services in North America, particularly the Miami data center region, experienced increased latency, intermittent connectivity issues, slower data transfers, and difficulty reaching certain applications or services. Performance was unstable, with periods of normal operation followed by disruptions. To address the issue, Akamai applied a deny-all policy to the impacted upstream provider transit link, redirecting traffic around the impacted routes. Despite this mitigation, ongoing IPv6 losses occurred due to congestion between two alternative upstream providers, impacting some users. One provider acknowledged a bottleneck in the Asia region, and the alternate provider worked to reroute traffic away from affected links.  The initial impacted service provider confirmed that two fiber cuts in Mexico caused congestion on the impacted routes. One of these fiber cuts was resolved at 23:43 UTC on July 31, 2026, and no further issues were observed following this mitigation.  This summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing and any information herein is subject to change.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 28. Juli 2026 um 18:14 UTCinvestigating

   Unser Team untersucht ein Problem, das den Block Storage-Service in mehreren Rechenzentrumsregionen betrifft. Dieses Problem wirkt sich weitgehend auf das Anbringen und Trennen von Block Storage-Volumes aus. Während dieser Zeit können Benutzer Volume Attach, Timeouts und Fehler mit diesem Dienst auftreten. Wir werden zusätzliche Updates teilen, da wir mehr Informationen haben.

2. 28. Juli 2026 um 19:27 UTCidentified

   Unser Team hat das Problem identifiziert, das den Block Storage-Service in unseren Rechenzentren betrifft. Wir arbeiten schnell daran, einen Fix zu implementieren, und wir werden ein Update bereitstellen, sobald die Lösung vorhanden ist.

3. 28. Juli 2026 um 20:17 UTCidentified

   Wir möchten aktualisieren, dass sich die Auswirkungen nach zusätzlichen Untersuchungen in verspäteten und manchmal fehlgeschlagenen Host-Jobs manifestieren würden, die viele verschiedene Aktionen auf Linodes beinhalten könnten und nicht nur das Anbringen und Ablösen von Block Storage-Volumes beeinflussen, wie wir in unserem ersten Update erwähnt haben, wir haben den Titel aktualisiert, um die aktualisierten Auswirkungen widerzuspiegeln. Wir arbeiten schnell daran, einen Fix zu implementieren, und wir werden ein Update bereitstellen, sobald die Lösung vorhanden ist.

4. 28. Juli 2026 um 22:51 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

5. 29. Juli 2026 um 12:27 UTCresolved

   Wir haben keine zusätzlichen Probleme mit der Leistungsminderung von Host-Jobs beobachtet und werden diesen Vorfall nun als gelöst betrachten. Wenn Sie weiterhin Probleme haben, öffnen Sie bitte ein Support-Ticket für Hilfe.

6. 31. Juli 2026 um 18:57 UTCpostmortem

   Am 27. Juli 2026 um 3:30 Uhr UTC beobachtete Akamai eine Zunahme von Fehlern bei der Verbindung zur Linode-Hosting-Datenbank, die hauptsächlich Block Storage-Volume-Anhänge betrafen. Dies führte zu Ausfällen von Host-Jobs und begrenzten Kundenauswirkungen, wobei einige Benutzer Fehlermeldungen und unterbrochene Workflows erlebten. Erhöhte Timeout-Raten wurden in Protokollen für bestimmte Rechenzentrumsstandorte vermerkt, was mit der schrittweisen Einführung eines neuen Feature-Flags zusammenfällt. Erste Untersuchungen ergaben intermittierende Paketverluste vom Datenbank-Proxy zu Client-Hosts während des TLS-Handshakes. Die aktuelle Theorie legt nahe, dass eine DDoS-Schutzgrenze in Bezug auf Pfad MTU-Paket zu große ICMP-Nachrichten erreicht wurde. Wenn der Proxy TCP-Pakete mit einer großen MTU sendete, wurden die erwarteten ICMP-Nachrichten von Dallas-Gateway-Routern aufgrund der Überschreitung der konfigurierten zulässigen Rate gelöscht. Dies führte dazu, dass Datenbank-Proxy-TCP-Verbindungen Timeout zu Compute Hosts hatten. Das Problem wurde durch die Aktivierung des neuen Feature-Flags ausgelöst, das den Routing-Pfad änderte und die MTU-Klemmung entfernte, bevor Pakete die Gateways erreichten. Um das Problem zu beheben, hat Akamai den jüngsten Netzwerkwechsel auf den betroffenen Compute-Sites um 20:50 UTC zurückgenommen. Ab 22:57 UTC kehrte die Rate der Service-Neustarts auf das Niveau vor dem Vorfall zurück. Akamai plant auch eine Änderung, um den zulässigen Schwellenwert für zu große Paket-ICMP-Nachrichten zu erhöhen. Diese Zusammenfassung gibt einen Überblick über unser aktuelles Verständnis des Vorfalls angesichts der verfügbaren Informationen. Unsere Untersuchung ist im Gange und alle hierin enthaltenen Informationen können sich ändern.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 20. Juli 2026 um 01:52 UTCinvestigating

   Unser Team untersucht derzeit ein Verbindungsproblem, das Linodes in der Region Italien (Mailand) betrifft. Während dieser Zeit können vorhandene Linoden an diesem Ort nicht erreichbar sein. Bitte beachten Sie, dass das Erstellen neuer Linoden normal funktioniert und unberührt bleibt.

2. 20. Juli 2026 um 02:56 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen. Wir werden das nächste Update bereitstellen, wenn wir Fortschritte machen.

3. 20. Juli 2026 um 03:12 UTCinvestigating

   Unser Team hat das Problem der Konnektivität in unserem Rechenzentrum in Mailand (Italien) identifiziert. Wir arbeiten schnell daran, einen Fix zu implementieren, und wir werden ein Update bereitstellen, sobald die Lösung vorhanden ist.

4. 20. Juli 2026 um 03:20 UTCmonitoring

   Zu diesem Zeitpunkt konnten wir die Probleme mit der Konnektivität in unserem Rechenzentrum in Mailand (Italien) beheben. Wir werden dies überwachen, um sicherzustellen, dass es stabil bleibt. Wenn Sie immer noch Probleme haben, öffnen Sie bitte ein Support-Ticket für Hilfe.

5. 20. Juli 2026 um 04:10 UTCresolved

   Wir haben keine zusätzlichen Verbindungsprobleme in unserem Rechenzentrum in Mailand (Italien) festgestellt und werden diesen Vorfall nun als behoben betrachten. Wenn Sie weiterhin Probleme haben, öffnen Sie bitte ein Support-Ticket für Hilfe.

6. 20. Juli 2026 um 05:45 UTCpostmortem

   Am 20. Juli 2026 um 00:33 Uhr UTC wurden einige Hosts im Rechenzentrum Mailand, Italien, nicht mehr verfügbar, was den Kundenzugang zu Linodes beeinträchtigte. Die Untersuchung ergab, dass dieses Problem bei geplanten Router-Firmware-Updates aufgetreten ist. Während wir einen schrittweisen Upgrade-Prozess verfolgen, um Serviceunterbrechungen zu verhindern, führte eine unerwartete Schnittstelle von gleichzeitigen Wartungsaktivitäten zu einem vorübergehenden Verlust der Netzwerkverbindung für die betroffenen Hosts. Der Service wurde am 20. Juli 2026 um 02:16 Uhr UTC vollständig wiederhergestellt, und alle Systeme funktionieren nun wie erwartet. Intern überprüfen wir unsere Änderungsmanagement- und Wartungsplanungsverfahren, um eine bessere Koordination zu gewährleisten und ähnliche Probleme in Zukunft zu vermeiden. Wir entschuldigen uns für die Auswirkungen und danken Ihnen für Ihre Geduld und anhaltende Unterstützung. Wir sind bestrebt, kontinuierliche Verbesserungen vorzunehmen, um unsere Systeme zu verbessern und Wiederholungen zu verhindern. Diese Zusammenfassung gibt einen Überblick über unser aktuelles Verständnis des Vorfalls angesichts der verfügbaren Informationen. Unsere Untersuchung ist im Gange, und alle hierin enthaltenen Informationen können sich ändern.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 18. Juli 2026 um 03:34 UTCinvestigating

   Unser Team untersucht ein Problem, das den Object Storage-Service betrifft. Während dieser zeit können benutzer verbindungs-timeouts und fehler mit diesem dienst auftreten.

2. 18. Juli 2026 um 03:54 UTCidentified

   Unser Team hat das Problem identifiziert, das den Object Storage-Service betrifft. Wir arbeiten schnell daran, einen Fix zu implementieren, und wir werden ein Update bereitstellen, sobald die Lösung vorhanden ist.

3. 18. Juli 2026 um 04:36 UTCresolved

   Wir haben keine zusätzlichen Probleme mit dem Object Storage-Service beobachtet und werden diesen Vorfall nun als behoben betrachten. Wenn Sie weiterhin Probleme haben, öffnen Sie bitte ein Support-Ticket für Hilfe.

4. 21. Juli 2026 um 15:26 UTCpostmortem

   Am 18. Juli 2026, zwischen ca. 00:30 UTC und 04:00 UTC, haben Benutzer möglicherweise 5xx-Fehler beim Versuch, einen neuen Bucket im Objektspeicher für die folgenden Endpunkte zu erstellen. * [us-ord-1.linodeobjects.com](http://us-ord-1.linodeobjects.com) * [us-lax-1.linodeobjects.com](http://us-lax-1.linodeobjects.com) * [us-iad-1.linodeobjects.com](http://us-iad-1.linodeobjects.com) * [us-sea-1.linodeobjects.com](http://us-sea-1.linodeobjects.com) * [fr-par-1.linodeobjects.com](http://fr-par-1.linodeobjects.com) Das Problem begann, als die Infrastruktur, die Object Storage unterstützt, in einen degradierten Zustand über alle Knoten eintrat. Dies verhinderte, dass der Dienst Anfragen verarbeitete, was zu Ausfällen während der Bucket-Erstellung führte. Um die Auswirkungen zu mildern, haben wir einen Fix im Backend-System angewendet, der für die Bucket-Erstellung verantwortlich ist. Die Auswirkungen wurden nach dieser Aktion gemildert. Unsere Fachexperten untersuchen die Ursache und werden geeignete Präventivmaßnahmen ergreifen. Wir entschuldigen uns für die Auswirkungen und schätzen Ihre Geduld und anhaltende Unterstützung. Wir nehmen Konfigurations- und Betriebsänderungen an unseren Systemen vor, um zu verhindern, dass sich dies wiederholt, und setzen uns weiterhin für kontinuierliche Verbesserungen ein. Diese Zusammenfassung gibt einen Überblick über unser aktuelles Verständnis des Vorfalls, angesichts der verfügbaren Informationen. Unsere Untersuchung ist im Gange, und alle hierin enthaltenen Informationen können sich ändern.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. Juli 2026 um 01:24 UTCresolved

   Unser Team untersuchte ein Problem, das die Konnektivität in unserem US-MIA-Rechenzentrum (Miami) zwischen 21:20 UTC und ungefähr 23:28 UTC am 15. Juli 2026 beeinflusste. Während dieses Fensters haben Benutzer möglicherweise eine verschlechterte Netzwerkleistung und einen Paketverlust für Compute-Dienste in dieser Region erlebt. Das Problem wurde behoben, nachdem wir einen Fix implementiert hatten. Wir arbeiten weiterhin mit unserem drittanbieter zusammen, um die ursache zu bestätigen, da erste beweise auf einen campus-cross-connect-ausfall (dark fiber) auf ihrer infrastruktur hinweisen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 14. Juli 2026 um 12:21 UTCinvestigating

   Unser Team untersucht ein aufkommendes Serviceproblem, das API und CLI betrifft. Wir werden zusätzliche Updates teilen, da wir mehr Informationen haben.

2. 14. Juli 2026 um 12:58 UTCidentified

   Unser Team hat das Problem identifiziert, das den Cloud Manager und die API betrifft. Wir arbeiten schnell daran, einen Fix zu implementieren, und wir werden ein Update bereitstellen, sobald die Lösung vorhanden ist.

3. 14. Juli 2026 um 13:11 UTCmonitoring

   Zu diesem Zeitpunkt konnten wir das Problem mit dem Cloud Manager und der API beheben. Wir werden dies überwachen, um sicherzustellen, dass der Service stabil bleibt. Wenn Sie immer noch Probleme haben und kein Support-Ticket öffnen können, rufen Sie uns bitte an 855-454-6633 (+1-609-380-7100 Intl.), oder senden Sie eine E-Mail an [email protected].

4. 14. Juli 2026 um 18:36 UTCmonitoring

   Wir werden weiterhin auf weitere Probleme achten.

5. 14. Juli 2026 um 19:26 UTCresolved

   Wir haben keine zusätzlichen Probleme mit dem Cloud Manager, der API oder der CLI festgestellt und werden diesen Vorfall nun als behoben betrachten. Wenn Sie weiterhin Probleme haben, kontaktieren Sie uns bitte unter 855-454-6633 (+1-609-380-7100 Intl.), oder senden Sie eine E-Mail an [email protected] für Unterstützung.

6. 16. Juli 2026 um 18:13 UTCpostmortem

   Am 14. Juli 2026, um 10:57 UTC, identifizierte Akamai einen Anstieg von 502 Fehlern und Latenzzeiten, die Kunden mit Linode API, CLI und Cloud Manager betreffen. Diese Störung führte zu moderaten Auswirkungen auf den Service, wobei die Kunden erhöhte Fehlerquoten meldeten. Unsere erste Untersuchung verfolgte das Problem auf Latenz mit IAM-Diensten, die behoben wurde, aber erhöhte Fehler blieben bestehen. Eine weitere Analyse durch relevante Experten ergab, dass der Vorfall durch ein manuelles Failback des primären Lastausgleichs des Cloud IAM vom sekundären Lastausgleichsmechanismus ausgelöst wurde. Diese Aktion wurde durch einen Warnalarm ausgelöst, der anzeigte, dass der sekundäre Load Balancer als Keepalived Master fungierte. Der manuelle Prozess des Startens und Stoppens von Diensten zur Initiierung des Failbacks unterschied sich vom automatisierten Prozess und führte zu einer Kaskade veralteter GRPC-Verbindungen, was zu erhöhten Latenz- und API-Fehlern führte. Durch den Neustart der API-Server wurden die veralteten Verbindungen gelöscht und der normale Betrieb wiederhergestellt. Die Kundenauswirkungen wurden am 14. Juli 2026 um etwa 13:10 UTC gemindert. Um ein Wiederauftreten zu verhindern, untersucht Akamai, warum das manuelle Failback dieses Verhalten verursacht hat. Das Team erwägt die Implementierung eines Drain-Befehls, um GRPC-Verbindungen während des Failovers zu löschen und Warnungen einzurichten, um veraltete Verbindungen für proaktive Eingriffe zu erkennen. Der unmittelbare Fokus liegt jedoch weiterhin auf dem Verständnis der Ursache, wobei Alarmierung und Automatisierung für spätere Phasen geplant sind. Mehrere Kunden haben eine Lösung für ihre Bereitstellungen bestätigt. Akamai wird weiterhin den Zustand des Systems überwachen und auf zusätzliches Kundenfeedback warten, bevor es die vollständige Wiederherstellung erklärt. Diese Zusammenfassung gibt einen Überblick über unser aktuelles Verständnis des Vorfalls angesichts der verfügbaren Informationen. Unsere Untersuchung ist im Gange und alle hierin enthaltenen Informationen können sich ändern.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 13. Juli 2026 um 18:29 UTCidentified

   Unser Team hat ein aufkommendes Serviceproblem identifiziert, das Host-Jobs für einige Hosts in allen Regionen betrifft. Linode-Konnektivität ist *nicht betroffen*, aber einige Host-Level-Jobs, wie Backups oder Versuche, Ihre Dienste einzu- oder auszuschalten, können sich verzögern. Wir werden zusätzliche Updates teilen, da wir mehr Informationen haben.

2. 13. Juli 2026 um 19:54 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 9. Juli 2026 um 16:57 UTCinvestigating

   Unser Team untersucht ein aufkommendes Serviceproblem, das Cloud Manager-Logins betrifft. Wir werden zusätzliche Updates teilen, da wir mehr Informationen haben.

2. 9. Juli 2026 um 17:24 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen. Wir werden innerhalb der nächsten 30 Minuten ein Update bereitstellen.

3. 9. Juli 2026 um 17:49 UTCmonitoring

   Zu diesem Zeitpunkt konnten wir das Problem mit den Cloud Manager-Logins beheben. Wir werden dies überwachen, um sicherzustellen, dass der Service stabil bleibt. Wenn Sie immer noch Probleme haben und kein Support-Ticket öffnen können, rufen Sie uns bitte an 855-454-6633 (+1-609-380-7100 Intl.), oder senden Sie eine E-Mail an [email protected].

4. 9. Juli 2026 um 18:21 UTCresolved

   Wir haben keine zusätzlichen Probleme mit den Cloud Manager-Logins beobachtet und werden diesen Vorfall nun als behoben betrachten. Wenn Sie weiterhin Probleme haben, kontaktieren Sie uns bitte unter 855-454-6633 (+1-609-380-7100 Intl.), oder senden Sie eine E-Mail an [email protected] für Unterstützung.

5. 10. Juli 2026 um 12:30 UTCpostmortem

   Am 9. Juli 2026, um 15:43 UTC, konnten sich die Kunden nicht mit Benutzername und Passwort bei [cloud.linode.com] (http://cloud.linode.com) anmelden. Kunden erhielten eine Fehlermeldung "falsches Passwort". Die Untersuchung ergab, dass das Problem auf ein internes Zertifikatsproblem zurückzuführen war. Um die Auswirkungen zu mildern, haben wir das Zertifikatsproblem auf den betroffenen Servern am 9. Juli 2026 um 17:24 Uhr UTC behoben. Nachdem wir unsere Systeme einige Zeit lang überwacht hatten, bestätigten wir, dass das Problem vollständig gelöst war. Akamai wird eine dauerhafte Lösung einsetzen, um ein Wiederauftreten des Problems zu verhindern.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 6. Juli 2026 um 18:04 UTCinvestigating

   Our team is investigating an emerging service issue affecting Managed Databases across all regions. Customers may experience latency when provisioning new databases or deleting existing ones. There is no observed impact to the performance or availability of active, running databases at this time. We will provide updates as more information becomes available.

2. 7. Juli 2026 um 15:31 UTCresolved

   This incident has been resolved.

1. 1. Juli 2026 um 17:21 UTCidentified

   Our team is investigating a service issue that affects the auto configuration of networking on Linodes by Network Helper to fail. During that time, some users may have Linodes provision but appear to have no connectivity. This also can impact Linodes created by the Linode Kubernetes Engine and impact autoscaling or provisioning of clusters. Customers can still manually configure networking via the LISH console to mitigate this issue. Please see our guide on manual network configuration on a Compute Instance . We will share additional updates as we have more information.

2. 1. Juli 2026 um 18:09 UTCmonitoring

   A fix has been implemented to resolve the automated network configuration issue on Linodes using Network Helper. We recommend rebooting your Linode to restore full network functionality. We are actively monitoring the results to ensure continued stability.

3. 1. Juli 2026 um 18:28 UTCresolved

   We haven’t observed any additional issues with the Linode Automated Networking service, and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

1. 30. Juni 2026 um 18:54 UTCinvestigating

   Our team is investigating an emerging issue affecting the Block Storage service in our Singapore Expansion, SP (sg-sin-2) data center. During this time, users may experience connection timeouts and errors with this service. We will share additional updates as we have more information.

2. 30. Juni 2026 um 19:55 UTCinvestigating

   We are continuing to investigate this issue.

3. 30. Juni 2026 um 20:36 UTCidentified

   Our team has identified the issue affecting the Block Storage service in our Singapore Expansion, SP (sg-sin-2) data center. We are working quickly to implement a fix, and we will provide an update as soon as the solution is in place.

4. 30. Juni 2026 um 21:36 UTCidentified

   We are continuing to work on a fix for this issue.

5. 30. Juni 2026 um 22:10 UTCmonitoring

   At this time we have been able to correct the issues affecting the Block Storage service. We will be monitoring this to ensure that it remains stable. If you continue to experience problems, please open a Support ticket for assistance.

6. 30. Juni 2026 um 23:22 UTCresolved

   We haven’t observed any additional issues with the Block Storage service in Singapore Expansion, SP (sg-sin-2), and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

7. 2. Juli 2026 um 16:29 UTCpostmortem

   On June 30, 2026, between approximately 17:30 UTC and 21:45 UTC, users may have experienced connection timeouts and errors related to the Block Storage service in Singapore Expansion, SP \(sg-sin-2\). The issue began when one host in the cluster was taken down for maintenance while another host unexpectedly encountered network issues. A configuration issue also contributed to the impact. These factors led to a degraded state that affected performance and, to a limited extent, data availability. We mitigated the impact to customers at 21:45 UTC on June 30, 2026 by correcting the network, configuration and cluster issues. We apologize for the impact and appreciate your patience and ongoing support. We are making configuration and operational changes to our systems to help prevent this from happening again, and remain committed to continuous improvement. This summary provides an overview of our current understanding of the incident, given the information available. Our investigation is ongoing, and any information herein is subject to change.

1. 26. Juni 2026 um 17:35 UTCinvestigating

   Unser Team untersucht ein Problem, das die Cloud Pulse Metrics (ACLP Metrics) betrifft, insbesondere das Managed Database Metrics Reporting. Das Thema scheint intermittierend zu sein. Wir werden zusätzliche Updates teilen, da wir mehr Informationen haben.

2. 26. Juni 2026 um 18:19 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen. Wir werden zusätzliche Updates teilen, da wir mehr Informationen haben.

3. 26. Juni 2026 um 19:08 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen. Wir werden weitere Updates zur Verfügung stellen, da wir mehr Informationen haben.

4. 26. Juni 2026 um 20:04 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen.

5. 26. Juni 2026 um 21:13 UTCmonitoring

   Wir haben seit mehreren Stunden kein Wiederauftreten des Problems beobachtet, das die Cloud Pulse Metrics (ACLP Metrics) betrifft. Unser Team wird den Service weiterhin genau beobachten, während wir die zugrunde liegende Ursache untersuchen. Wenn Sie weiterhin Probleme haben, öffnen Sie bitte ein Support-Ticket für Hilfe.

6. 30. Juni 2026 um 00:02 UTCmonitoring

   Wir werden weiterhin auf weitere Probleme achten.

7. 8. Juli 2026 um 12:26 UTCresolved

   Wir haben keine zusätzlichen Probleme mit dem Cloud Pulse Metrics (ACLP Metrics) Service beobachtet und werden diesen Vorfall nun als behoben betrachten. Wenn Sie weiterhin Probleme haben, öffnen Sie bitte ein Support-Ticket für Hilfe.

Automatisch aus der offiziellen Störungsmeldung übersetzt.