Linode driftsforstyrrelser

1. 24. august 2026 kl. 21.52 UTCinvestigating

   Vores team undersøger et problem, der påvirker Objekt Storage service i US- SEA. I løbet af denne tid, kan brugerne opleve intermitterende 5xx fejl med denne tjeneste.

2. 25. august 2026 kl. 00.31 UTCinvestigating

   Vi fortsætter med at undersøge dette spørgsmål.

3. 25. august 2026 kl. 00.55 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

4. 25. august 2026 kl. 01.11 UTCresolved

   Vi har ikke observeret nogen yderligere problemer med Objekt Storage service, og vil nu overveje denne hændelse løst. Hvis du fortsætter med at opleve problemer, skal du åbne en Support billet for hjælp.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 21. august 2026 kl. 17.23 UTCinvestigating

   Vores team undersøger et nyt serviceproblem, der påvirker vores hav (Seattle, WA). Vi vil dele yderligere opdateringer, da vi har flere oplysninger.

2. 21. august 2026 kl. 21.59 UTCresolved

   På nuværende tidspunkt har vi været i stand til at rette op på problemet, og tjenesten har genoptaget den normale drift.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 14. august 2026 kl. 20.13 UTCinvestigating

   Vores team undersøger et problem, der påvirker forbindelsen i vores IT- MIL (Milano) datacenter. I løbet af denne tid, kan brugerne opleve intermitterende forbindelse timeouts og fejl for alle tjenester indsat i dette datacenter. Vi vil dele yderligere opdateringer, da vi har flere oplysninger.

2. 14. august 2026 kl. 21.18 UTCinvestigating

   Vi fortsætter med at undersøge dette spørgsmål. Vi vil dele yderligere opdateringer, da vi har flere oplysninger.

3. 14. august 2026 kl. 21.30 UTCresolved

   Vi har ikke observeret nogen yderligere forbindelsesproblemer i vores IT- MIL (Milano) datacenter og vil nu overveje denne hændelse løst. Hvis du fortsætter med at opleve problemer, skal du åbne en Support billet for hjælp.

4. 18. august 2026 kl. 19.02 UTCpostmortem

   Den 14. august 2026, starter omkring 17: 30 UTC, under en begivenhed i vores IT- MIL\ (Milano\) datacenter, blev flere advarsler udløst, der indikerer, at flere værter i dette datacenter blev utilgængelig. Name Akamai straks begyndte at undersøge problemet og arbejder på at genoprette de ramte værter. Under indslagsvinduet ville kunderne have oplevet intermitterende tilslutningstimeout og fejl på tværs af alle tjenester i dette datacenter. Name Vi restaurerede de ramte værter og fikserede konnektivitet spørgsmål på 21: 20 UTC den 14. august 2026. Vi undersøger stadig årsagen til fejlen. Name Vi er forpligtet til at forebygge fremtidige hændelser og vil foretage en grundig undersøgelse af, hvorfor værterne blev uopnåelige, gennemføre foranstaltninger til at øge stabilitet og pålidelighed. Name Dette resumé giver et overblik over vores nuværende forståelse af hændelsen i betragtning af de tilgængelige oplysninger. Vores undersøgelse er i gang, og alle oplysninger heri kan ændres.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 13. august 2026 kl. 21.13 UTCinvestigating

   Vores team undersøger et problem, der påvirker oprettelsen af Linode Kubernetes Engine Enterprise (LKE- E) klynger i IAD2 - Washington datacenter. Dette er en fortsættelse af det spørgsmål, der blev rapporteret tidligere. Vi vil dele yderligere opdateringer, da vi har flere oplysninger.

2. 13. august 2026 kl. 23.02 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

3. 13. august 2026 kl. 23.24 UTCresolved

   Denne hændelse er blevet løst.

