Istoricul incidentelor Linode

1. 24 august 2026 la 21:52 UTCinvestigating

   Echipa noastră investighează o problemă care afectează serviciul de stocare a obiectelor din SUA-SEA. În acest timp, utilizatorii pot experimenta erori intermitente 5xxx cu acest serviciu.

2. 25 august 2026 la 00:31 UTCinvestigating

   Continuăm să investigăm această problemă.

3. 25 august 2026 la 00:55 UTCidentified

   Problema a fost identificată și se pune în aplicare o soluție.

4. 25 august 2026 la 01:11 UTCresolved

   Am observat orice probleme suplimentare cu serviciul Object Storage, și acum va lua în considerare acest incident rezolvat. Dacă continuaţi să aveţi probleme, vă rugăm să deschideţi un bilet de sprijin pentru asistenţă.

Traducere automată din actualizarea oficială a incidentului.

1. 21 august 2026 la 17:23 UTCinvestigating

   Echipa noastră investighează o problemă de servicii emergente care ne afectează marea (Seattle, WA). Vom împărtăși actualizări suplimentare, deoarece avem mai multe informații.

2. 21 august 2026 la 21:59 UTCresolved

   În acest moment am reuşit să corectăm problema şi serviciul a reluat funcţionarea normală.

Traducere automată din actualizarea oficială a incidentului.

1. 14 august 2026 la 20:13 UTCinvestigating

   Echipa noastră investighează o problemă care afectează conectivitatea în centrul nostru de date IT-MIL (Milan). În acest timp, utilizatorii pot experimenta timeout-uri de conectare intermitente și erori pentru toate serviciile utilizate în acest centru de date. Vom împărtăși actualizări suplimentare, deoarece avem mai multe informații.

2. 14 august 2026 la 21:18 UTCinvestigating

   Continuăm să investigăm această problemă. Vom împărtăși actualizări suplimentare, deoarece avem mai multe informații.

3. 14 august 2026 la 21:30 UTCresolved

   Am observat orice probleme de conectivitate suplimentare în centrul nostru de date IT-MIL (Milan) și va lua în considerare acum acest incident rezolvat. Dacă continuaţi să aveţi probleme, vă rugăm să deschideţi un bilet de sprijin pentru asistenţă.

4. 18 august 2026 la 19:02 UTCpostmortem

   La 14 august 2026, începând cu ora 17:30 UTC, în timpul unui eveniment în centrul nostru de date IT-MIL \ (Milan\), au fost declanșate alerte multiple care indică faptul că mai multe gazde din acest centru de date au devenit inaccesibile. Akamai a început imediat să investigheze problema și să lucreze pentru a restabili gazdele afectate. În timpul ferestrei de impact, clienţii ar fi avut momente intermitente de conectare şi erori în toate serviciile desfăşurate în acest centru de date. Am restaurat gazdele afectate și am rezolvat problemele de conectivitate la 21:20 UTC la 14 august 2026. Încă investigăm cauza stării de eşec. Ne-am angajat să prevenim incidentele viitoare şi vom efectua o investigaţie amănunţită asupra motivelor pentru care gazdele au devenit inaccesibile, punând în aplicare măsuri de sporire a stabilităţii şi fiabilităţii. Acest rezumat oferă o imagine de ansamblu a înțelegerii noastre actuale a incidentului dat informațiile disponibile. Ancheta noastră este în curs de desfăşurare şi orice informaţie de aici este supusă schimbării.

Traducere automată din actualizarea oficială a incidentului.

1. 13 august 2026 la 21:13 UTCinvestigating

   Echipa noastră investighează o problemă care afectează crearea de clustere Linod Kubernetes Engine Enterprise (LKE-E) în centrul de date IAD2 - Washington. Aceasta este o continuare a problemei raportate mai devreme. Vom împărtăși actualizări suplimentare, deoarece avem mai multe informații.

2. 13 august 2026 la 23:02 UTCmonitoring

   A fost implementată o soluţie şi monitorizăm rezultatele.

