Linode 장애 기록

1. 2026년 8월 24일 PM 9:52 UTCinvestigating

   우리 팀은 미국 SEA의 Object Storage 서비스에 영향을 미치는 문제점을 조사하고 있습니다. 이 시간 동안 사용자는이 서비스에 5xx 오류를 간헐적으로 경험할 수 있습니다.

2. 2026년 8월 25일 AM 12:31 UTCinvestigating

   이 문제를 조사하고 있습니다.

3. 2026년 8월 25일 AM 12:55 UTCidentified

   문제는 식별되고 수정이 구현됩니다.

4. 2026년 8월 25일 AM 1:11 UTCresolved

   Object Storage 서비스에 대한 추가적인 문제점을 관찰하지 않고, 이 사건이 해결되었습니다. 문제가 계속되면 지원 티켓을 엽니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 8월 21일 PM 5:23 UTCinvestigating

   우리의 팀은 us-sea (Seattle, WA)에 영향을 미치는 신흥 서비스 문제점을 조사하고 있습니다. 우리는 더 많은 정보가 있기 때문에 추가 업데이트를 공유합니다.

2. 2026년 8월 21일 PM 9:59 UTCresolved

   이 시간에 우리는 문제점을 수정할 수 있고 서비스는 정상적인 가동을 재개했습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 8월 14일 PM 8:13 UTCinvestigating

   우리 팀은 IT-MIL (Milan) 데이터 센터에 대한 연결에 영향을 미치는 문제를 조사하고 있습니다. 이 시간 동안 사용자는 이 데이터 센터에서 배포 된 모든 서비스에 대한 간헐적인 연결 시간 및 오류를 경험할 수 있습니다. 우리는 더 많은 정보가 있기 때문에 추가 업데이트를 공유합니다.

2. 2026년 8월 14일 PM 9:18 UTCinvestigating

   이 문제를 조사하고 있습니다. 우리는 더 많은 정보가 있기 때문에 추가 업데이트를 공유합니다.

3. 2026년 8월 14일 PM 9:30 UTCresolved

   우리는 IT-MIL (Milan) 데이터 센터에 대한 추가적인 연결 문제들을 관찰하지 않았으며 이제이 사건이 해결되었습니다. 문제가 계속되면 지원 티켓을 엽니다.

4. 2026년 8월 18일 PM 7:02 UTCpostmortem

   8월 14, 2026일에는 IT-MIL \(Milan\) 데이터 센터의 이벤트 중에는 여러 호스트가 이 데이터 센터에 접근할 수 없다는 것을 나타내는 경고가 발생했습니다. Akamai는 즉시 문제를 조사하고 영향을받는 호스트를 복원하기 위해 노력하고 있습니다. 충격 창 도중, 고객은 이 자료 센터에서 배치된 모든 서비스의 맞은편에 intermittent 연결 timeouts 그리고 과실을 경험할 것입니다. 우리는 영향을받은 호스트를 복원하고 8 월 14 일 21:20 UTC의 연결 문제를 고정 2026. 우리는 여전히 실패 상태의 원인을 조사하고 있습니다. 우리는 미래 사건을 방지하기 위해 최선을 다하고 있으며 호스트가 신뢰성과 신뢰성을 향상시키기 위해 측정을 구현하는 데 필요한 조사를 수행 할 것입니다. 이 요약은 우리의 현재 이해에 대한 개요를 제공합니다. 우리의 조사는 진행 중이며, 여기에는 변경 될 수 있습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 8월 13일 PM 9:13 UTCinvestigating

   우리 팀은 IAD2 - Washington 데이터 센터의 Linode Kubernetes Engine Enterprise (LKE-E) 클러스터의 생성에 영향을 미치는 문제점을 조사하고 있습니다. 이것은 이전에보고 된 문제의 연속입니다. 우리는 더 많은 정보가 있기 때문에 추가 업데이트를 공유합니다.