4. 18. august 2026 kl. 20.32 UTCpostmortem

   Mellem 17: 25 UTC og 22: 50 UTC den 13 august 2026, Linode Kubernetes Engine Enterprise\ (LKE- E\) kunder forsøger at implementere G7 dedikerede Linode tilfælde i vores Washington\ (IAD2\) datacenter, modtog 403 levering fejlmeddelelser. Aktive arbejdsbelastninger og løbende tilfælde blev ikke påvirket af dette problem. Vores undersøgelse viste, at mens total fysisk hardware kapacitet i IAD2 var tilstrækkelig, levering anmodning udløste en ret kontrol fiasko på grund af en indledende blød host- tildeling tærskel. Akamai løst problemet ved at øge Linode- per- host grænse fra 5 til 20 i IAD2. Fuld implementering kapaciteter blev genoprettet og stabiliseret på 22: 50 UTC. For at forhindre tilbagefald vil vi implementere dedikeret varsling om rettigheder og kapacitetsproblemer, der er direkte forbundet med responselinjer til hurtig oprydning. Derudover er vi ved at opbygge en centraliseret kapacitetsoversigt instrumentbræt til proaktivt at spore regionale headroom. Dette resumé giver et overblik over vores nuværende forståelse af hændelsen i betragtning af de tilgængelige oplysninger. Vores undersøgelse er i gang, og alle oplysninger heri kan ændres.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 13. august 2026 kl. 18.46 UTCinvestigating

   Vores team er at undersøge en ny service problem påvirker API i alle regioner. Vi vil dele yderligere opdateringer, da vi har flere oplysninger.

2. 13. august 2026 kl. 19.58 UTCmonitoring

   Fra 19: 30 UTC har været i stand til at rette problemet påvirker API i alle regioner. Vi vil overvåge dette for at sikre, at tjenesten forbliver stabil. Hvis du stadig oplever problemer og ikke kan åbne en Support billet, bedes du ringe til os på 855- 454- 6633 (+ 1-609- 380- 7100 Intl.), eller sende en e-mail til support @ linode.com.

3. 13. august 2026 kl. 19.59 UTCmonitoring

   Vi fortsætter med at overvåge for yderligere spørgsmål.

4. 14. august 2026 kl. 00.26 UTCresolved

   Denne hændelse er blevet løst.

5. 17. august 2026 kl. 17.38 UTCpostmortem

   Den 13. august 2026, ca. 18: 15 UTC, Akamai observeret en kort service udfald påvirker [_ api.linode.com _] (http: / / api.linode.com). Den samlede service afbrydelse varede i ca. 3 minutter, slutter kl 18: 18 UTC. Efter genoprettelsen af den oprindelige konnektivitet, hævede API response latency gennem 19: 06 UTC, forårsager langsommere svartider og intermitterende forsinkelser for kunder interagere med API-tjenester. For at imødegå effekterne identificerede Akamai-ingeniørteams en konfigurationsafvigelse på den sekundære cachinginfrastrukturknude, som forhindrede den i at absorbere den fulde trafikbelastning efter fejlen. Ingeniører afsluttet en kontrolleret migration og flyttede anmodning caching trafik tilbage til den primære vært. Efter denne ændring faldt API latency hurtigt til normale driftsniveauer. Den oprindelige tilstand blev udløst af en uventet genstart af den primære caching node fysiske vært. Mens den overflødige infrastruktur var aktiv, var den sekundære node ude af stand til at behandle den svigtende trafik problemfrit, hvilket forårsagede den udvidede forringelse af ydeevnen. Vores ingeniørhold er i gang med en opfølgning-up undersøgelse af failover mekanismer til at optimere udførelsen hastigheder og tilpasse konfigurationsindstillinger på tværs af overflødige knudepunkter, sikre sekundære systemer kan håndtere trafik problemfrit i fremtidige begivenheder. Dette resumé giver et overblik over vores nuværende forståelse af hændelsen i betragtning af de tilgængelige oplysninger. Vores undersøgelse er i gang, og alle oplysninger heri kan ændres.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 13. august 2026 kl. 16.16 UTCinvestigating

   Vores team undersøger et problem, der påvirker Linode Kubernetes Engine (LKE). Vi vil dele yderligere opdateringer, da vi har flere oplysninger.

2. 13. august 2026 kl. 16.30 UTCmonitoring

   På nuværende tidspunkt har vi været i stand til at korrigere de spørgsmål, der berører LKE-tjenesten. Vi vil overvåge dette for at sikre, at det forbliver stabilt. Hvis du fortsætter med at opleve problemer, skal du åbne en Support billet for hjælp.