3. 13 august 2026 la 23:24 UTCresolved

   Acest incident a fost rezolvat.

4. 18 august 2026 la 20:32 UTCpostmortem

   Între 17:25 UTC și 22:50 UTC la 13 august 2026, Linod Kubernetes Engine Enterprise \ (LKE-E\) clienții care încearcă să desfășoare cazuri dedicate G7 în centrul nostru de date din Washington \ (IAD2\) au primit 403 de mesaje de eroare de furnizare. Volumul de muncă activ și cazurile de funcționare nu au fost afectate de această problemă. Ancheta noastră a arătat că, deși capacitatea totală a hardware-ului în IAD2 a fost suficientă, cererea de furnizare a declanșat un eșec al verificării drepturilor din cauza unui prag inițial moale de alocare a gazdelor. Akamai a rezolvat problema prin creșterea limitei de la 5 la 20 în IAD2. Capacitățile de implementare complete au fost restaurate și stabilizate la 22:50 UTC. Pentru a preveni redresarea în viitor, vom pune în aplicare alerte specifice pentru aspecte legate de drepturi și capacitate, legate direct de listele de răspunsuri pentru remedierea rapidă. În plus, construim un tablou centralizat de bord de prezentare a capacităţii pentru a urmări proactiv sala regională. Acest rezumat oferă o imagine de ansamblu a înțelegerii noastre actuale a incidentului dat informațiile disponibile. Ancheta noastră este în curs de desfășurare și orice informație de aici este supusă schimbării.

Traducere automată din actualizarea oficială a incidentului.

1. 13 august 2026 la 18:46 UTCinvestigating

   Echipa noastră investighează o problemă de servicii emergente care afectează API în toate regiunile. Vom împărtăși actualizări suplimentare, deoarece avem mai multe informații.

2. 13 august 2026 la 19:58 UTCmonitoring

   La 19:30 UTC au fost în măsură să corecteze problema care afectează API în toate regiunile. Vom monitoriza acest lucru pentru a ne asigura că serviciul rămâne stabil. Dacă sunteți încă confruntă cu probleme și în imposibilitatea de a deschide un bilet de sprijin , vă rugăm să ne sunați la 855-454-6633 (+1-609-380-7100 Intl.), sau trimiteți un e-mail la [email protected].

3. 13 august 2026 la 19:59 UTCmonitoring

   Continuăm să monitorizăm orice alte probleme.

4. 14 august 2026 la 00:26 UTCresolved

   Acest incident a fost rezolvat.

