Cronologia delle interruzioni di Linode

1. 24 agosto 2026 alle ore 21:52 UTCinvestigating

   Il nostro team sta indagando su un problema che riguarda il servizio Object Storage negli Stati Uniti-SEA. Durante questo periodo, gli utenti possono sperimentare errori intermittent 5xx con questo servizio.

2. 25 agosto 2026 alle ore 00:31 UTCinvestigating

   Stiamo continuando a indagare su questo problema.

3. 25 agosto 2026 alle ore 00:55 UTCidentified

   Il problema è stato identificato e si sta attuando una correzione.

4. 25 agosto 2026 alle ore 01:11 UTCresolved

   Non abbiamo osservato altri problemi con il servizio di storage degli oggetti, e ora considereremo questo incidente risolto. Se si continua a sperimentare problemi, si prega di aprire un biglietto di supporto per l'assistenza.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 21 agosto 2026 alle ore 17:23 UTCinvestigating

   Il nostro team sta indagando su un problema di servizio emergente che riguarda noi-mare (Seattle, WA). Condivideremo aggiornamenti aggiuntivi come abbiamo più informazioni.

2. 21 agosto 2026 alle ore 21:59 UTCresolved

   In questo momento siamo stati in grado di correggere il problema e il servizio ha ripreso il normale funzionamento.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 14 agosto 2026 alle ore 20:13 UTCinvestigating

   Il nostro team sta indagando su un problema che riguarda la connettività nel nostro centro dati IT-MIL (Milano). Durante questo periodo, gli utenti possono sperimentare timeout di connessione intermittenti e errori per tutti i servizi implementati in questo data center. Condivideremo aggiornamenti aggiuntivi come abbiamo più informazioni.

2. 14 agosto 2026 alle ore 21:18 UTCinvestigating

   Stiamo continuando a indagare su questo problema. Condivideremo aggiornamenti aggiuntivi come abbiamo più informazioni.

3. 14 agosto 2026 alle ore 21:30 UTCresolved

   Non abbiamo osservato altri problemi di connettività nel nostro centro dati IT-MIL (Milano) e ora considereremo questo incidente risolto. Se si continua a sperimentare problemi, si prega di aprire un biglietto di supporto per l'assistenza.

4. 18 agosto 2026 alle ore 19:02 UTCpostmortem

   Il 14 agosto 2026, a partire dalle 17:30 UTC, durante un evento nel nostro data center IT-MIL \(Milano\), sono stati attivati più avvisi che indicano che più host in questo data center sono diventati irraggiungibili. Akamai ha subito iniziato a indagare sul problema e a lavorare per ripristinare gli host colpiti. Durante la finestra di impatto, i clienti avrebbero sperimentato timeout di connessione intermittenti e errori in tutti i servizi implementati in questo data center. Abbiamo ripristinato gli host colpiti e risolto i problemi di connettività a 21:20 UTC il 14 agosto 2026. Stiamo ancora indagando sulla causa della condizione di fallimento. Siamo impegnati a prevenire gli incidenti futuri e condurremo un'indagine approfondita sul motivo per cui gli host sono diventati irraggiungibili, implementando misure per migliorare la stabilità e l'affidabilità. Questo riassunto fornisce una panoramica della nostra attuale comprensione dell'incidente dato le informazioni disponibili. La nostra indagine è in corso e tutte le informazioni qui riportate sono soggette a modifiche.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 13 agosto 2026 alle ore 21:13 UTCinvestigating

   Il nostro team sta indagando su un problema che riguarda la creazione di cluster di Linode Kubernetes Engine Enterprise (LKE-E) nel data center IAD2 - Washington. Questa è una continuazione del problema segnalato in precedenza. Condivideremo aggiornamenti aggiuntivi come abbiamo più informazioni.

2. 13 agosto 2026 alle ore 23:02 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

3. 13 agosto 2026 alle ore 23:24 UTCresolved

   Questo incidente è stato risolto.