3. 13. august 2026 kl. 17.54 UTCresolved

   Vi har ikke observeret nogen yderligere problemer med LKE service, og vil nu overveje denne hændelse løst. Hvis du fortsætter med at opleve problemer, skal du åbne en Support billet for hjælp.

4. 17. august 2026 kl. 21.30 UTCpostmortem

   Begynder på ca. 14: 50 UTC den August 13, 2026, kunder, der forsøgte at levere Linode Kubernetes Engine Enterprise\ (LKE- E\) klynger i IAD2 datacenter var ude af stand til. Vi identificerede, at problemet skyldtes udelukkelse af to komponenter i IAD2 i en nylig softwareversion opgradering, som resulterede i en API mismatch. Vi opdaterede de identificerede komponenter for at bringe dem i synkronisering med den forventede tilstand. Dette mindskede problemet omkring kl. 16: 00 UTC den 13. august 2026. For at forhindre dette problem i at forekomme i fremtiden, vi gennemgår LKE software opdatering processer for at sikre, at alle inkluderede komponenter fuldføre version opgraderinger, før de genintroduceres til service under platform software opdateringer. Dette resumé giver et overblik over vores nuværende forståelse af hændelsen i betragtning af de tilgængelige oplysninger. Vores undersøgelse er i gang, og alle oplysninger heri kan ændres.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 14. august 2026 kl. 15.46 UTCresolved

   On August 13, 2026, between approximately 14:00-16:30 UTC, we observed intermittent failures and delays when provisioning new LKE-E clusters in the Seattle (SEA1) region. The issue affecting the LKE-E service in Seattle self-corrected at approximately 16:30 UTC, and we have not observed a recurrence since. We are actively investigating the cause. We will continue to monitor the service for stability. If you experience any problems with this service, please open a Support ticket for assistance.

2. 21. august 2026 kl. 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.

1. 10. august 2026 kl. 17.15 UTCinvestigating

   Vores team undersøger et opstrøms problem, der påvirker Ubuntu deployeringer. Dette kan påvirke evnen til at installere pakke og sikkerhedsopdateringer på alle Ubuntu-systemer.

2. 11. august 2026 kl. 23.35 UTCinvestigating

   Vi fortsætter med at undersøge dette spørgsmål. De relevante fageksperter er engageret. Efterfølgende opdateringer omkring afbødning status vil blive bogført som fremskridt er gjort.

3. 12. august 2026 kl. 03.29 UTCidentified

   Vi har identificeret årsagen til problemet, og der gennemføres et fix. Vi vil give en opdatering, så snart løsningen er på plads.

4. 21. august 2026 kl. 18.40 UTCresolved

   Vi kan bekræfte, at spørgsmålet blev afbødet kl 06: 30 UTC den 20 august 2026 og tjenesten har genoptaget normale operationer.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 31. juli 2026 kl. 17.49 UTCinvestigating

   Vores team undersøger pakketab på nogle stier fra in-maa & in-bom-2 datacentre ind i den amerikanske region. I løbet af denne tid, kan brugerne opleve forbindelse timeouts og fejl med tjenester, der kører mellem Indien og USA regioner. Vi vil dele yderligere opdateringer, da vi har flere oplysninger.

2. 31. juli 2026 kl. 18.25 UTCidentified

   Vores team har identificeret årsagen til pakketab til vores amerikanske datacentre. Vi arbejder med vores opstrømsleverandør for at løse dette problem, og vi vil levere en opdatering, så snart løsningen er på plads.

3. 4. august 2026 kl. 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 kl. 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 kl. 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.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 28. juli 2026 kl. 18.14 UTCinvestigating

   Vores team undersøger et problem, der påvirker Block Storage service i flere data center regioner. Dette spørgsmål i høj grad påvirker fastgørelse og løsrivning Block Storage mængder. I løbet af denne tid, kan brugerne opleve volumen vedhæftet / løsrevet hænger, timeouts og fejl med denne service. Vi vil dele yderligere opdateringer, da vi har flere oplysninger.

