Histórico de interrupções do Linode

1. 24 Eost 2026 da 21:52 UTCinvestigating

   Nossa equipe está investigando um problema que afeta o serviço de armazenamento de objetos na US-SEA. Durante este tempo, os usuários podem experimentar erros intermitentes de 5xx com este serviço.

2. 25 Eost 2026 da 00:31 UTCinvestigating

   Continuamos a investigar esta questão.

3. 25 Eost 2026 da 00:55 UTCidentified

   A questão foi identificada e está a ser implementada uma solução.

4. 25 Eost 2026 da 01:11 UTCresolved

   Não observamos quaisquer problemas adicionais com o serviço de armazenamento de objetos, e agora consideraremos este incidente resolvido. Se você continuar a ter problemas, por favor abra um ticket de suporte para assistência.

Traduzido automaticamente da atualização oficial do incidente.

1. 21 Eost 2026 da 17:23 UTCinvestigating

   Nossa equipe está investigando uma questão de serviço emergente que afeta a us-sea (Seattle, WA). Iremos partilhar actualizações adicionais à medida que tivermos mais informações.

2. 21 Eost 2026 da 21:59 UTCresolved

   Neste momento, conseguimos corrigir a questão e o serviço voltou a funcionar normalmente.

Traduzido automaticamente da atualização oficial do incidente.

1. 14 Eost 2026 da 20:13 UTCinvestigating

   Nossa equipe está investigando um problema que afeta a conectividade no nosso data center de TI-MIL (Milan). Durante esse tempo, os usuários podem experimentar tempo limite de conexão intermitente e erros para todos os serviços implantados neste data center. Iremos partilhar actualizações adicionais à medida que tivermos mais informações.

2. 14 Eost 2026 da 21:18 UTCinvestigating

   Continuamos a investigar esta questão. Iremos partilhar actualizações adicionais à medida que tivermos mais informações.

3. 14 Eost 2026 da 21:30 UTCresolved

   Não observamos quaisquer problemas adicionais de conectividade no nosso data center de TI-MIL (Milan) e agora consideraremos este incidente resolvido. Se você continuar a ter problemas, por favor abra um ticket de suporte para assistência.

4. 18 Eost 2026 da 19:02 UTCpostmortem

   Em 14 de agosto de 2026, começando por volta de 17:30 UTC, durante um evento em nosso centro de dados IT-MIL \(Milan\), vários alertas foram disparados indicando que vários hosts neste data center se tornaram inalcançáveis. □ Akamai imediatamente começou a investigar o problema e a trabalhar para restaurar os hospedeiros impactados. Durante a janela de impacto, os clientes teriam experimentado tempo limite de conexão intermitente e erros em todos os serviços implantados neste data center. □ Restauramos os hosts impactados e fixamos os problemas de conectividade às 21:20 UTC em 14 de agosto de 2026. Ainda estamos a investigar a causa da falha. □ Estamos empenhados em prevenir futuros incidentes e conduziremos uma investigação aprofundada sobre o motivo pelo qual os anfitriões se tornaram inalcançáveis, implementando medidas para aumentar a estabilidade e a fiabilidade. □ Este resumo fornece uma visão geral da nossa compreensão atual do incidente dada a informação disponível. A nossa investigação está em curso, e qualquer informação aqui está sujeita a alterações.

Traduzido automaticamente da atualização oficial do incidente.

1. 13 Eost 2026 da 21:13 UTCinvestigating

   Nossa equipe está investigando um problema que afeta a criação de clusters Linode Kubernetes Engine Enterprise (LKE-E) no data center IAD2 - Washington. Esta é uma continuação da questão relatada anteriormente. Iremos partilhar actualizações adicionais à medida que tivermos mais informações.

2. 13 Eost 2026 da 23:02 UTCmonitoring

   Foi implementada uma correção e estamos monitorando os resultados.

3. 13 Eost 2026 da 23:24 UTCresolved

   Este incidente foi resolvido.