2. 2026년 8월 13일 PM 11:02 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

3. 2026년 8월 13일 PM 11:24 UTCresolved

   이 사건은 해결되었습니다.

4. 2026년 8월 18일 PM 8:32 UTCpostmortem

   사이 17:25 UTC와 22:50 UTC 에 8월 13, 2026, Linode Kubernetes Engine Enterprise \(LKE-E\) 고객은 워싱턴 \(IAD2\) 데이터 센터에 G7 전용 Linode 인스턴스를 배포하려고 시도 403 제공 오류 메시지. Active workloads and running 인스턴스는 이 문제점에 영향을 미치지 않았습니다. 우리의 조사는 IAD2에 있는 총 물리적 하드웨어 수용량이 충분하다는 것을 계시했습니다, 준비 요청은 처음 연약한 주인 위치 문턱 때문에 부제 검사 실패를 방아쇠를 쳤습니다. Akamai는 IAD2에서 5에서 20까지의 Linode-per-host 제한을 증가하여 문제를 해결했습니다. 전체 배포 기능 복원 및 안정화 22:50 UTC. 반복을 방지하기 위해, 우리는 급속한 구제를 위한 응답 runbooks에 직접 연결한 entitlement와 수용량 문제점을 위한 바짝 죄기를 실행할 것입니다. 또한 중앙 용량 개요 대시보드를 구축하여 지역 헤드룸을 신속하게 추적합니다. 이 요약은 우리의 현재 이해에 대한 개요를 제공합니다. 우리의 조사는 진행 중이며 여기에는 변경 될 수 있습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 8월 13일 PM 6:46 UTCinvestigating

   우리의 팀은 모든 지역에서 API에 영향을 미치는 신흥 서비스 문제를 조사하고 있습니다. 우리는 더 많은 정보가 있기 때문에 추가 업데이트를 공유합니다.

2. 2026년 8월 13일 PM 7:58 UTCmonitoring

   19:30 UTC의 모든 지역에서 API에 영향을 미치는 문제를 수정할 수 있었다. 우리는 서비스를 안정적으로 유지되도록이 모니터링 할 것입니다. 문제가 발생하면 지원 티켓을 열 수 없습니다. 855-454-6633 (+1-609-380-7100 Intl.)로 전화하거나 [email protected]으로 이메일을 보내주십시오.

3. 2026년 8월 13일 PM 7:59 UTCmonitoring

   우리는 더 많은 문제를 모니터링하고 있습니다.

4. 2026년 8월 14일 AM 12:26 UTCresolved

   이 사건은 해결되었습니다.