2. 28. juli 2026 kl. 19.27 UTCidentified

   Vores team har identificeret problemet, der påvirker Block Storage service i vores datacentre. Vi arbejder hurtigt på at gennemføre en rettelse, og vi vil levere en opdatering, så snart løsningen er på plads.

3. 28. juli 2026 kl. 20.17 UTCidentified

   Vi vil gerne opdatere, at efter yderligere undersøgelse, virkningen ville manifestere sig i forsinkede og undertiden mislykkede værtsjob, som kunne omfatte mange forskellige handlinger på Linodes og ikke kun påvirke fastgørelse og løsrivning Block Storage mængder, som vi nævnte i vores første opdatering, vi har opdateret titlen til at afspejle den opdaterede virkning. Vi arbejder hurtigt på at gennemføre en rettelse, og vi vil levere en opdatering, så snart løsningen er på plads.

4. 28. juli 2026 kl. 22.51 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

5. 29. juli 2026 kl. 12.27 UTCresolved

   Vi har ikke observeret nogen yderligere host job ydeevne nedbrydning problemer, og vil nu overveje denne hændelse løst. Hvis du fortsætter med at opleve problemer, skal du åbne en Support billet for hjælp.

6. 31. juli 2026 kl. 18.57 UTCpostmortem

   Den 27. juli 2026 kl. 3: 30 UTC, Akamai observeret en stigning i fejl, når forbindelse til Linode hosting database, primært påvirker Block Storage volumen vedhæftede filer. Dette resulterede i host job fiaskoer og begrænset kundeeffekt, med nogle brugere oplever fejlmeddelelser og afbrudt arbejdsgange. Forhøjede timeout satser blev bemærket i logfiler for visse data center steder, der falder sammen med den trinvise udrulning af en ny funktion flag. Den første undersøgelse afslørede periodiske pakkedråber fra databaseproxy til klient værter under TLS håndtryk. Den nuværende teori tyder på, at en DDoS-beskyttelse grænse relateret til sti MTU pakke for store ICMP-meddelelser blev nået. Når proxy sendt TCP pakker med en stor MTU, de forventede ICMP-meddelelser blev droppet af Dallas gateway routere på grund af overskridelse af den konfigurerede tilladte sats. Dette forårsagede database proxy TCP-forbindelser til timeout til Compute Hosts. Problemet blev udløst af muligheden for den nye funktion flag, som ændrede routing sti og fjernet MTU fastspænding før pakkerne nåede gateways. For at afbøde problemet, Akamai rullede tilbage den seneste netværksændring på tværs af berørte Compute sites, startende ved 20: 50 UTC. Fra 22: 57 UTC, hastigheden af service genstarter tilbage til præ-hændelse niveauer. Akamai planlægger også en ændring for at øge den tilladte tærskel for pakker for store ICMP-meddelelser. Dette resumé giver et overblik over vores nuværende forståelse af hændelsen i betragtning af de tilgængelige oplysninger. Vores undersøgelse er i gang, og alle oplysninger heri kan ændres.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 20. juli 2026 kl. 01.52 UTCinvestigating

   Vores team er i øjeblikket ved at undersøge en forbindelse problem påvirker Linodes i Italien (Milano) regionen. I løbet af denne tid, kan eksisterende Linodes i dette sted være utilgængelig. Bemærk venligst, at oprettelse af nye Linodes fungerer normalt og forbliver upåvirket.

2. 20. juli 2026 kl. 02.56 UTCinvestigating

   Vi fortsætter med at undersøge dette spørgsmål. Vi vil levere den næste opdatering, når vi gør fremskridt.

3. 20. juli 2026 kl. 03.12 UTCinvestigating

   Vores team har identificeret problemet, der påvirker forbindelse i vores Milan (Italien) datacenter. Vi arbejder hurtigt på at gennemføre en rettelse, og vi vil levere en opdatering, så snart løsningen er på plads.

4. 20. juli 2026 kl. 03.20 UTCmonitoring

   På nuværende tidspunkt har vi været i stand til at korrigere de problemer, der påvirker forbindelse i vores Milano (Italien) datacenter. Vi vil overvåge dette for at sikre, at det forbliver stabilt. Hvis du stadig oplever problemer, bedes du åbne en Support billet for hjælp.