4. 18 Eost 2026 da 20:32 UTCpostmortem

   Entre 17:25 UTC e 22:50 UTC em 13 de agosto de 2026, Linode Kubernetes Engine Enterprise \(LKE-E\) clientes tentando implantar G7 instâncias dedicadas Linode em nosso centro de dados Washington \(IAD2\), recebeu 403 provisionamento de mensagens de erro. As cargas de trabalho ativas e as instâncias de execução não foram afetadas por esta questão. Nossa investigação revelou que, embora a capacidade física total de hardware no IAD2 fosse suficiente, o pedido de provisionamento desencadeou uma falha na verificação de direitos devido a um limiar inicial de alocação do hospedeiro. Akamai resolveu o problema aumentando o limite de Linode-por-host de 5 para 20 no IAD2. As capacidades de implantação completas foram restauradas e estabilizadas às 22:50 UTC. Para evitar que a recorrência avance, implementaremos o alerta dedicado para questões de direito e capacidade, diretamente ligado aos runbooks de resposta para uma rápida reparação. Além disso, estamos construindo um painel de visão geral de capacidade centralizada para rastrear proativamente a sede regional. Este resumo fornece uma visão geral da nossa compreensão atual do incidente dada a informação disponível. Nossa investigação está em andamento e qualquer informação aqui está sujeita a mudanças.

Traduzido automaticamente da atualização oficial do incidente.

1. 13 Eost 2026 da 18:46 UTCinvestigating

   Nossa equipe está investigando um problema de serviço emergente que afeta a API em todas as regiões. Iremos partilhar actualizações adicionais à medida que tivermos mais informações.

2. 13 Eost 2026 da 19:58 UTCmonitoring

   A partir das 19:30 UTC foram capazes de corrigir o problema que afeta API em todas as regiões. Estaremos a acompanhar esta situação para garantir que o serviço se mantenha estável. Se você ainda estiver tendo problemas e incapaz de abrir um ticket de suporte, por favor ligue para 855-454-6633 (+1-609-380-7100 Intl.), ou envie um e-mail para [email protected].

3. 13 Eost 2026 da 19:59 UTCmonitoring

   Continuamos monitorando quaisquer outros problemas.

4. 14 Eost 2026 da 00:26 UTCresolved

   Este incidente foi resolvido.