4. 18 agosto 2026 alle ore 20:32 UTCpostmortem

   Tra 17:25 UTC e 22:50 UTC il 13 agosto 2026, i clienti di Linode Kubernetes Engine Enterprise \(LKE-E\) che tentano di distribuire le istanze Linode dedicate G7 nel nostro centro dati di Washington \(IAD2\), hanno ricevuto 403 messaggi di errore di provisioning. I carichi di lavoro attivi e le istanze in esecuzione non sono stati colpiti da questo problema. La nostra indagine ha rivelato che, mentre la capacità totale di hardware fisico in IAD2 era sufficiente, la richiesta di provisioning ha innescato un insuccesso di controllo del diritto a causa di una soglia iniziale di assegnazione soft host. Akamai ha risolto il problema aumentando il limite Linode-per-host da 5 a 20 in IAD2. Le funzionalità di distribuzione completa sono state ripristinate e stabilizzate alle 22:50 UTC. Per evitare che la ricorrenza si proceda in avanti, implementeremo un avviso dedicato per le questioni di diritto e di capacità, direttamente legate ai runbook di risposta per una rapida bonifica. Inoltre, stiamo costruendo un cruscotto di panoramica della capacità centralizzata per monitorare proattivamente il headroom regionale. Questo riassunto fornisce una panoramica della nostra attuale comprensione dell'incidente dato le informazioni disponibili. La nostra indagine è in corso e qualsiasi informazione qui presente è soggetta a modifiche.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 13 agosto 2026 alle ore 18:46 UTCinvestigating

   Il nostro team sta indagando su un problema di servizio emergente che interessa l'API in tutte le regioni. Condivideremo aggiornamenti aggiuntivi come abbiamo più informazioni.

2. 13 agosto 2026 alle ore 19:58 UTCmonitoring

   A partire dalle 19:30 UTC sono stati in grado di correggere il problema che interessa API in tutte le regioni. Stiamo monitorando questo per garantire che il servizio rimanga stabile. Se stai ancora vivendo problemi e non riesci ad aprire un biglietto di supporto , chiamaci a 855-454-6633 (+1-609-380-7100 Intl.), o invia una email a [email protected].

3. 13 agosto 2026 alle ore 19:59 UTCmonitoring

   Stiamo continuando a monitorare eventuali ulteriori problemi.

4. 14 agosto 2026 alle ore 00:26 UTCresolved

   Questo incidente è stato risolto.