5. 20. juli 2026 kl. 04.10 UTCresolved

   Vi har ikke observeret nogen yderligere forbindelsesproblemer i vores Milan (Italien) datacenter og vil nu overveje denne hændelse løst. Hvis du fortsætter med at opleve problemer, skal du åbne en Support billet for hjælp.

6. 20. juli 2026 kl. 05.45 UTCpostmortem

   Fra omkring 00: 33 UTC den 20 juli 2026, nogle værter i Milano, Italien datacentret blev ikke tilgængelig, påvirker kundeadgang til Linodes. Undersøgelsen viste, at dette problem opstod under planlagte router firmware opdateringer. Mens vi følger en gradvis opgradering proces for at forhindre serviceforstyrrelser, et uventet kryds af samtidige vedligeholdelsesaktiviteter førte til et midlertidigt tab af netværksforbindelse for de berørte værter. Tjenesten blev fuldt restaureret af 02: 16 UTC den 20. juli 2026, og alle systemer fungerer nu som forventet. Internt gennemgår vi vores ændringsstyrings- og vedligeholdelsesplanlægningsprocedurer for at sikre bedre koordinering og forhindre lignende problemer i fremtiden. Vi undskylder for virkningen og takker dig for din tålmodighed og fortsatte støtte. Vi er forpligtet til at foretage løbende forbedringer for at forbedre vores systemer og forhindre gentagelser. Dette resumé giver et overblik over vores nuværende forståelse af hændelsen i betragtning af de tilgængelige oplysninger. Vores undersøgelse er i gang, og alle oplysninger heri kan ændres.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 18. juli 2026 kl. 03.34 UTCinvestigating

   Vores team undersøger et problem, der påvirker Objekt Storage service. I løbet af denne tid, kan brugerne opleve forbindelse timeouts og fejl med denne service.

2. 18. juli 2026 kl. 03.54 UTCidentified

   Vores team har identificeret problemet, der påvirker Objekt Storage service. Vi arbejder hurtigt på at gennemføre en rettelse, og vi vil levere en opdatering, så snart løsningen er på plads.

3. 18. juli 2026 kl. 04.36 UTCresolved

   Vi har ikke observeret nogen yderligere problemer med Objekt Storage service, og vil nu overveje denne hændelse løst. Hvis du fortsætter med at opleve problemer, skal du åbne en Support billet for hjælp.

4. 21. juli 2026 kl. 15.26 UTCpostmortem

   Den 18. juli 2026, mellem ca. 00: 30 UTC og 04: 00 UTC, brugere kan have oplevet 5xx fejl, mens de forsøger at skabe en ny spand i Objekt Storage for følgende endepunkter. * [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) The problem begyndte, da infrastrukturen understøtter Objekt Storage trådte en forringet tilstand på tværs af alle knudepunkter. Dette forhindrede tjenesten i at behandle anmodninger, hvilket resulterede i svigt i forbindelse med oprettelse af skovle. For at afbøde virkningen, har vi anvendt en rettelse på backend system ansvarlig for skovl skabelse. Virkningen blev afbødet efter denne handling. Vores fageksperter undersøger årsagen og vil træffe passende forebyggende foranstaltninger. Vi undskylder for virkningen og værdsætter din tålmodighed og løbende støtte. Vi foretager konfigurationer og operationelle ændringer af vores systemer for at hjælpe med at forhindre dette i at ske igen, og er fortsat forpligtet til løbende forbedringer. Denne oversigt giver et overblik over vores nuværende forståelse af hændelsen, i betragtning af de tilgængelige oplysninger. Vores undersøgelse er i gang, og alle oplysninger heri kan ændres.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 16. juli 2026 kl. 01.24 UTCresolved

   Vores team undersøgte et problem, der påvirkede forbindelse i vores US- MIA (Miami) datacenter mellem 21: 20 UTC og ca. 23: 28 UTC den 15. juli 2026. I dette vindue, kan brugerne have oplevet forringet netværk ydeevne og pakkelab for Compute-tjenester, der anvendes i denne region. Problemet blev løst efter vi implementerede et fix. Vi fortsætter med at arbejde med vores tredjeparts service udbyder til at bekræfte den grundlæggende årsag, som indledende beviser peger på en campus cross-connect (mørk fiber) udfald på deres infrastruktur.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 14. juli 2026 kl. 12.21 UTCinvestigating

   Vores team undersøger et nyt serviceproblem, der påvirker API og CLI. Vi vil dele yderligere opdateringer, da vi har flere oplysninger.