5. 17 Eost 2026 da 17:38 UTCpostmortem

   Em 13 de agosto de 2026, aproximadamente 18:15 UTC, Akamai observou uma breve interrupção de serviço afetando [ api.linode.com ](http://api.linode.com). A interrupção total do serviço durou aproximadamente 3 minutos, concluindo às 18:18 UTC. Após a restauração da conectividade inicial, a latência elevada da resposta da API persistiu até 19:06 UTC, causando tempos de resposta mais lentos e atrasos intermitentes para os clientes que interagiam com os serviços da API. Para lidar com o impacto do desempenho, as equipes de engenharia da Akamai identificaram uma discrepância de configuração no nó de infraestrutura de cache secundário que o impediu de absorver toda a carga de tráfego após o failover. Os engenheiros completaram uma migração controlada e moveram o tráfego de cache de requisição para o host primário. Após essa mudança, a latência da API diminuiu rapidamente para níveis operacionais normais. A condição inicial foi desencadeada por uma reinicialização inesperada do hospedeiro físico do nó de cache primário. Enquanto a infraestrutura redundante estava ativa, o nó secundário não foi capaz de processar o tráfego failover sem problemas, causando a degradação prolongada do desempenho. Nossas equipes de engenharia estão realizando uma investigação de seguimento sobre os mecanismos de failover para otimizar as velocidades de execução e alinhar as configurações em nós redundantes, garantindo que os sistemas secundários possam lidar com o tráfego sem problemas em eventos futuros. Este resumo fornece uma visão geral da nossa compreensão atual do incidente dada a informação disponível. Nossa investigação está em andamento e qualquer informação aqui está sujeita a mudanças.

Traduzido automaticamente da atualização oficial do incidente.

1. 13 Eost 2026 da 16:16 UTCinvestigating

   Nossa equipe está investigando um problema que afeta o Linode Kubernetes Engine (LKE). Iremos partilhar actualizações adicionais à medida que tivermos mais informações.

2. 13 Eost 2026 da 16:30 UTCmonitoring

   Neste momento, conseguimos corrigir as questões que afectam o serviço LKE. Vamos acompanhar esta situação para garantir que se mantenha estável. Se você continuar a ter problemas, por favor abra um ticket de suporte para assistência.

3. 13 Eost 2026 da 17:54 UTCresolved

   Não observamos quaisquer problemas adicionais com o serviço LKE, e agora consideraremos este incidente resolvido. Se você continuar a ter problemas, por favor abra um ticket de suporte para assistência.

4. 17 Eost 2026 da 21:30 UTCpostmortem

   A partir de aproximadamente 14:50 UTC em 13 de agosto de 2026, os clientes que tentaram fornecer Linode Kubernetes Engine Enterprise \(LKE-E\) clusters no centro de dados IAD2 não puderam. Identificamos que o problema foi devido à exclusão de dois componentes no IAD2 em uma atualização recente de versão de software que resultou em um descompasso de API. Atualizamos os componentes identificados para os sincronizar com o estado esperado. Isso mitigou a questão em aproximadamente 16:00 UTC em 13 de agosto de 2026. Para evitar que esse problema ocorra no futuro, estamos revisando processos de atualização de software LKE para garantir que todos os componentes incluídos completem atualizações de versão antes de serem reintroduzidos ao serviço durante as atualizações de software da plataforma. Este resumo fornece uma visão geral da nossa compreensão atual do incidente dada a informação disponível. Nossa investigação está em andamento e qualquer informação aqui está sujeita a mudanças.

Traduzido automaticamente da atualização oficial do incidente.

1. 14 Eost 2026 da 15:46 UTCresolved

   Em 13 de agosto de 2026, entre aproximadamente 14:00-16:30 UTC, observamos falhas intermitentes e atrasos no provisionamento de novos clusters LKE-E na região de Seattle (SEA1). A questão que afeta o serviço LKE-E em Seattle se auto-corregiu em aproximadamente 16:30 UTC, e não observamos uma recorrência desde então. Estamos a investigar a causa. Continuaremos a acompanhar o serviço de estabilidade. Se você tiver algum problema com este serviço, por favor abra um ticket de suporte para assistência.

2. 21 Eost 2026 da 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.

Traduzido automaticamente da atualização oficial do incidente.

1. 10 Eost 2026 da 17:15 UTCinvestigating

   A nossa equipa está a investigar um problema a montante que afecta as implantações do Ubuntu. Isso pode afetar a capacidade de instalar atualizações de pacote e segurança em todos os sistemas Ubuntu.

2. 11 Eost 2026 da 23:35 UTCinvestigating

   Continuamos a investigar esta questão. Estão envolvidos os peritos em assuntos específicos. As atualizações subsequentes em torno do estado de mitigação serão publicadas à medida que o progresso for feito.

3. 12 Eost 2026 da 03:29 UTCidentified

   Identificámos a causa da questão e está a ser implementada uma solução. Forneceremos uma atualização assim que a solução estiver em vigor.

4. 21 Eost 2026 da 18:40 UTCresolved

   Podemos confirmar que a questão foi atenuada às 06:30 UTC em 20 de agosto de 2026 e o serviço retomou as operações normais.

Traduzido automaticamente da atualização oficial do incidente.

1. 31 Gouere 2026 da 17:49 UTCinvestigating

   Nossa equipe está investigando a perda de pacotes em alguns caminhos dos data centers in-maa e in-bom-2 para a região dos EUA. Durante este tempo, os usuários podem experimentar timeouts de conexão e erros com serviços que atravessam entre as regiões da Índia e dos Estados Unidos. Iremos partilhar actualizações adicionais à medida que tivermos mais informações.

2. 31 Gouere 2026 da 18:25 UTCidentified

   A nossa equipa identificou a causa da perda de pacotes para os nossos centros de dados americanos. Estamos trabalhando com nosso provedor a montante para resolver este problema e vamos fornecer uma atualização assim que a solução estiver em vigor.

3. 4 Eost 2026 da 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 Eost 2026 da 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 Eost 2026 da 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.

Traduzido automaticamente da atualização oficial do incidente.

1. 28 Gouere 2026 da 18:14 UTCinvestigating

   Nossa equipe está investigando um problema que afeta o serviço de armazenamento de blocos em várias regiões de data center. Esta questão tem grande impacto na ligação e desacoplamento dos volumes de armazenamento em bloco. Durante este tempo, os usuários podem experimentar o volume anexar/desligar travas, timeouts e erros com este serviço. Iremos partilhar actualizações adicionais à medida que tivermos mais informações.

2. 28 Gouere 2026 da 19:27 UTCidentified

   Nossa equipe identificou o problema que afeta o serviço de Armazenamento de Blocos em nossos data centers. Estamos trabalhando rapidamente para implementar uma correção, e vamos fornecer uma atualização assim que a solução estiver em vigor.

3. 28 Gouere 2026 da 20:17 UTCidentified

   Gostaríamos de atualizar que, após uma investigação adicional, o impacto se manifestaria em trabalhos de host atrasados e às vezes fracassados, o que poderia incluir muitas ações diferentes em Linodes e não apenas impactando anexar e desacoplar volumes de armazenamento de bloco como mencionamos em nossa atualização inicial, atualizamos o título para refletir o impacto atualizado. Estamos trabalhando rapidamente para implementar uma correção, e vamos fornecer uma atualização assim que a solução estiver em vigor.

4. 28 Gouere 2026 da 22:51 UTCmonitoring

   Foi implementada uma correção e estamos monitorando os resultados.

5. 29 Gouere 2026 da 12:27 UTCresolved

   Não observamos quaisquer problemas adicionais de degradação do desempenho dos trabalhos de acolhimento, e agora consideraremos este incidente resolvido. Se você continuar a ter problemas, por favor abra um ticket de suporte para assistência.

6. 31 Gouere 2026 da 18:57 UTCpostmortem

   Em 27 de julho de 2026, às 3:30 UTC, Akamai observou um aumento de erros ao se conectar ao banco de dados de hospedagem da Linode, afetando principalmente os anexos de volume de armazenamento em bloco. Isso resultou em falhas no trabalho de host e impacto limitado do cliente, com alguns usuários tendo mensagens de erro e fluxos de trabalho interrompidos. Taxas elevadas de timeout foram anotadas em logs para certos locais de data center, coincidindo com o lançamento incremental de uma nova bandeira de recursos. A investigação inicial revelou gotas intermitentes de pacotes do proxy do banco de dados para hosts clientes durante o aperto de mão do TLS. A teoria atual sugere que um limite de proteção DDoS relacionado ao caminho MTU pacote mensagens muito grandes ICMP foi alcançado. Quando o proxy enviou pacotes TCP com um grande MTU, as mensagens ICMP esperadas foram largadas por roteadores de gateway Dallas devido a exceder a taxa configurável. Isso causou conexões TCP proxy de banco de dados para timeout para Calcular Hosts. O problema foi acionado pela habilitação da nova bandeira de recursos, que mudou o caminho de roteamento e removeu o aperto MTU antes que os pacotes chegassem aos gateways. Para mitigar o problema, Akamai retrocedeu a recente mudança de rede nos sites de computação afetados, começando às 20:50 UTC. A partir das 22:57 UTC, a taxa de serviço reinicia-se aos níveis pré-incidentes. Akamai também está planejando uma mudança para aumentar o limiar permissível para as mensagens ICMP demasiado grandes. Este resumo fornece uma visão geral da nossa compreensão atual do incidente dada a informação disponível. Nossa investigação está em andamento e qualquer informação aqui está sujeita a mudanças.

Traduzido automaticamente da atualização oficial do incidente.

1. 20 Gouere 2026 da 01:52 UTCinvestigating

   Nossa equipe está atualmente investigando uma questão de conectividade que afeta Linodes na região da Itália (Milão). Durante este tempo, Linodes existentes neste local pode ser inacessível. Por favor, note que criar novos Linodes está funcionando normalmente e permanece inalterado.

2. 20 Gouere 2026 da 02:56 UTCinvestigating

   Continuamos a investigar esta questão. Apresentaremos a próxima actualização à medida que avançarmos.

3. 20 Gouere 2026 da 03:12 UTCinvestigating

   Nossa equipe identificou o problema que afeta a conectividade em nosso data center de Milão (Itália). Estamos trabalhando rapidamente para implementar uma correção, e vamos fornecer uma atualização assim que a solução estiver em vigor.

4. 20 Gouere 2026 da 03:20 UTCmonitoring

   Neste momento, temos sido capazes de corrigir as questões que afetam a conectividade em nosso centro de dados Milão (Itália). Vamos acompanhar esta situação para garantir que se mantenha estável. Se você ainda tiver problemas, por favor abra um ticket de suporte para assistência.

5. 20 Gouere 2026 da 04:10 UTCresolved

   Não observamos problemas adicionais de conectividade em nosso data center de Milão (Itália) e agora consideraremos este incidente resolvido. Se você continuar a ter problemas, por favor abra um ticket de suporte para assistência.

6. 20 Gouere 2026 da 05:45 UTCpostmortem

   A partir das 00:33 UTC em 20 de julho de 2026, alguns anfitriões no centro de dados de Milão, Itália, tornaram-se indisponíveis, impactando o acesso do cliente à Linodes. A investigação identificou que este problema ocorreu durante as atualizações programadas do firmware do roteador. Enquanto seguimos um processo de atualização faseado para evitar a interrupção do serviço, uma interseção inesperada de atividades de manutenção simultâneas levou a uma perda temporária de conectividade de rede para os hosts afetados. O serviço foi totalmente restaurado por 02:16 UTC em 20 de julho de 2026, e todos os sistemas estão agora funcionando como esperado. Internamente, estamos revisando nossos procedimentos de gerenciamento de mudanças e agendamento de manutenção para garantir uma melhor coordenação e prevenir problemas semelhantes no futuro. Pedimos desculpas pelo impacto e agradecemos a sua paciência e apoio contínuo. Estamos empenhados em fazer melhorias contínuas para melhorar nossos sistemas e prevenir a recorrência. Este resumo fornece uma visão geral da nossa compreensão atual do incidente dada a informação disponível. A nossa investigação está em curso, e qualquer informação aqui está sujeita a alterações.

Traduzido automaticamente da atualização oficial do incidente.

1. 18 Gouere 2026 da 03:34 UTCinvestigating

   A nossa equipa está a investigar um problema que afecta o serviço de armazenamento de objectos. Durante este tempo, os usuários podem experimentar timeouts de conexão e erros com este serviço.

2. 18 Gouere 2026 da 03:54 UTCidentified

   Nossa equipe identificou o problema que afeta o serviço de armazenamento de objetos. Estamos trabalhando rapidamente para implementar uma correção, e vamos fornecer uma atualização assim que a solução estiver em vigor.

3. 18 Gouere 2026 da 04:36 UTCresolved

   Não observamos quaisquer problemas adicionais com o serviço de armazenamento de objetos, e agora consideraremos este incidente resolvido. Se você continuar a ter problemas, por favor abra um ticket de suporte para assistência.

4. 21 Gouere 2026 da 15:26 UTCpostmortem

   Em 18 de julho de 2026, entre aproximadamente 00:30 UTC e 04:00 UTC, os usuários podem ter experimentado erros de 5xx ao tentar criar um novo balde no armazenamento de objetos para os seguintes objetivos. * [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) O problema começou quando a infraestrutura que suporta o armazenamento de objetos entrou em um estado degradado em todos os nós. Isso impediu o serviço de processar solicitações, resultando em falhas durante as operações de criação de baldes. Para mitigar o impacto, aplicamos uma correção no sistema de infraestrutura responsável pela criação do balde. O impacto foi atenuado após essa ação. Os nossos especialistas estão a investigar a causa principal e irão tomar as medidas preventivas adequadas. Pedimos desculpas pelo impacto e apreciamos sua paciência e apoio contínuo. Estamos fazendo mudanças de configuração e operacionais em nossos sistemas para ajudar a evitar que isso aconteça novamente, e continuamos comprometidos com a melhoria contínua. Este resumo fornece uma visão geral da nossa compreensão atual do incidente, dada a informação disponível. A nossa investigação está em curso, e qualquer informação aqui está sujeita a alterações.

Traduzido automaticamente da atualização oficial do incidente.

1. 16 Gouere 2026 da 01:24 UTCresolved

   Nossa equipe investigou um problema que afetou a conectividade em nosso data center US-MIA (Miami) entre 21:20 UTC e aproximadamente 23:28 UTC em 15 de julho de 2026. Durante esta janela, os usuários podem ter experimentado desempenho de rede degradado e perda de pacotes para serviços de computação implantados nesta região. O problema foi resolvido depois de termos implementado uma solução. Continuamos trabalhando com nosso provedor de serviços de terceiros para confirmar a causa raiz, como evidência inicial aponta para uma falha de conexão cruzada (fibra escura) no campus em sua infraestrutura.

Traduzido automaticamente da atualização oficial do incidente.

1. 14 Gouere 2026 da 12:21 UTCinvestigating

   Nossa equipe está investigando um problema de serviço emergente que afeta a API e CLI. Iremos partilhar actualizações adicionais à medida que tivermos mais informações.

2. 14 Gouere 2026 da 12:58 UTCidentified

   Nossa equipe identificou o problema que afeta o Cloud Manager e a API. Estamos trabalhando rapidamente para implementar uma correção, e vamos fornecer uma atualização assim que a solução estiver em vigor.

3. 14 Gouere 2026 da 13:11 UTCmonitoring

   Neste momento, conseguimos corrigir o problema que afeta o Cloud Manager e a API. Estaremos a acompanhar esta situação para garantir que o serviço se mantenha estável. Se você ainda estiver tendo problemas e incapaz de abrir um ticket de suporte, por favor ligue para 855-454-6633 (+1-609-380-7100 Intl.), ou envie um e-mail para [email protected].

4. 14 Gouere 2026 da 18:36 UTCmonitoring

   Continuamos monitorando quaisquer outros problemas.

5. 14 Gouere 2026 da 19:26 UTCresolved

   Não observamos quaisquer problemas adicionais com o Cloud Manager, API ou CLI, e agora consideraremos este incidente resolvido. Se você continuar a experimentar problemas, entre em contato conosco em 855-454-6633 (+1-609-380-7100 Intl.), ou envie um e-mail para [email protected] para assistência.

6. 16 Gouere 2026 da 18:13 UTCpostmortem

   Em 14 de julho de 2026, às 10:57 UTC, Akamai identificou um aumento em 502 erros e latência afetando clientes usando a API Linode, CLI e Cloud Manager. Essa interrupção resultou em impacto moderado no serviço, com os clientes relatando taxas de erro elevadas. Nossa investigação inicial rastreou a questão até a latência com os serviços do IAM, que foi resolvida, mas os erros elevados persistiram. Análise adicional por especialistas relevantes em matéria de assunto determinou que o incidente foi acionado por um failback manual para o balanceador de carga primário Cloud IAM do balanceador de carga secundário. Essa ação foi motivada por um alerta de alerta indicando que o balanceador de carga secundário estava agindo como o mestre mantido. O processo manual de iniciar e parar os serviços para iniciar o failback diferiu do processo automatizado e levou a uma cascata de conexões GRPC, causando aumento da latência e erros de API. Reiniciar os servidores API limpou as conexões antigas e restaurou as operações normais. O impacto do cliente foi atenuado por aproximadamente 13:10 UTC em 14 de julho de 2026. Para evitar recorrência, Akamai está investigando por que o failback manual causou esse comportamento. A equipe está considerando implementar um comando de drenagem para limpar conexões GRPC durante o failover e configurar alertas para detectar conexões antigas para intervenção proativa. No entanto, o foco imediato permanece na compreensão da causa raiz, com alerta e automação planejadas para fases posteriores. Vários clientes confirmaram a resolução em suas implantações. Akamai continuará a monitorar a saúde do sistema e aguardará feedback adicional do cliente antes de declarar recuperação completa. Este resumo fornece uma visão geral da nossa compreensão atual do incidente dada a informação disponível. Nossa investigação está em andamento e qualquer informação aqui está sujeita a mudanças.

Traduzido automaticamente da atualização oficial do incidente.

1. 13 Gouere 2026 da 18:29 UTCidentified

   A nossa equipa identificou um problema de serviços emergente que afecta os empregos de acolhimento de alguns anfitriões em todas as regiões. A conectividade de linodo é * não impactada*, mas alguns trabalhos de nível de host, como backups ou tentativas de ligar ou desligar seus serviços podem ser atrasados. Iremos partilhar actualizações adicionais à medida que tivermos mais informações.

2. 13 Gouere 2026 da 19:54 UTCresolved

   Este incidente foi resolvido.

Traduzido automaticamente da atualização oficial do incidente.

1. 9 Gouere 2026 da 16:57 UTCinvestigating

   Nossa equipe está investigando um problema de serviço emergente que afeta os logins do Cloud Manager. Iremos partilhar actualizações adicionais à medida que tivermos mais informações.

2. 9 Gouere 2026 da 17:24 UTCinvestigating

   Continuamos a investigar esta questão. Forneceremos uma atualização nos próximos 30 minutos.

3. 9 Gouere 2026 da 17:49 UTCmonitoring

   Neste momento, conseguimos corrigir o problema que afeta os logins do Cloud Manager. Estaremos a acompanhar esta situação para garantir que o serviço se mantenha estável. Se você ainda estiver tendo problemas e incapaz de abrir um ticket de suporte, por favor ligue para 855-454-6633 (+1-609-380-7100 Intl.), ou envie um e-mail para [email protected].

4. 9 Gouere 2026 da 18:21 UTCresolved

   Não observamos quaisquer problemas adicionais com os logins do Cloud Manager e agora consideraremos este incidente resolvido. Se você continuar a experimentar problemas, entre em contato conosco em 855-454-6633 (+1-609-380-7100 Intl.), ou envie um e-mail para [email protected] para assistência.

5. 10 Gouere 2026 da 12:30 UTCpostmortem

   Em 9 de julho de 2026, às 15:43 UTC, os clientes não puderam fazer login em [cloud.linode.com](http://cloud.linode.com) usando nome de usuário e senha. Os clientes estavam a receber uma mensagem de erro "passe errada". A investigação revelou que a questão se devia a uma emissão interna de certificado. Para mitigar o impacto, fixamos a emissão do certificado nos servidores impactados às 17:24 UTC em 9 de julho de 2026. Depois de monitorar nossos sistemas por algum tempo, confirmamos que a questão estava totalmente resolvida. Akamai irá implantar uma correção permanente para evitar uma recorrência do problema.

Traduzido automaticamente da atualização oficial do incidente.

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

   This incident has been resolved.

1. 1 Gouere 2026 da 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 Gouere 2026 da 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 Gouere 2026 da 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 Mezheven 2026 da 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 Mezheven 2026 da 19:55 UTCinvestigating

   We are continuing to investigate this issue.

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

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

5. 30 Mezheven 2026 da 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 Mezheven 2026 da 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 Gouere 2026 da 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 Mezheven 2026 da 17:35 UTCinvestigating

   Nossa equipe está investigando um problema que afeta a Cloud Pulse Metrics (ACLP Metrics), especificamente impactando o relatório da Managed Database Metrics. A questão parece ser intermitente. Iremos partilhar actualizações adicionais à medida que tivermos mais informações.

2. 26 Mezheven 2026 da 18:19 UTCinvestigating

   Continuamos a investigar esta questão. Iremos partilhar actualizações adicionais à medida que tivermos mais informações.

3. 26 Mezheven 2026 da 19:08 UTCinvestigating

   Continuamos a investigar esta questão. Nós forneceremos atualizações adicionais como temos mais informações.

4. 26 Mezheven 2026 da 20:04 UTCinvestigating

   Continuamos a investigar esta questão.

5. 26 Mezheven 2026 da 21:13 UTCmonitoring

   Não observamos uma recorrência do problema que afeta a Métrica de Pulso de Nuvem (Métricas ACLP) por várias horas. Nossa equipe continuará a monitorar o serviço de perto enquanto investigamos a causa subjacente. Se você continuar a ter problemas, por favor abra um ticket de suporte para assistência.

6. 30 Mezheven 2026 da 00:02 UTCmonitoring

   Continuamos monitorando quaisquer outros problemas.

7. 8 Gouere 2026 da 12:26 UTCresolved

   Nós não observamos quaisquer problemas adicionais com o serviço Cloud Pulse Metrics (ACLP Metrics), e agora vamos considerar este incidente resolvido. Se você continuar a ter problemas, por favor abra um ticket de suporte para assistência.

Traduzido automaticamente da atualização oficial do incidente.