5. 2026년 8월 17일 PM 5:38 UTCpostmortem

   8 월 13 일, 2026, 약 18:15 UTC에서, Akamai는 [ api.linode.com ](http://api.linode.com)에 영향을 미치는 간단한 서비스 정전을 관찰했습니다. 총 서비스 중단은 약 3 분 동안 지속되며 18 : 18 UTC에 가입하십시오. 초기 연결의 복원에 따라 19:06 UTC를 통해 상승 된 API 응답 대기 시간이 단축되고 API 서비스와 상호작용 지연을 유발합니다. 성능 충격을 해결하려면 Akamai 엔지니어링 팀은 실패 후 전체 트래픽 부하를 흡수하여 방지하는 보조 캐싱 인프라 노드에 구성 디펜션을 확인했습니다. 엔지니어는 제어 마이그레이션을 완료하고 이동 요청 캐싱 트래픽을 다시 1 차 호스트. 이 변화에 따라 API 대기 시간은 정상적인 운영 수준으로 빠르게 감소했습니다. 초기 상태는 기본 캐싱 노드의 물리적 호스트의 예상치 못한 재부팅에 의해 트리거되었습니다. 중복 인프라가 활성화되었지만, 이차 노드는 실패 트래픽을 원활하게 처리할 수 없으며, 확장된 성능 향상을 유발합니다. 우리의 엔지니어링 팀은 실행 속도를 최적화하고 중복 노드의 구성 설정을 정렬하기 위해 실패 메커니즘에 따라 후속 조사를 수행하고, 이차 시스템을 보장하는 것은 향후 이벤트에서 트래픽을 원활하게 처리 할 수 있습니다. 이 요약은 우리의 현재 이해에 대한 개요를 제공합니다. 우리의 조사는 진행 중이며 여기에는 변경 될 수 있습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 8월 13일 PM 4:16 UTCinvestigating

   우리의 팀은 Linode Kubernetes Engine (LKE)에 영향을 미치는 문제점을 조사하고 있습니다. 우리는 더 많은 정보가 있기 때문에 추가 업데이트를 공유합니다.

2. 2026년 8월 13일 PM 4:30 UTCmonitoring

   이번에는 LKE 서비스에 영향을 미치는 문제를 수정할 수 있었습니다. 안정적인 유지를 보장하기 위해 이것을 모니터링 할 것입니다. 문제가 계속되면 지원 티켓을 엽니다.

3. 2026년 8월 13일 PM 5:54 UTCresolved

   LKE 서비스에 대한 추가적인 문제점을 관찰하지 않고, 이 사건이 해결된 것으로 간주합니다. 문제가 계속되면 지원 티켓을 엽니다.

4. 2026년 8월 17일 PM 9:30 UTCpostmortem

   8월 13, 2026에 약 14:50 UTC에서 시작, IAD2 데이터 센터의 Linode Kubernetes Engine Enterprise \ (LKE-E\) 클러스터를 제공하려고하는 고객은 할 수 없었다. IAD2의 두 가지 구성 요소의 예외로 인해 API mismatch로 인한 최근 소프트웨어 버전 업그레이드에서 문제가 발생했습니다. 우리는 예상 상태와 동기화하여 식별 된 구성 요소를 업데이트했습니다. 8월 13, 2026에 대한 약 16시 UTC의 문제를 해결했습니다. LKE 소프트웨어 업데이트 프로세스를 검토하고, LKE 소프트웨어 업데이트 프로세스를 검토하여 플랫폼 소프트웨어 업데이트 중에 서비스로 재투자되기 전에 모든 포함 된 구성 요소 전체 버전 업그레이드를 보장합니다. 이 요약은 우리의 현재 이해에 대한 개요를 제공합니다. 우리의 조사는 진행 중이며 여기에는 변경 될 수 있습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 8월 14일 PM 3:46 UTCresolved

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

2. 2026년 8월 21일 PM 1:13 UTCpostmortem

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

1. 2026년 8월 10일 PM 5:15 UTCinvestigating

   우리 팀은 Ubuntu 배포에 영향을 미치는 업스트림 문제를 조사하고 있습니다. 이 모든 Ubuntu 시스템에 패키지 및 보안 업데이트를 설치할 수있는 능력에 영향을 줄 수 있습니다.

2. 2026년 8월 11일 PM 11:35 UTCinvestigating

   이 문제를 조사하고 있습니다. 적절한 주제는 전문가가 참여합니다. mitigation status의 지속적인 업데이트가 진행될 예정입니다.

3. 2026년 8월 12일 AM 3:29 UTCidentified

   우리는 문제의 원인을 확인하고 수정이 구현됩니다. 우리는 해결책이 장소에 있는 것처럼 곧 갱신을 제공할 것입니다.

4. 2026년 8월 21일 PM 6:40 UTCresolved

   우리는 문제가 8월 20, 2026일 오전 6시 30분 UTC에 mitigated 것을 확인하고 서비스는 정상 작동을 재개했습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 31일 PM 5:49 UTCinvestigating

   우리 팀은 인-maa & in-bom-2 데이터 센터의 일부 경로에 대한 패킷 손실을 조사하고 있습니다. 이 시간 동안 사용자는 인도와 미국 지역의 서비스 traversing과 연결 시간 및 오류를 경험할 수 있습니다. 우리는 더 많은 정보가 있기 때문에 추가 업데이트를 공유합니다.

2. 2026년 7월 31일 PM 6:25 UTCidentified

   우리의 팀은 우리의 미국 자료 센터에 소포 손실의 원인을 확인했습니다. 우리는 우리의 업스트림 공급자와 협력하여이 문제를 해결하고 솔루션이 장소에있을 때 곧 업데이트를 제공 할 것입니다.

3. 2026년 8월 4일 PM 6: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. 2026년 8월 5일 AM 1: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. 2026년 8월 5일 PM 5: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.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 28일 PM 6:14 UTCinvestigating

   저희 팀은 여러 데이터 센터 지역의 Block Storage 서비스에 영향을 미치는 문제점을 조사하고 있습니다. 이 문제는 크게 부착 및 분리 블록 스토리지 볼륨에 영향을 미칩니다. 이 시간 동안 사용자는 볼륨 첨부 / 표창, 타임 아웃 및 오류를 경험할 수 있습니다. 우리는 더 많은 정보가 있기 때문에 추가 업데이트를 공유합니다.

2. 2026년 7월 28일 PM 7:27 UTCidentified

   우리의 팀은 우리의 자료 센터에서 구획 저장 서비스에 영향을 미치는 문제점을 발견했습니다. 우리는 신속하게 수정을 구현하고, 우리는 솔루션이 장소에 있기 때문에 업데이트를 제공 할 것입니다.

3. 2026년 7월 28일 PM 8:17 UTCidentified

   우리는 추가 조사 후에 그것을 업데이트하고 싶으면, 충격은 지연되고 때때로 Linodes에 많은 다른 활동을 포함할 수 있던 주인 일에서 나타나고 우리가 우리의 처음 갱신에서 언급한 대로 연결하고 detaching 구획 저장 양에 충격을 가하지 않는, 우리는 갱신한 충격을 반영하기 위하여 제목을 새롭게 했습니다. 우리는 신속하게 수정을 구현하고, 우리는 솔루션이 장소에 있기 때문에 업데이트를 제공 할 것입니다.

4. 2026년 7월 28일 PM 10:51 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

5. 2026년 7월 29일 PM 12:27 UTCresolved

   우리는 추가 호스트 작업 성능 평가 문제를 관찰하지 않았다, 그리고 지금이 사건을 해결 고려. 문제가 계속되면 지원 티켓을 엽니다.

6. 2026년 7월 31일 PM 6:57 UTCpostmortem

   에 27 7월 2026 에 3:30 UTC, Akamai는 블록 스토리지 볼륨 첨부 파일에 영향을 미치는 Linode 호스팅 데이터베이스에 연결 할 때 오류의 증가를 관찰. 이 작업 실패 및 제한된 고객 영향으로 인해 오류 메시지와 중단 된 워크플로우를 경험하는 일부 사용자와 함께 발생합니다. 모든 데이터 센터 위치에 대한 로그에 올리는 타임 아웃 비율은 새로운 기능 플래그의 incremental rollout과 일치합니다. 초기 조사는 TLS Handhake에서 데이터베이스 프록시에서 클라이언트 호스트에 간헐적 인 패킷 드롭을 공개했습니다. 현재 이론은 MTU 패킷과 관련된 DDoS 보호 한계가 너무 큰 ICMP 메시지가 도달 한 것을 제안합니다. 프록시가 큰 MTU를 가진 TCP 패킷을 전송할 때, 예상 ICMP 메시지가 달라스 게이트웨이 라우터에 의해 축소되었다. Compute Hosts에 timeout에 데이터베이스 프록시 TCP 연결이 발생했습니다. 이 문제는 새로운 기능 플래그의 활성화에 의해 트리거되었다, 이는 여정 경로 변경 및 패킷 전에 MTU 클램핑 제거 게이트웨이에 도달. 문제를 완화하기 위해 Akamai는 20:50 UTC에서 시작된 영향을받은 Compute 사이트 전체에 최근의 네트워크 변경 사항을 다시 압연했습니다. 기준으로 22:57 UTC, 서비스 재시작의 비율은 사전 통지 수준으로 반환됩니다. Akamai는 또한 패킷의 허용 임계값을 너무 큰 ICMP 메시지로 늘리는 변경을 계획하고 있습니다. 이 요약은 우리의 현재 이해에 대한 개요를 제공합니다. 우리의 조사는 진행 중이며 여기에는 변경 될 수 있습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 20일 AM 1:52 UTCinvestigating

   우리의 팀은 현재 이탈리아 (Milan) 지역에서 Linodes에 영향을 미치는 연결 문제에 투자하고 있습니다. 이 시간 동안, 이 위치에 기존의 Linodes는 접근할 수 없습니다. 새로운 Linodes를 만드는 것은 일반적으로 작용하고 unaffected 남아 있다는 것을 주의하십시오.

2. 2026년 7월 20일 AM 2:56 UTCinvestigating

   이 문제를 조사하고 있습니다. 우리는 우리가 진전을 만들 때 다음 업데이트를 제공 할 것입니다.

3. 2026년 7월 20일 AM 3:12 UTCinvestigating

   우리 팀은 밀라노 (이탈리아) 데이터 센터의 연결에 영향을 미치는 문제를 발견했습니다. 우리는 신속하게 수정을 구현하고, 우리는 솔루션이 장소에 있기 때문에 업데이트를 제공 할 것입니다.

4. 2026년 7월 20일 AM 3:20 UTCmonitoring

   이번에는 밀라노 (이탈리아) 데이터 센터에 연결되는 문제를 수정할 수 있었습니다. 안정적인 유지를 보장하기 위해 이것을 모니터링 할 것입니다. 아직 문제가 발생하면 지원 티켓을 엽니다.

5. 2026년 7월 20일 AM 4:10 UTCresolved

   우리는 우리의 밀라노 (이탈리아) 데이터 센터에 대한 추가 연결 문제를 관찰하지 않았으며 이제이 사건이 해결 된 것을 고려합니다. 문제가 계속되면 지원 티켓을 엽니다.

6. 2026년 7월 20일 AM 5:45 UTCpostmortem

   7 월 20, 2026에 00:33 UTC를 시작, 밀라노에있는 일부 호스트, 이탈리아 데이터 센터는 Linodes에 대한 고객 액세스를 영향을받지 못했습니다. 이 문제는 예정된 라우터 펌웨어 업데이트 중에 발생했습니다. 우리는 서비스 중단을 방지하기 위해 단계 업그레이드 프로세스를 따르는 동안, 영향을받는 호스트에 대한 네트워크 연결의 임시 손실에 주도 동시 유지 보수 활동의 예기치 않은 교차. 서비스는 7 월 20, 2026에 02:16 UTC에 완전히 복원되었으며 모든 시스템은 예상대로 운영됩니다. 내부적으로, 우리는 우리의 변경 관리 및 유지 보수 스케줄링 절차를 검토하여 더 나은 조정을 보장하고 미래의 유사한 문제를 방지합니다. 우리는 영향에 대해 사과하고 당신의 인내와 지속적인 지원을 주셔서 감사합니다. 우리는 우리의 체계를 더 잘 만들고 recurrence를 방지하기 위하여 지속적인 개선을 만들기 위하여 투입됩니다. 이 요약은 우리의 현재 이해에 대한 개요를 제공합니다. 우리의 조사는 진행 중이며, 여기에는 변경 될 수 있습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 18일 AM 3:34 UTCinvestigating

   우리의 팀은 Object Storage 서비스에 영향을 미치는 문제점을 조사하고 있습니다. 이 시간 동안 사용자는이 서비스와 연결 시간 및 오류를 경험할 수 있습니다.

2. 2026년 7월 18일 AM 3:54 UTCidentified

   우리의 팀은 Object Storage 서비스에 영향을 미치는 문제점을 발견했습니다. 우리는 신속하게 수정을 구현하고, 우리는 솔루션이 장소에 있기 때문에 업데이트를 제공 할 것입니다.

3. 2026년 7월 18일 AM 4:36 UTCresolved

   Object Storage 서비스에 대한 추가적인 문제점을 관찰하지 않고, 이 사건이 해결되었습니다. 문제가 계속되면 지원 티켓을 엽니다.

4. 2026년 7월 21일 PM 3:26 UTCpostmortem

   7월 18, 2026일, 약 00:30 UTC와 04:00 UTC 사이, 사용자는 다음 엔드포인트를 위해 Object Storage의 새로운 버킷을 만들려고하면서 5xx 오류를 경험할 수 있습니다. * [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) Object Storage를 지원하는 인프라가 모든 노드를 통해 degraded state를 입력했을 때 문제가 시작되었습니다. 이 처리 요청에서 서비스를 방지, 버킷 생성 작업 중에 실패 발생. 충격을 완화하기 위해, 우리는 물통 창조에 책임있는 백엔드 체계에 고침을 적용했습니다. 이 행동을 따르는 영향이었다. 우리의 주제는 전문가가 뿌리 원인을 조사하고 적절한 예방 조치를 취할 것입니다. 우리는 영향에 대한 사과하고 당신의 인내 및 지속적인 지원을 평가합니다. 우리는 우리의 체계에 윤곽과 가동 변화가 다시 일어나고, 지속적인 개선에 투입된 것을 돕도록 돕기 위하여 변화하고 있습니다. 이 요약은 현재 사건에 대한 이해에 대한 개요를 제공합니다. 우리의 조사는 진행 중이며, 여기에는 변경 될 수 있습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 16일 AM 1:24 UTCresolved

   우리 팀은 21:20 UTC와 7월 15, 2026의 약 23:28 UTC 사이 우리의 미국 (미미) 데이터 센터에 영향을 미치는 문제에 대해 조사했습니다. 이 창에서 사용자는 이 지역에서 배포된 Compute 서비스에 대한 degraded 네트워킹 성능과 패킷 손실을 경험할 수 있습니다. 문제는 수정을 구현한 후 해결되었습니다. 우리는 우리의 제 3 자 서비스 제공 업체와 협력하여 뿌리 원인을 확인하기 위해 계속됩니다. 초기 증거는 캠퍼스 교차 연결 (dark fiber)에 대한 것입니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 14일 PM 12:21 UTCinvestigating

   우리의 팀은 API와 CLI에 영향을 미치는 신흥 서비스 문제점을 조사하고 있습니다. 우리는 더 많은 정보가 있기 때문에 추가 업데이트를 공유합니다.

2. 2026년 7월 14일 PM 12:58 UTCidentified

   우리의 팀은 Cloud Manager 및 API에 영향을 미치는 문제를 식별했습니다. 우리는 신속하게 수정을 구현하고, 우리는 솔루션이 장소에 있기 때문에 업데이트를 제공 할 것입니다.

3. 2026년 7월 14일 PM 1:11 UTCmonitoring

   이번에는 Cloud Manager와 API에 영향을 미치는 문제를 수정할 수 있었습니다. 우리는 서비스를 안정적으로 유지되도록이 모니터링 할 것입니다. 문제가 발생하면 지원 티켓을 열 수 없습니다. 855-454-6633 (+1-609-380-7100 Intl.)로 전화하거나 [email protected]으로 이메일을 보내주십시오.

4. 2026년 7월 14일 PM 6:36 UTCmonitoring

   우리는 더 많은 문제를 모니터링하고 있습니다.

5. 2026년 7월 14일 PM 7:26 UTCresolved

   Cloud Manager, API 또는 CLI와 함께 추가적인 문제점을 관찰하지 않고 이 사건이 해결된 것으로 간주합니다. 문제가 계속되면 855-454-6633 (+1-609-380-7100 Intl.)로 연락하거나 [email protected]으로 이메일을 보내주십시오.

6. 2026년 7월 16일 PM 6:13 UTCpostmortem

   7월 14, 2026, 10:57 UTC에서, Akamai는 Linode API, CLI 및 Cloud Manager를 사용하여 고객에 영향을 미치는 502 오류 및 대기 시간 증가를 확인했습니다. 이 붕괴는 온건한 서비스 충격에서 결과로, 고객 보고 높은 과실 비율. 우리의 초기 조사는 해결 된 IAM 서비스로 대기권에 대한 문제를 추적했지만, 오류가 지속되었습니다. 관련 주제에 의한 더 많은 분석은 이차 로드 밸런서에서 Cloud IAM 1 차 로드밸런서에 대한 매뉴얼이 실패한 것으로 결정했습니다. 이 행동은 경고 경고 경고에 의해 초안되었다는 것을 나타내는 이차 짐 밸런서는 keepalived 주인으로 행동했다. 시작 및 중지 서비스의 수동 프로세스는 자동화 된 프로세스와 달리 실패 및 stale GRPC 연결의 cascade에 주도, 증가 된 대기 시간 및 API 오류를 발생. API 서버가 stale 연결을 삭제하고 정상적인 작업을 복원. 고객 영향은 7월 14, 2026일 UTC에 약 13:10 UTC에 의해 투약되었습니다. recurrence를 방지하기 위해, Akamai는 왜 수동 고장이 이 행동을 발생했는지 조사하고 있습니다. 이 팀은 실패 중에 GRPC 연결을 명확하게하는 배수 명령을 구현하고 proactive 개입을 위해 stale 연결을 감지하기 위해 경고를 설정합니다. 그러나, 즉각적인 초점은 루트 원인을 이해하고, 경고 및 자동화가 나중에 단계에 계획. 몇몇 고객은 그들의 배치의 맞은편에 해결책을 확인했습니다. Akamai는 시스템 건강을 모니터링하고 전체 복구를 선언하기 전에 추가 고객 피드백을 기다립니다. 이 요약은 우리의 현재 이해에 대한 개요를 제공합니다. 우리의 조사는 진행 중이며 여기에는 변경 될 수 있습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 13일 PM 6:29 UTCidentified

   우리 팀은 모든 지역에서 호스트 작업에 영향을 미치는 새로운 서비스 문제를 발견했습니다. Linode 연결은 *not impacted*이지만, 백업과 같은 일부 호스트 수준의 작업이나 서비스에 전원을 시도하면 지연 될 수 있습니다. 우리는 더 많은 정보가 있기 때문에 추가 업데이트를 공유합니다.

2. 2026년 7월 13일 PM 7:54 UTCresolved

   이 사건은 해결되었습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 9일 PM 4:57 UTCinvestigating

   Cloud Manager 로그인에 영향을 미치는 새로운 서비스 문제점을 조사하고 있습니다. 우리는 더 많은 정보가 있기 때문에 추가 업데이트를 공유합니다.

2. 2026년 7월 9일 PM 5:24 UTCinvestigating

   이 문제를 조사하고 있습니다. 우리는 다음 30 분 안에 업데이트를 제공 할 것입니다.

3. 2026년 7월 9일 PM 5:49 UTCmonitoring

   이때 Cloud Manager 로그인에 영향을 미치는 문제를 수정할 수 있었습니다. 우리는 서비스를 안정적으로 유지되도록이 모니터링 할 것입니다. 문제가 발생하면 지원 티켓을 열 수 없습니다. 855-454-6633 (+1-609-380-7100 Intl.)로 전화하거나 [email protected]으로 이메일을 보내주십시오.

4. 2026년 7월 9일 PM 6:21 UTCresolved

   Cloud Manager 로그인으로 추가적인 문제점을 관찰하지 않고 이 사건이 해결된 것으로 간주합니다. 문제가 계속되면 855-454-6633 (+1-609-380-7100 Intl.)로 연락하거나 [email protected]으로 이메일을 보내주십시오.

5. 2026년 7월 10일 PM 12:30 UTCpostmortem

   7월 9, 2026, at 15:43 UTC, 고객은 사용자 이름과 암호를 사용하여 [cloud.linode.com](http://cloud.linode.com)에 로그인할 수 없습니다. 고객은 "잘못된 암호" 오류 메시지가 발생했습니다. Investigation은 내부 인증서 문제로 인해 문제가 발생했습니다. 충격을 완화하려면 7 월 9, 2026의 17 : 24 UTC의 영향 서버에서 인증서 문제를 해결했습니다. 몇 시간 동안 우리의 시스템을 모니터링 한 후, 우리는 문제가 완전히 해결되었습니다. Akamai는 문제의 재발을 방지하기 위해 영구적인 수정을 배포합니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 6일 PM 6: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. 2026년 7월 7일 PM 3:31 UTCresolved

   This incident has been resolved.

1. 2026년 7월 1일 PM 5: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. 2026년 7월 1일 PM 6: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. 2026년 7월 1일 PM 6: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. 2026년 6월 30일 PM 6: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. 2026년 6월 30일 PM 7:55 UTCinvestigating

   We are continuing to investigate this issue.

3. 2026년 6월 30일 PM 8: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. 2026년 6월 30일 PM 9:36 UTCidentified

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

5. 2026년 6월 30일 PM 10: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. 2026년 6월 30일 PM 11: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. 2026년 7월 2일 PM 4: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. 2026년 6월 26일 PM 5:35 UTCinvestigating

   우리의 팀은 Cloud Pulse Metrics (ACLP Metrics)에 영향을 미치는 문제점을 조사하고, 특히 Managed Database Metrics Reporting에 영향을 미칩니다. 문제는 intermittent로 나타납니다. 우리는 더 많은 정보가 있기 때문에 추가 업데이트를 공유합니다.

2. 2026년 6월 26일 PM 6:19 UTCinvestigating

   이 문제를 조사하고 있습니다. 우리는 더 많은 정보가 있기 때문에 추가 업데이트를 공유합니다.

3. 2026년 6월 26일 PM 7:08 UTCinvestigating

   이 문제를 조사하고 있습니다. 우리는 더 많은 정보가 있기 때문에 더 많은 업데이트를 제공할 것입니다.

4. 2026년 6월 26일 PM 8:04 UTCinvestigating

   이 문제를 조사하고 있습니다.

5. 2026년 6월 26일 PM 9:13 UTCmonitoring

   우리는 몇 시간 동안 Cloud Pulse Metrics (ACLP Metrics)에 영향을 미치는 문제의 반복성을 관찰하지 않았습니다. 우리의 팀은 우리가 underlying 원인을 조사하면서 긴밀한 서비스를 모니터링 할 것입니다. 문제가 계속되면 지원 티켓을 엽니다.

6. 2026년 6월 30일 AM 12:02 UTCmonitoring

   우리는 더 많은 문제를 모니터링하고 있습니다.

7. 2026년 7월 8일 PM 12:26 UTCresolved

   Cloud Pulse Metrics (ACLP Metrics) 서비스에 대한 추가 문제를 관찰하지 않고이 사건이 해결되었습니다. 문제가 계속되면 지원 티켓을 엽니다.

공식 인시던트 업데이트를 자동 번역했습니다.