2. 14. juli 2026 kl. 12.58 UTCidentified

   Vores team har identificeret problemet påvirker Cloud Manager og API. Vi arbejder hurtigt på at gennemføre en rettelse, og vi vil levere en opdatering, så snart løsningen er på plads.

3. 14. juli 2026 kl. 13.11 UTCmonitoring

   På dette tidspunkt har vi været i stand til at rette problemet påvirker Cloud Manager og API. Vi vil overvåge dette for at sikre, at tjenesten forbliver stabil. Hvis du stadig oplever problemer og ikke kan åbne en Support billet, bedes du ringe til os på 855- 454- 6633 (+ 1-609- 380- 7100 Intl.), eller sende en e-mail til support @ linode.com.

4. 14. juli 2026 kl. 18.36 UTCmonitoring

   Vi fortsætter med at overvåge for yderligere spørgsmål.

5. 14. juli 2026 kl. 19.26 UTCresolved

   Vi har ikke observeret nogen yderligere problemer med Cloud Manager, API, eller CLI, og vil nu overveje denne hændelse løst. Hvis du fortsætter med at opleve problemer, bedes du kontakte os på 855- 454- 6633 (+ 1- 609- 380- 7100 Intl.), eller sende en e-mail til support @ linode.com for hjælp.

6. 16. juli 2026 kl. 18.13 UTCpostmortem

   Den 14. juli 2026, på 10: 57 UTC, Akamai identificeret en stigning i 502 fejl og latency påvirker kunder, der bruger Linode API, CLI, og Cloud Manager. Denne afbrydelse resulterede i moderat serviceeffekt, hvor kunderne rapporterede forhøjede fejlrater. Vores første undersøgelse sporede problemet til latency med IAM-tjenester, som blev løst, men forhøjede fejl fortsatte. Yderligere analyse af relevante fageksperter fastslog, at hændelsen blev udløst af en manuel svigt i Cloud IAM primær belastning balancer fra den sekundære belastning balancer. Denne handling var foranlediget af en advarsel om, at den sekundære belastning balancer fungerede som vedligeholdt master. Den manuelle proces med at starte og stoppe tjenester til at indlede failback afveg fra den automatiserede proces og førte til en kaskade af gamle GRPC-forbindelser, forårsager øget latency og API fejl. Genstart API-servere ryddet de gamle forbindelser og genoprettet normale operationer. Kundeeffekten blev mindsket med ca. 13: 10 UTC den 14. juli 2026. For at forhindre tilbagefald undersøger Akamai, hvorfor den manuelle fiasko forårsagede denne adfærd. Holdet overvejer at implementere en drænkommando til at rydde GRPC-forbindelser under failover og oprette advarsler til at opdage dårlige forbindelser til proaktiv intervention. Men det umiddelbare fokus er fortsat at forstå den grundlæggende årsag, med alarmering og automatisering planlagt til senere faser. Flere kunder har bekræftet resolution på tværs af deres deployeringer. Akamai vil fortsætte med at overvåge systemets sundhed og afventer yderligere kundefeedback, før du erklærer fuld opsving. Dette resumé giver et overblik over vores nuværende forståelse af hændelsen i betragtning af de tilgængelige oplysninger. Vores undersøgelse er i gang, og alle oplysninger heri kan ændres.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 13. juli 2026 kl. 18.29 UTCidentified

   Vores team har identificeret et nyt serviceproblem, der påvirker værtsjob for nogle værter i alle regioner. Linode forbindelse er * ikke påvirket *, men nogle host- level job, såsom sikkerhedskopier eller forsøg på at strøm på eller fra dine tjenester kan blive forsinket. Vi vil dele yderligere opdateringer, da vi har flere oplysninger.

2. 13. juli 2026 kl. 19.54 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 9. juli 2026 kl. 16.57 UTCinvestigating

   Vores team undersøger et nyt serviceproblem, der påvirker Cloud Manager logins. Vi vil dele yderligere opdateringer, da vi har flere oplysninger.