5. 17 agosto 2026 alle ore 17:38 UTCpostmortem

   Il 13 agosto 2026, a circa 18:15 UTC, Akamai ha osservato un breve outage di servizio che interessa [ api.linode.com ](http://api.linode.com). L'interruzione totale del servizio è durata circa 3 minuti, concludendo a 18:18 UTC. Dopo il ripristino della connettività iniziale, elevata latenza di risposta API persiste attraverso 19:06 UTC, causando tempi di risposta più lenti e ritardi intermittenti per i clienti che interagiscono con i servizi API. Per affrontare l'impatto delle prestazioni, i team di ingegneria Akamai hanno identificato una discrepanza di configurazione sul nodo dell'infrastruttura di caching secondario che gli ha impedito di assorbire il carico pieno del traffico dopo il failover. Gli ingegneri hanno completato una migrazione controllata e hanno spostato il traffico di caching richiesta all'ospite principale. A seguito di questo cambiamento, la latenza API rapidamente diminuì a livelli operativi normali. La condizione iniziale è stata innescata da un riavvio inaspettato dell'ospite fisico del nodo di caching primario. Mentre l'infrastruttura ridondante era attiva, il nodo secondario non era in grado di elaborare il traffico failover senza soluzione di continuità, causando il degrado delle prestazioni esteso. I nostri team di ingegneria stanno conducendo un'indagine di follow-up sui meccanismi di failover per ottimizzare le velocità di esecuzione e allineare le impostazioni di configurazione attraverso nodi ridondanti, assicurando che i sistemi secondari possano gestire il traffico senza soluzione di continuità in eventi futuri. Questo riassunto fornisce una panoramica della nostra attuale comprensione dell'incidente dato le informazioni disponibili. La nostra indagine è in corso e qualsiasi informazione qui presente è soggetta a modifiche.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 13 agosto 2026 alle ore 16:16 UTCinvestigating

   Il nostro team sta indagando su un problema che riguarda il Linode Kubernetes Engine (LKE). Condivideremo aggiornamenti aggiuntivi come abbiamo più informazioni.

2. 13 agosto 2026 alle ore 16:30 UTCmonitoring

   In questo momento siamo stati in grado di correggere i problemi che interessano il servizio LKE. Noi stiamo monitorando questo per assicurarci che rimanga stabile. Se si continua a sperimentare problemi, si prega di aprire un biglietto di supporto per l'assistenza.

3. 13 agosto 2026 alle ore 17:54 UTCresolved

   Non abbiamo osservato problemi aggiuntivi con il servizio LKE, e ora considereremo questo incidente risolto. Se si continua a sperimentare problemi, si prega di aprire un biglietto di supporto per l'assistenza.

4. 17 agosto 2026 alle ore 21:30 UTCpostmortem

   A partire da circa 14:50 UTC il 13 agosto 2026, i clienti che hanno tentato di fornire Linode Kubernetes Engine Enterprise \(LKE-E\) clusters nel data center IAD2 non sono stati in grado di. Abbiamo identificato che il problema era dovuto all'esclusione di due componenti in IAD2 in un recente aggiornamento della versione software che ha portato a un errore API. Abbiamo aggiornato i componenti identificati per portarli in sincronia con lo stato previsto. Ciò ha mitigato il problema a circa 16:00 UTC il 13 agosto 2026. Per evitare che questo problema si verifichi in futuro, stiamo rivedendo i processi di aggiornamento del software LKE per garantire che tutti i componenti inclusi completano gli aggiornamenti della versione prima di essere reintrodotti al servizio durante gli aggiornamenti del software della piattaforma. Questo riassunto fornisce una panoramica della nostra attuale comprensione dell'incidente dato le informazioni disponibili. La nostra indagine è in corso e qualsiasi informazione qui presente è soggetta a modifiche.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 14 agosto 2026 alle ore 15:46 UTCresolved

   Il 13 agosto 2026, tra circa 14:00-16:30 UTC, abbiamo osservato guasti intermittenti e ritardi durante la fornitura di nuovi cluster LKE-E nella regione di Seattle (SEA1). Il problema che riguarda il servizio LKE-E a Seattle autocorrettato a circa 16:30 UTC, e non abbiamo osservato una ricorrenza da allora. Stiamo indagando attivamente sulla causa. Continueremo a monitorare il servizio per la stabilità. Se si verificano problemi con questo servizio, si prega di aprire un biglietto di supporto per l'assistenza.

2. 21 agosto 2026 alle ore 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.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 10 agosto 2026 alle ore 17:15 UTCinvestigating

   Il nostro team sta indagando su un problema a monte che influenza le implementazioni di Ubuntu. Ciò può influenzare la capacità di installare aggiornamenti di pacchetto e sicurezza su tutti i sistemi Ubuntu.

2. 11 agosto 2026 alle ore 23:35 UTCinvestigating

   Stiamo continuando a indagare su questo problema. Gli esperti interessati sono impegnati. Gli aggiornamenti successivi sullo stato di mitigazione saranno pubblicati come progresso è fatto.

3. 12 agosto 2026 alle ore 03:29 UTCidentified

   Abbiamo identificato la causa del problema, e si sta attuando una correzione. Forniamo un aggiornamento non appena la soluzione è in atto.

4. 21 agosto 2026 alle ore 18:40 UTCresolved

   Possiamo confermare che il problema è stato mitigato alle 06:30 UTC il 20 agosto 2026 e il servizio ha ripreso le normali operazioni.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 31 luglio 2026 alle ore 17:49 UTCinvestigating

   Il nostro team sta indagando sulla perdita di pacchetti su alcuni percorsi dai data center in-maa & in-bom-2 nella regione degli Stati Uniti. Durante questo periodo, gli utenti possono sperimentare timeout di connessione e errori con servizi che attraversano le regioni dell'India e degli Stati Uniti. Condivideremo aggiornamenti aggiuntivi come abbiamo più informazioni.

2. 31 luglio 2026 alle ore 18:25 UTCidentified

   Il nostro team ha identificato la causa della perdita di pacchetti nei nostri data center statunitensi. Stiamo lavorando con il nostro provider a monte per risolvere questo problema e forniremo un aggiornamento non appena la soluzione è in atto.

3. 4 agosto 2026 alle ore 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 agosto 2026 alle ore 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 agosto 2026 alle ore 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.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 28 luglio 2026 alle ore 18:14 UTCinvestigating

   Il nostro team sta indagando su un problema che riguarda il servizio Block Storage in diverse regioni del data center. Questo problema colpisce in gran parte allegando e staccando volumi Block Storage. Durante questo periodo, gli utenti possono sperimentare il volume allegare / staccare i blocchi, timeout ed errori con questo servizio. Condivideremo aggiornamenti aggiuntivi come abbiamo più informazioni.

2. 28 luglio 2026 alle ore 19:27 UTCidentified

   Il nostro team ha identificato il problema che riguarda il servizio Block Storage nei nostri data center. Stiamo lavorando rapidamente per implementare una correzione, e forniremo un aggiornamento non appena la soluzione è in atto.

3. 28 luglio 2026 alle ore 20:17 UTCidentified

   Vorremmo aggiornare che dopo ulteriori indagini, l'impatto si manifesterebbe in posti di lavoro host ritardati e a volte falliti, che potrebbero includere molte azioni diverse su Linodes e non solo impatto allegando e staccando i volumi di Block Storage come abbiamo accennato nel nostro aggiornamento iniziale, abbiamo aggiornato il titolo per riflettere l'impatto aggiornato. Stiamo lavorando rapidamente per implementare una correzione, e forniremo un aggiornamento non appena la soluzione è in atto.

4. 28 luglio 2026 alle ore 22:51 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

5. 29 luglio 2026 alle ore 12:27 UTCresolved

   Non abbiamo osservato ulteriori problemi di degrado delle prestazioni dei posti di lavoro host, e ora considereremo questo incidente risolto. Se si continua a sperimentare problemi, si prega di aprire un biglietto di supporto per l'assistenza.

6. 31 luglio 2026 alle ore 18:57 UTCpostmortem

   Il 27 luglio 2026 alle 3:30 UTC, Akamai ha osservato un aumento degli errori durante la connessione al database di hosting Linode, che colpisce principalmente gli allegati di volume di Block Storage. Ciò ha portato a guasti di lavoro host e impatto limitato del cliente, con alcuni utenti che sperimentano messaggi di errore e flussi di lavoro interrotti. I tassi di timeout elevati sono stati rilevati nei registri per alcune posizioni del data center, coincidendo con il rollout incrementale di una nuova bandierina di funzionalità. L'indagine iniziale ha rivelato colli intermittenti dal proxy del database agli host client durante il handshake TLS. La teoria attuale suggerisce che è stato raggiunto un limite di protezione DDoS relativo al pacchetto MTU percorso messaggi ICMP troppo grandi. Quando il proxy ha inviato pacchetti TCP con una grande MTU, i messaggi ICMP attesi sono stati eliminati dai router di gateway Dallas a causa del superamento della velocità consentita configurata. Ciò ha causato connessioni TCP proxy database a timeout per Compute Hosts. Il problema è stato innescato dall'attivazione della nuova bandierina di funzionalità, che ha cambiato il percorso di routing e rimosso il bloccaggio MTU prima che i pacchetti raggiungessero i gateway. Per mitigare il problema, Akamai ha rilanciato il recente cambiamento di rete nei siti Compute colpiti, a partire dalle 20:50 UTC. A partire da 22:57 UTC, il tasso di riavvio del servizio è tornato a livelli pre-incidenti. Akamai sta anche pianificando una modifica per aumentare la soglia consentibile per i messaggi ICMP troppo grandi. Questo riassunto fornisce una panoramica della nostra attuale comprensione dell'incidente dato le informazioni disponibili. La nostra indagine è in corso e qualsiasi informazione qui presente è soggetta a modifiche.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 20 luglio 2026 alle ore 01:52 UTCinvestigating

   Il nostro team sta attualmente indagando su un problema di connettività che interessa Linodes nella regione Italia (Milano). Durante questo periodo, le Linodi esistenti in questa posizione possono essere irraggiungibili. Si prega di notare che la creazione di nuovi Linodi funziona normalmente e rimane inalterata.

2. 20 luglio 2026 alle ore 02:56 UTCinvestigating

   Stiamo continuando a indagare su questo problema. Forneremo il prossimo aggiornamento come facciamo progressi.

3. 20 luglio 2026 alle ore 03:12 UTCinvestigating

   Il nostro team ha individuato il problema della connettività nel nostro data center di Milano (Italia). Stiamo lavorando rapidamente per implementare una correzione, e forniremo un aggiornamento non appena la soluzione è in atto.

4. 20 luglio 2026 alle ore 03:20 UTCmonitoring

   In questo momento, siamo stati in grado di correggere i problemi relativi alla connettività nel nostro data center di Milano (Italia). Noi stiamo monitorando questo per assicurarci che rimanga stabile. Se si verificano ancora problemi, si prega di aprire un biglietto di supporto per l'assistenza.

5. 20 luglio 2026 alle ore 04:10 UTCresolved

   Non abbiamo osservato altri problemi di connettività nel nostro data center di Milano (Italia) e ora considereremo questo incidente risolto. Se si continua a sperimentare problemi, si prega di aprire un biglietto di supporto per l'assistenza.

6. 20 luglio 2026 alle ore 05:45 UTCpostmortem

   A partire dalle 00:33 UTC il 20 luglio 2026, alcuni host del centro dati di Milano, Italia, non sono stati disponibili, influenzando l'accesso dei clienti a Linodes. L'indagine ha identificato che questo problema si è verificato durante gli aggiornamenti del firmware del router programmato. Mentre seguiamo un processo di aggiornamento graduale per evitare interruzioni di servizio, un inaspettato intersezione di attività di manutenzione concorrenziale ha portato a una perdita temporanea di connettività di rete per gli host interessati. Il servizio è stato completamente restaurato da 02:16 UTC il 20 luglio 2026, e tutti i sistemi sono ora operativi come previsto. Internamente, stiamo esaminando le nostre procedure di gestione dei cambiamenti e pianificazione della manutenzione per garantire un migliore coordinamento e prevenire problemi simili in futuro. Ci scusiamo per l'impatto e vi ringraziamo per la vostra pazienza e il supporto continuo. Ci impegniamo a migliorare continuamente i nostri sistemi e a prevenire il ripetersi. Questo riassunto fornisce una panoramica della nostra attuale comprensione dell'incidente dato le informazioni disponibili. La nostra indagine è in corso e tutte le informazioni qui riportate sono soggette a modifiche.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 18 luglio 2026 alle ore 03:34 UTCinvestigating

   Il nostro team sta indagando su un problema che riguarda il servizio Object Storage. Durante questo periodo, gli utenti possono sperimentare timeout di connessione e errori con questo servizio.

2. 18 luglio 2026 alle ore 03:54 UTCidentified

   Il nostro team ha identificato il problema che riguarda il servizio Object Storage. Stiamo lavorando rapidamente per implementare una correzione, e forniremo un aggiornamento non appena la soluzione è in atto.

3. 18 luglio 2026 alle ore 04:36 UTCresolved

   Non abbiamo osservato altri problemi con il servizio di storage degli oggetti, e ora considereremo questo incidente risolto. Se si continua a sperimentare problemi, si prega di aprire un biglietto di supporto per l'assistenza.

4. 21 luglio 2026 alle ore 15:26 UTCpostmortem

   Il 18 luglio 2026, tra le 00:30 UTC e le 04:00 UTC, gli utenti potrebbero aver sperimentato 5xx errori mentre si cerca di creare un nuovo secchio nel Object Storage per i seguenti endpoint. * [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) Il problema è iniziato quando l'infrastruttura che supporta Object Storage è entrata in uno stato degradato in tutti i nodi. Ciò ha impedito al servizio di elaborare richieste, con conseguente guasti durante le operazioni di creazione di secchi. Per mitigare l'impatto, abbiamo applicato un fix al sistema backend responsabile della creazione di secchi. L'impatto è stato mitigato dopo questa azione. I nostri esperti in materia stanno indagando sulla causa principale e prenderanno opportune azioni preventive. Ci scusiamo per l'impatto e apprezziamo la vostra pazienza e il supporto continuo. Stiamo effettuando modifiche di configurazione e di funzionamento ai nostri sistemi per evitare che questo accada di nuovo, e rimanere impegnati a un miglioramento continuo. Questo sommario fornisce una panoramica della nostra attuale comprensione dell'incidente, date le informazioni disponibili. La nostra indagine è in corso e tutte le informazioni qui riportate sono soggette a modifiche.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 16 luglio 2026 alle ore 01:24 UTCresolved

   Il nostro team ha indagato un problema che ha interessato la connettività nel nostro data center US-MIA (Miami) tra 21:20 UTC e circa 23:28 UTC il 15 luglio 2026. Durante questa finestra, gli utenti possono avere sperimentato le prestazioni di rete degradate e la perdita di pacchetti per i servizi Compute implementati in questa regione. Il problema è stato risolto dopo che abbiamo implementato una correzione. Stiamo continuando a lavorare con il nostro fornitore di servizi di terze parti per confermare la causa principale, come evidenza iniziale indica un outage cross-connect del campus (fibra oscura) sulla loro infrastruttura.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 14 luglio 2026 alle ore 12:21 UTCinvestigating

   Il nostro team sta indagando su un problema di servizio emergente che riguarda le API e CLI. Condivideremo aggiornamenti aggiuntivi come abbiamo più informazioni.

2. 14 luglio 2026 alle ore 12:58 UTCidentified

   Il nostro team ha identificato il problema che riguarda Cloud Manager e API. Stiamo lavorando rapidamente per implementare una correzione, e forniremo un aggiornamento non appena la soluzione è in atto.

3. 14 luglio 2026 alle ore 13:11 UTCmonitoring

   In questo momento siamo stati in grado di correggere il problema che interessa Cloud Manager e API. Stiamo monitorando questo per garantire che il servizio rimanga stabile. Se stai ancora vivendo problemi e non riesci ad aprire un biglietto di supporto , chiamaci a 855-454-6633 (+1-609-380-7100 Intl.), o invia una email a [email protected].

4. 14 luglio 2026 alle ore 18:36 UTCmonitoring

   Stiamo continuando a monitorare eventuali ulteriori problemi.

5. 14 luglio 2026 alle ore 19:26 UTCresolved

   Non abbiamo osservato altri problemi con Cloud Manager, API o CLI, e ora considereremo questo incidente risolto. Se continui a provare problemi, contattaci a 855-454-6633 (+1-609-380-7100 Intl.), oppure invia una email a [email protected] per assistenza.

6. 16 luglio 2026 alle ore 18:13 UTCpostmortem

   Il 14 luglio 2026, alle 10:57 UTC, Akamai ha identificato un aumento di 502 errori e latenza che interessano i clienti utilizzando l'API Linode, CLI e Cloud Manager. Questa interruzione ha portato a un impatto moderato del servizio, con i clienti che segnalano tassi di errore elevati. La nostra indagine iniziale ha tracciato il problema alla latenza con i servizi IAM, che è stato risolto, ma gli errori elevati persistono. Un'ulteriore analisi da parte di esperti interessati ha determinato che l'incidente è stato innescato da un failback manuale al bilanciatore di carico primario Cloud IAM dal bilanciatore di carico secondario. Questa azione è stata sollecitata da un avviso di avvertimento che indica che il bilanciatore del carico secondario stava agendo come il maestro mangime. Il processo manuale di avvio e arresto dei servizi per avviare il failback differiva dal processo automatizzato e ha portato a una cascata di connessioni GRPC stanti, causando una maggiore latenza e errori API. Riavviare i server API ha eliminato le connessioni stanti e ripristinato le operazioni normali. L'impatto del cliente è stato mitigato da circa 13:10 UTC il 14 luglio 2026. Per evitare il ripetersi, Akamai sta indagando perché il failback manuale ha causato questo comportamento. Il team sta pensando di implementare un comando di scarico per cancellare le connessioni GRPC durante il failover e impostare avvisi per rilevare connessioni stanti per intervento proattivo. Tuttavia, l'attenzione immediata rimane sulla comprensione della causa principale, con allerta e automazione pianificata per fasi successive. Diversi clienti hanno confermato la risoluzione attraverso le loro implementazioni. Akamai continuerà a monitorare la salute del sistema e attendere ulteriori feedback dei clienti prima di dichiarare il pieno recupero. Questo riassunto fornisce una panoramica della nostra attuale comprensione dell'incidente dato le informazioni disponibili. La nostra indagine è in corso e qualsiasi informazione qui presente è soggetta a modifiche.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 13 luglio 2026 alle ore 18:29 UTCidentified

   Il nostro team ha identificato un problema di servizio emergente che riguarda i posti di lavoro per alcuni host in tutte le regioni. La connettività Linode è *non ha impatto*, ma alcuni lavori di livello host, come i backup o i tentativi di accendere o spegnere i tuoi servizi possono essere ritardati. Condivideremo aggiornamenti aggiuntivi come abbiamo più informazioni.

2. 13 luglio 2026 alle ore 19:54 UTCresolved

   Questo incidente è stato risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 9 luglio 2026 alle ore 16:57 UTCinvestigating

   Il nostro team sta indagando su un problema di servizio emergente che riguarda i login Cloud Manager. Condivideremo aggiornamenti aggiuntivi come abbiamo più informazioni.

2. 9 luglio 2026 alle ore 17:24 UTCinvestigating

   Stiamo continuando a indagare su questo problema. Forneremo un aggiornamento entro i prossimi 30 minuti.

3. 9 luglio 2026 alle ore 17:49 UTCmonitoring

   In questo momento siamo stati in grado di correggere il problema che riguarda i login Cloud Manager. Stiamo monitorando questo per garantire che il servizio rimanga stabile. Se stai ancora vivendo problemi e non riesci ad aprire un biglietto di supporto , chiamaci a 855-454-6633 (+1-609-380-7100 Intl.), o invia una email a [email protected].

4. 9 luglio 2026 alle ore 18:21 UTCresolved

   Non abbiamo osservato altri problemi con i login Cloud Manager e ora considereremo questo incidente risolto. Se continui a provare problemi, contattaci a 855-454-6633 (+1-609-380-7100 Intl.), oppure invia una email a [email protected] per assistenza.

5. 10 luglio 2026 alle ore 12:30 UTCpostmortem

   Il 9 luglio 2026, alle 15:43 UTC, i clienti non sono stati in grado di accedere a [cloud.linode.com](http://cloud.linode.com) utilizzando nome utente e password. I clienti ricevevano un messaggio di errore "password sbagliata". L'indagine ha rivelato che il problema era dovuto a un problema di certificato interno. Per mitigare l'impatto, abbiamo risolto il problema del certificato sui server colpiti alle 17:24 UTC il 9 luglio 2026. Dopo aver monitorato i nostri sistemi per qualche tempo, abbiamo confermato che il problema è stato completamente risolto. Akamai distribuirà una correzione permanente per evitare una ricorrenza del problema.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 6 luglio 2026 alle ore 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 luglio 2026 alle ore 15:31 UTCresolved

   This incident has been resolved.

1. 1 luglio 2026 alle ore 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 luglio 2026 alle ore 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 luglio 2026 alle ore 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 giugno 2026 alle ore 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 giugno 2026 alle ore 19:55 UTCinvestigating

   We are continuing to investigate this issue.

3. 30 giugno 2026 alle ore 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 giugno 2026 alle ore 21:36 UTCidentified

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

5. 30 giugno 2026 alle ore 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 giugno 2026 alle ore 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 luglio 2026 alle ore 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 giugno 2026 alle ore 17:35 UTCinvestigating

   Il nostro team sta indagando su un problema che riguarda i Cloud Pulse Metrics (ACLP Metrics), in particolare l'impatto di Managed Database Metrics reporting. Il problema sembra essere intermittente. Condivideremo aggiornamenti aggiuntivi come abbiamo più informazioni.

2. 26 giugno 2026 alle ore 18:19 UTCinvestigating

   Stiamo continuando a indagare su questo problema. Condivideremo aggiornamenti aggiuntivi come abbiamo più informazioni.

3. 26 giugno 2026 alle ore 19:08 UTCinvestigating

   Stiamo continuando a indagare su questo problema. Forniremo ulteriori aggiornamenti in quanto abbiamo maggiori informazioni.

4. 26 giugno 2026 alle ore 20:04 UTCinvestigating

   Stiamo continuando a indagare su questo problema.

5. 26 giugno 2026 alle ore 21:13 UTCmonitoring

   Non abbiamo osservato una ricorrenza del problema che riguarda le metriche di impulso del cloud (metriche ACLP) per diverse ore. Il nostro team continuerà a monitorare il servizio da vicino mentre studiamo la causa sottostante. Se si continua a sperimentare problemi, si prega di aprire un biglietto di supporto per l'assistenza.

6. 30 giugno 2026 alle ore 00:02 UTCmonitoring

   Stiamo continuando a monitorare eventuali ulteriori problemi.

7. 8 luglio 2026 alle ore 12:26 UTCresolved

   Non abbiamo osservato altri problemi con il servizio Cloud Pulse Metrics (ACLP Metrics), e ora considereremo questo incidente risolto. Se si continua a sperimentare problemi, si prega di aprire un biglietto di supporto per l'assistenza.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.