5. 17 august 2026 la 17:38 UTCpostmortem

   La 13 august 2026, la aproximativ 18:15 UTC, Akamai a observat o scurtă întrerupere de serviciu care afectează [ api.linode.com ](http://api.linode.com). Întreruperea totală a serviciului a durat aproximativ 3 minute, încheind la 18:18 UTC. Ca urmare a restabilirii conectivității inițiale, gradul ridicat de latență a răspunsului API a persistat până la 19:06 UTC, cauzând perioade de răspuns mai lente și întârzieri intermitente pentru clienții care interacționează cu serviciile API. Pentru a aborda impactul de performanță, echipele de inginerie Akamai au identificat o discrepanță de configurare a nodului secundar al infrastructurii de cache care a împiedicat-o să absoarbă întreaga încărcătură de trafic după eșuare. Inginerii au finalizat o migrare controlată și au mutat cache-ul traficului înapoi la gazda principală. În urma acestei modificări, latenţa API a scăzut rapid la nivele normale operaţionale. Condiţia iniţială a fost declanşată de o repornire neaşteptată a gazdei fizice a nodului primar. În timp ce infrastructura redundantă era activă, nodul secundar nu a reușit să proceseze fără probleme traficul, cauzând degradarea extinsă a performanței. Echipele noastre de inginerie efectuează o investigaţie de urmărire a mecanismelor eşuate pentru optimizarea vitezelor de execuţie şi alinierea setărilor de configurare între nodurile redundante, asigurând că sistemele secundare pot gestiona traficul fără probleme în evenimentele viitoare. Acest rezumat oferă o imagine de ansamblu a înțelegerii noastre actuale a incidentului dat informațiile disponibile. Ancheta noastră este în curs de desfășurare și orice informație de aici este supusă schimbării.

Traducere automată din actualizarea oficială a incidentului.

1. 13 august 2026 la 16:16 UTCinvestigating

   Echipa noastră investighează o problemă care afectează motorul Linod Kubernetes (LKE). Vom împărtăși actualizări suplimentare, deoarece avem mai multe informații.

2. 13 august 2026 la 16:30 UTCmonitoring

   În acest moment am reușit să corectăm problemele care afectează serviciul LKE. Vom monitoriza acest lucru pentru a ne asigura că rămâne stabil. Dacă continuaţi să aveţi probleme, vă rugăm să deschideţi un bilet de sprijin pentru asistenţă.

3. 13 august 2026 la 17:54 UTCresolved

   Am observat orice probleme suplimentare cu serviciul LKE, și va lua în considerare acum acest incident rezolvat. Dacă continuaţi să aveţi probleme, vă rugăm să deschideţi un bilet de sprijin pentru asistenţă.

4. 17 august 2026 la 21:30 UTCpostmortem

   Începând cu aproximativ 14:50 UTC la 13 august 2026, clienții care au încercat să furnizeze Linod Kubernetes Engine Enterprise \ (LKE-E\) clustere în centrul de date IAD2. Am identificat faptul că problema s-a datorat excluderii a două componente din IAD2 într-o actualizare recentă a versiunii software, care a dus la o nepotrivire API. Am actualizat componentele identificate pentru a le sincroniza cu starea aşteptată. Acest lucru a atenuat problema la aproximativ 16:00 UTC la 13 august 2026. Pentru a preveni apariția acestei probleme în viitor, revizuim procesele de actualizare a software-ului LKE pentru a ne asigura că toate componentele incluse completează actualizările versiunii înainte de a fi reintroduse în funcțiune în timpul actualizărilor software-ului platformei. Acest rezumat oferă o imagine de ansamblu a înțelegerii noastre actuale a incidentului dat informațiile disponibile. Ancheta noastră este în curs de desfășurare și orice informație de aici este supusă schimbării.

Traducere automată din actualizarea oficială a incidentului.

1. 14 august 2026 la 15:46 UTCresolved

   La 13 august 2026, între orele 14:00-16:30 UTC, am observat eșecuri intermitente și întârzieri în furnizarea de noi grupuri LKE-E în regiunea Seattle (SEA1). Problema care afectează serviciul LKE-E în Seattle auto-corectat la aproximativ 16:30 UTC, și nu am observat o recurență de atunci. Investigăm în mod activ cauza. Vom continua să monitorizăm serviciul pentru stabilitate. Dacă aveţi probleme cu acest serviciu, vă rugăm să deschideţi un bilet de sprijin pentru asistenţă.

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

Traducere automată din actualizarea oficială a incidentului.

1. 10 august 2026 la 17:15 UTCinvestigating

   Echipa noastră investighează o problemă în amonte care afectează desfăşurarea Ubuntu. Acest lucru poate afecta capacitatea de a instala pachete și actualizări de securitate pe toate sistemele Ubuntu.

2. 11 august 2026 la 23:35 UTCinvestigating

   Continuăm să investigăm această problemă. Sunt angajaţi experţii în materie corespunzătoare. Actualizările ulterioare privind starea de atenuare vor fi postate pe măsură ce se înregistrează progrese.

3. 12 august 2026 la 03:29 UTCidentified

   Am identificat cauza problemei și se pune în aplicare o soluție. Vom oferi o actualizare de îndată ce soluția este în vigoare.

4. 21 august 2026 la 18:40 UTCresolved

   Putem confirma că problema a fost atenuată la 06:30 UTC la 20 august 2026 și serviciul a reluat operațiunile normale.

Traducere automată din actualizarea oficială a incidentului.

1. 31 iulie 2026 la 17:49 UTCinvestigating

   Echipa noastră investighează pierderea pachetelor pe câteva căi de la centrele de date in-maa & in-bom-2 în regiunea SUA. În acest timp, utilizatorii pot experimenta timeout-uri de conectare și erori cu servicii care traversează între India și regiunile Statelor Unite. Vom împărtăși actualizări suplimentare, deoarece avem mai multe informații.

2. 31 iulie 2026 la 18:25 UTCidentified

   Echipa noastră a identificat cauza pierderii pachetelor către centrele noastre de date din SUA. Lucrăm cu furnizorul nostru din amonte pentru a rezolva această problemă și vom oferi o actualizare de îndată ce soluția este în vigoare.

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

Traducere automată din actualizarea oficială a incidentului.

1. 28 iulie 2026 la 18:14 UTCinvestigating

   Echipa noastră investighează o problemă care afectează serviciul Block Storage în mai multe regiuni din centrul de date. Această problemă afectează în mare măsură ataşarea şi detaşarea volumelor de stocare în bloc. În acest timp, utilizatorii pot experimenta volum atasat / detasare atarna, timeouts si erori cu acest serviciu. Vom împărtăși actualizări suplimentare, deoarece avem mai multe informații.

2. 28 iulie 2026 la 19:27 UTCidentified

   Echipa noastră a identificat problema care afectează serviciul Block Storage în centrele noastre de date. Lucrăm rapid pentru a pune în aplicare un fix, și vom oferi o actualizare de îndată ce soluția este în vigoare.

3. 28 iulie 2026 la 20:17 UTCidentified

   Am dori să actualizăm faptul că, după o investigaţie suplimentară, impactul s-ar manifesta în locurile de muncă gazdă întârziate şi uneori eşuate, care ar putea include multe acţiuni diferite asupra Linodesului şi nu numai că ar afecta ataşarea şi detaşarea volumelor de stocare a blocului, aşa cum am menţionat în actualizarea iniţială, am actualizat titlul pentru a reflecta impactul actualizat. Lucrăm rapid pentru a pune în aplicare un fix, și vom oferi o actualizare de îndată ce soluția este în vigoare.

4. 28 iulie 2026 la 22:51 UTCmonitoring

   A fost implementată o soluţie şi monitorizăm rezultatele.

5. 29 iulie 2026 la 12:27 UTCresolved

   Nu am observat nici o problemă suplimentară de degradare a performanței de locuri de muncă gazdă, și vom lua în considerare acum acest incident rezolvat. Dacă continuaţi să aveţi probleme, vă rugăm să deschideţi un bilet de sprijin pentru asistenţă.

6. 31 iulie 2026 la 18:57 UTCpostmortem

   La 27 iulie 2026 la 3:30 UTC, Akamai a observat o creștere a erorilor atunci când s-a conectat la baza de date de găzduire a Linodului, afectând în principal atașamentele de volum Block Storage. Acest lucru a dus la eșecuri de locuri de muncă gazdă și impactul limitat al clienților, unii utilizatori experimentând mesaje de eroare și fluxuri de lucru întrerupte. Ratele ridicate de timeout au fost notate în jurnale pentru anumite locații ale centrului de date, coincidend cu introducerea incrementală a unui nou pavilion caracteristică. Investigația inițială a dezvăluit picături intermitente de pachete de la proxy baza de date la gazde client în timpul strângerea de mână TLS. Teoria actuală sugerează că a fost atinsă o limită de protecţie DDoS legată de pachetul de cale MTU prea mare mesaje ICMP. Atunci când proxy a trimis pachete TCP cu o MTU mare, mesajele ICMP preconizate au fost retrase de către routere gateway Dallas datorită depășirii ratei admisibile configurate. Acest lucru a cauzat conexiunile proxy baza de date TCP la timeout la Compute Gazde. Problema a fost declanșată de activarea noului steag de caracteristică, care a schimbat traseul de rutare și a îndepărtat prinderea MTU înainte ca pachetele să ajungă la porți. Pentru a atenua această problemă, Akamai a reluat recenta schimbare a rețelei pe site-urile de calcul afectate, începând cu ora 20:50 UTC. Începând cu 22:57 UTC, rata de repornire a serviciului a revenit la nivelurile pre-incidente. Akamai planifică, de asemenea, o schimbare pentru a mări pragul admisibil pentru pachetele de mesaje ICMP prea mari. Acest rezumat oferă o imagine de ansamblu a înțelegerii noastre actuale a incidentului dat informațiile disponibile. Ancheta noastră este în curs de desfășurare și orice informație de aici este supusă schimbării.

Traducere automată din actualizarea oficială a incidentului.

1. 20 iulie 2026 la 01:52 UTCinvestigating

   Echipa noastră investighează în prezent o problemă de conectivitate care afectează Linodes în regiunea Italia (Milan). În acest timp, Linodele existente în această locație pot fi inaccesibile. Vă rugăm să rețineți că crearea de noi Linodes funcționează normal și rămâne neafectată.

2. 20 iulie 2026 la 02:56 UTCinvestigating

   Continuăm să investigăm această problemă. Vom furniza următoarea actualizare pe măsură ce facem progrese.

3. 20 iulie 2026 la 03:12 UTCinvestigating

   Echipa noastră a identificat problema care afectează conectivitatea în centrul nostru de date din Milano (Italia). Lucrăm rapid pentru a pune în aplicare un fix, și vom oferi o actualizare de îndată ce soluția este în vigoare.

4. 20 iulie 2026 la 03:20 UTCmonitoring

   În acest moment, am reușit să corectăm problemele care afectează conectivitatea în centrul nostru de date din Milano (Italia). Vom monitoriza acest lucru pentru a ne asigura că rămâne stabil. Dacă vă confruntați încă cu probleme, vă rugăm să deschideți un bilet de sprijin pentru asistență.

5. 20 iulie 2026 la 04:10 UTCresolved

   Am observat orice probleme de conectivitate suplimentare în centrul nostru de date Milano (Italia) și va lua în considerare acum acest incident rezolvat. Dacă continuaţi să aveţi probleme, vă rugăm să deschideţi un bilet de sprijin pentru asistenţă.

6. 20 iulie 2026 la 05:45 UTCpostmortem

   Începând cu aproximativ 00:33 UTC pe 20 iulie 2026, unele gazde din Milano, centrul de date Italia a devenit indisponibil, impactul accesului clienților la Linodes. Ancheta a identificat faptul că această problemă a avut loc în timpul actualizărilor regulate ale firmei de router. În timp ce urmăm un proces de actualizare progresivă pentru a preveni perturbarea serviciilor, o intersecție neașteptată a activităților de întreținere concomitentă a dus la o pierdere temporară a conectivității la rețea pentru gazdele afectate. Serviciul a fost restaurat complet până la ora 02:16 UTC pe 20 iulie 2026, iar toate sistemele funcţionează acum conform aşteptărilor. Pe plan intern, revizuim procedurile de gestionare a schimbărilor și de planificare a întreținerii pentru a asigura o mai bună coordonare și pentru a preveni problemele similare în viitor. Ne cerem scuze pentru impact și vă mulțumim pentru răbdare și sprijin continuu. Ne-am angajat să facem îmbunătățiri continue pentru a face sistemele noastre mai bune și pentru a preveni recurența. Acest rezumat oferă o imagine de ansamblu a înțelegerii noastre actuale a incidentului dat informațiile disponibile. Ancheta noastră este în curs de desfăşurare şi orice informaţie de aici este supusă schimbării.

Traducere automată din actualizarea oficială a incidentului.

1. 18 iulie 2026 la 03:34 UTCinvestigating

   Echipa noastră investighează o problemă care afectează serviciul de stocare a obiectelor. În acest timp, utilizatorii pot experimenta timeout-uri de conectare și erori cu acest serviciu.

2. 18 iulie 2026 la 03:54 UTCidentified

   Echipa noastră a identificat problema care afectează serviciul Object Storage. Lucrăm rapid pentru a pune în aplicare un fix, și vom oferi o actualizare de îndată ce soluția este în vigoare.

3. 18 iulie 2026 la 04:36 UTCresolved

   Am observat orice probleme suplimentare cu serviciul Object Storage, și acum va lua în considerare acest incident rezolvat. Dacă continuaţi să aveţi probleme, vă rugăm să deschideţi un bilet de sprijin pentru asistenţă.

4. 21 iulie 2026 la 15:26 UTCpostmortem

   Pe 18 iulie 2026, între aproximativ 00:30 UTC și 04:00 UTC, utilizatorii ar fi putut experimenta erori 5xx în timp ce încercau să creeze o nouă găleată în Object Storage pentru următoarele obiective finale. * [us-ord-1.linodeobjects.com](http://us-ord-1.linodeobjects.com) * [us-lax-1.linodoobjects.com](http://us-lax-1.linodeobjects.com) * [us-iad-1.linodoobjects.com](http://us-iad-1.linodeobjects.com) * [us-sea-1.linodoobjects.com](http://us-sea-1.linodeobjects.com) * [fr-par-1.linodeobjects.com](http://fr-par-1.linodeobjects.com) Acest lucru a împiedicat serviciul să proceseze cererile, ceea ce a dus la eșecuri în timpul operațiunilor de creare a găleții. Pentru a atenua impactul, am aplicat un fix la sistemul de suport responsabil pentru crearea găleții. Impactul a fost atenuat în urma acestei acțiuni. Ne cerem scuze pentru impact şi apreciem răbdarea şi sprijinul continuu. Facem schimbări de configurare și de funcționare ale sistemelor noastre pentru a preveni acest lucru din nou, și rămânem angajați în îmbunătățirea continuă. Ancheta noastră este în curs de desfăşurare şi orice informaţie de aici este supusă schimbării.

Traducere automată din actualizarea oficială a incidentului.

1. 16 iulie 2026 la 01:24 UTCresolved

   Echipa noastră a investigat o problemă care a afectat conectivitatea în centrul nostru de date US-MIA (Miami) între 21:20 UTC și aproximativ 23:28 UTC pe 15 iulie 2026. În timpul acestei ferestre, este posibil ca utilizatorii să fi experimentat performanţe de reţea degradate şi pierderi de pachete pentru serviciile de calcul utilizate în această regiune. Problema a fost rezolvată după ce am pus în aplicare un fix. Continuăm să lucrăm cu furnizorul nostru de servicii terţe părţi pentru a confirma cauza principală, deoarece dovezile iniţiale indică o întrerupere a conexiunii campusului (fibra neagră) pe infrastructura lor.

Traducere automată din actualizarea oficială a incidentului.

1. 14 iulie 2026 la 12:21 UTCinvestigating

   Echipa noastră investighează o problemă de servicii emergente care afectează API și CLI. Vom împărtăși actualizări suplimentare, deoarece avem mai multe informații.

2. 14 iulie 2026 la 12:58 UTCidentified

   Echipa noastră a identificat problema care afectează Cloud Manager și API. Lucrăm rapid pentru a pune în aplicare un fix, și vom oferi o actualizare de îndată ce soluția este în vigoare.

3. 14 iulie 2026 la 13:11 UTCmonitoring

   În acest moment am reușit să corectăm problema care afectează Cloud Manager și API. Vom monitoriza acest lucru pentru a ne asigura că serviciul rămâne stabil. Dacă sunteți încă confruntă cu probleme și în imposibilitatea de a deschide un bilet de sprijin , vă rugăm să ne sunați la 855-454-6633 (+1-609-380-7100 Intl.), sau trimiteți un e-mail la [email protected].

4. 14 iulie 2026 la 18:36 UTCmonitoring

   Continuăm să monitorizăm orice alte probleme.

5. 14 iulie 2026 la 19:26 UTCresolved

   Nu am observat nici o problemă suplimentară cu Managerul Cloud, API, sau CLI, și va lua în considerare acum acest incident rezolvat. Dacă continuați să experimentați probleme, vă rugăm să ne contactați la 855-454-6633 (+1-609-380-7100 Intl.), sau trimiteți un e-mail la [email protected] pentru asistență.

6. 16 iulie 2026 la 18:13 UTCpostmortem

   La 14 iulie 2026, la 10:57 UTC, Akamai a identificat o creștere de 502 de erori și latență care afectează clienții folosind API, CLI și Cloud Manager. Această întrerupere a avut ca rezultat un impact moderat asupra serviciilor, clienții raportând rate ridicate de eroare. Ancheta noastră iniţială a urmărit problema latenţiei cu serviciile IAM, care a fost rezolvată, dar erorile ridicate au persistat. Analiza suplimentară efectuată de experții relevanți în materie de materie a stabilit că incidentul a fost declanșat de o revenire manuală la sistemul de echilibrare a sarcinii primare Cloud IAM de la cel secundar. Această acţiune a fost provocată de o alertă de avertizare care indică faptul că balanţa de sarcină secundară acţiona în calitate de maestru menţinut. Procesul manual de pornire și oprire a serviciilor pentru inițierea eșuării diferă de procesul automat și a condus la o cascadă de conexiuni vechi GRC, cauzând latență crescută și erori API. Repornirea serverelor API a eliminat conexiunile vechi și a restaurat operațiunile normale. Impactul asupra clienților a fost atenuat de aproximativ 13:10 UTC la 14 iulie 2026. Pentru a preveni recidiva, Akamai investighează de ce eșecul manual a cauzat acest comportament. Echipa are în vedere implementarea unei comenzi de scurgere pentru a șterge conexiunile GRC în timpul eșuării și pentru a crea alerte pentru detectarea conexiunilor vechi pentru intervenția proactivă. Cu toate acestea, accentul imediat rămâne pus pe înțelegerea cauzei profunde, cu alertă și automatizare planificate pentru fazele ulterioare. Mai mulţi clienţi şi-au confirmat rezoluţia pe parcursul desfăşurărilor lor. Akamai va continua să monitorizeze sistemul de sănătate și așteaptă feedback-ul suplimentar al clienților înainte de a declara recuperarea completă. Acest rezumat oferă o imagine de ansamblu a înțelegerii noastre actuale a incidentului dat informațiile disponibile. Ancheta noastră este în curs de desfășurare și orice informație de aici este supusă schimbării.

Traducere automată din actualizarea oficială a incidentului.

1. 13 iulie 2026 la 18:29 UTCidentified

   Echipa noastră a identificat o problemă de servicii emergente care afectează locurile de muncă ale gazdelor pentru unele gazde din toate regiunile. Conectivitatea la linod este * neafectată*, dar unele locuri de muncă la nivelul gazdelor, cum ar fi rezervări sau încercări de a alimenta sau de pe serviciile dumneavoastră pot fi întârziate. Vom împărtăși actualizări suplimentare, deoarece avem mai multe informații.

2. 13 iulie 2026 la 19:54 UTCresolved

   Acest incident a fost rezolvat.

Traducere automată din actualizarea oficială a incidentului.

1. 9 iulie 2026 la 16:57 UTCinvestigating

   Echipa noastră investighează o problemă de servicii emergente care afectează autentificările Cloud Manager. Vom împărtăși actualizări suplimentare, deoarece avem mai multe informații.

2. 9 iulie 2026 la 17:24 UTCinvestigating

   Continuăm să investigăm această problemă. Vom oferi o actualizare în următoarele 30 de minute.

3. 9 iulie 2026 la 17:49 UTCmonitoring

   În acest moment am reușit să corectăm problema care afectează loginurile Cloud Manager. Vom monitoriza acest lucru pentru a ne asigura că serviciul rămâne stabil. Dacă sunteți încă confruntă cu probleme și în imposibilitatea de a deschide un bilet de sprijin , vă rugăm să ne sunați la 855-454-6633 (+1-609-380-7100 Intl.), sau trimiteți un e-mail la [email protected].

4. 9 iulie 2026 la 18:21 UTCresolved

   Nu am observat alte probleme cu autentificarile de la Cloud Manager si acum vom considera acest incident rezolvat. Dacă continuați să experimentați probleme, vă rugăm să ne contactați la 855-454-6633 (+1-609-380-7100 Intl.), sau trimiteți un e-mail la [email protected] pentru asistență.

5. 10 iulie 2026 la 12:30 UTCpostmortem

   La 9 iulie 2026, la 15:43 UTC, clienții nu s-au putut conecta la [cloud.linode.com][http://cloud.linode.com] folosind numele de utilizator și parola. Clienţii primeau un mesaj de eroare cu parola greşită. Ancheta a arătat că problema a fost cauzată de eliberarea unui certificat intern. Pentru a atenua impactul, am stabilit eliberarea certificatului pe serverele afectate la ora 17:24 UTC la 9 iulie 2026. După ce ne-am monitorizat sistemele de ceva timp, am confirmat că problema a fost rezolvată pe deplin. Akamai va implementa un fix permanent pentru a preveni repetarea problemei.

Traducere automată din actualizarea oficială a incidentului.

1. 6 iulie 2026 la 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 iulie 2026 la 15:31 UTCresolved

   This incident has been resolved.

1. 1 iulie 2026 la 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 iulie 2026 la 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 iulie 2026 la 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 iunie 2026 la 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 iunie 2026 la 19:55 UTCinvestigating

   We are continuing to investigate this issue.

3. 30 iunie 2026 la 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 iunie 2026 la 21:36 UTCidentified

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

5. 30 iunie 2026 la 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 iunie 2026 la 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 iulie 2026 la 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 iunie 2026 la 17:35 UTCinvestigating

   Echipa noastra investigheaza o problema care afecteaza Metricea Pulselor Cloud (ACLP Metrics), care are impact in mod special asupra rapoartelor de baza de date. Problema pare să fie intermitentă. Vom împărtăși actualizări suplimentare, deoarece avem mai multe informații.

2. 26 iunie 2026 la 18:19 UTCinvestigating

   Continuăm să investigăm această problemă. Vom împărtăși actualizări suplimentare, deoarece avem mai multe informații.

3. 26 iunie 2026 la 19:08 UTCinvestigating

   Continuăm să investigăm această problemă. Vom furniza actualizări suplimentare, deoarece avem mai multe informații.

4. 26 iunie 2026 la 20:04 UTCinvestigating

   Continuăm să investigăm această problemă.

5. 26 iunie 2026 la 21:13 UTCmonitoring

   Nu am observat o recurență a problemei care afectează Metrica Pulsul Cloud (ACLP Metrics) de mai multe ore. Echipa noastră va continua să monitorizeze îndeaproape serviciul în timp ce vom investiga cauza de bază. Dacă continuaţi să aveţi probleme, vă rugăm să deschideţi un bilet de sprijin pentru asistenţă.

6. 30 iunie 2026 la 00:02 UTCmonitoring

   Continuăm să monitorizăm orice alte probleme.

7. 8 iulie 2026 la 12:26 UTCresolved

   Am observat orice probleme suplimentare cu Cloud Pulse Metrics (ACLP Metrics) serviciu, și va lua în considerare acum acest incident rezolvat. Dacă continuaţi să aveţi probleme, vă rugăm să deschideţi un bilet de sprijin pentru asistenţă.

Traducere automată din actualizarea oficială a incidentului.