2. 9. juli 2026 kl. 17.24 UTCinvestigating

   Vi fortsætter med at undersøge dette spørgsmål. Vi vil levere en opdatering inden for de næste 30 minutter.

3. 9. juli 2026 kl. 17.49 UTCmonitoring

   På dette tidspunkt har vi været i stand til at rette problemet påvirker Cloud Manager logins. Vi vil overvåge dette for at sikre, at tjenesten forbliver stabil. Hvis du stadig oplever problemer og ikke kan åbne en Support billet, bedes du ringe til os på 855- 454- 6633 (+ 1-609- 380- 7100 Intl.), eller sende en e-mail til support @ linode.com.

4. 9. juli 2026 kl. 18.21 UTCresolved

   Vi har ikke observeret nogen yderligere problemer med Cloud Manager logins og vil nu overveje denne hændelse løst. Hvis du fortsætter med at opleve problemer, bedes du kontakte os på 855- 454- 6633 (+ 1- 609- 380- 7100 Intl.), eller sende en e-mail til support @ linode.com for hjælp.

5. 10. juli 2026 kl. 12.30 UTCpostmortem

   Den 9. juli 2026, på 15: 43 UTC, kunder var ude af stand til at logge ind på [cloud.linode.com] (http: / / cloud.linode.com) ved hjælp af brugernavn og adgangskode. Kunder fik "forkert adgangskode" fejlmeddelelse. Undersøgelsen viste, at spørgsmålet skyldtes en udstedelse af et internt certifikat. For at afbøde virkningen, vi fastsat certifikatet udstedelse på de ramte servere på 17: 24 UTC den 9 juli 2026. Efter at have overvåget vores systemer i nogen tid, bekræftede vi, at spørgsmålet var helt løst. Akamai vil implementere en permanent rettelse for at forhindre en gentagelse af problemet.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 6. juli 2026 kl. 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 kl. 15.31 UTCresolved

   This incident has been resolved.

1. 1. juli 2026 kl. 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 kl. 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 kl. 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 kl. 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 kl. 19.55 UTCinvestigating

   We are continuing to investigate this issue.

3. 30. juni 2026 kl. 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 kl. 21.36 UTCidentified

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

5. 30. juni 2026 kl. 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 kl. 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 kl. 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 kl. 17.35 UTCinvestigating

   Vores team undersøger et problem, der påvirker Cloud Pulse Metrics (ACLP Metrics), specielt påvirker Managed Database Metrics rapportering. Spørgsmålet synes at være intermitterende. Vi vil dele yderligere opdateringer, da vi har flere oplysninger.

2. 26. juni 2026 kl. 18.19 UTCinvestigating

   Vi fortsætter med at undersøge dette spørgsmål. Vi vil dele yderligere opdateringer, da vi har flere oplysninger.

3. 26. juni 2026 kl. 19.08 UTCinvestigating

   Vi fortsætter med at undersøge dette spørgsmål. Vi vil give yderligere opdateringer, da vi har flere oplysninger.

4. 26. juni 2026 kl. 20.04 UTCinvestigating

   Vi fortsætter med at undersøge dette spørgsmål.

5. 26. juni 2026 kl. 21.13 UTCmonitoring

   Vi har ikke observeret en gentagelse af problemet påvirker Cloud Pulse Metrics (ACLP Metrics) i flere timer. Vores team vil fortsætte med at overvåge tjenesten tæt, mens vi undersøger den underliggende årsag. Hvis du fortsætter med at opleve problemer, skal du åbne en Support billet for hjælp.

6. 30. juni 2026 kl. 00.02 UTCmonitoring

   Vi fortsætter med at overvåge for yderligere spørgsmål.

7. 8. juli 2026 kl. 12.26 UTCresolved

   Vi har ikke observeret nogen yderligere problemer med Cloud Pulse Metrics (ACLP Metrics) service, og vil nu overveje denne hændelse løst. Hvis du fortsætter med at opleve problemer, skal du åbne en Support billet for hjælp.

Automatisk oversat fra den officielle hændelsesopdatering.