Nasz zespół bada problem wpływający na usługę przechowywania obiektów w US- SEA. W tym czasie użytkownicy mogą doświadczać przerywanych błędów 5xx z tą usługą.
investigating
Nadal badamy tę kwestię.
identified
Problem został zidentyfikowany i jest w trakcie wdrażania.
resolved
Nie zaobserwowaliśmy żadnych dodatkowych problemów z usługą przechowywania obiektów, a teraz rozważamy rozwiązanie tego incydentu. Jeśli nadal masz problemy, otwórz bilet wsparcia dla pomocy.
Nasz zespół bada pojawiający się problem usług wpływających na nas - morze (Seattle, WA). Będziemy udostępniać dodatkowe aktualizacje, ponieważ mamy więcej informacji.
resolved
W tym czasie udało nam się skorygować tę kwestię i służba wznowiła normalne działanie.
Nasz zespół bada problem wpływający na łączność w naszym centrum danych IT- MIL (Mediolan). W tym czasie użytkownicy mogą doświadczać przerw w połączeniach i błędów dla wszystkich usług wprowadzonych w tym centrum danych. Będziemy udostępniać dodatkowe aktualizacje, ponieważ mamy więcej informacji.
investigating
Nadal badamy tę kwestię. Będziemy udostępniać dodatkowe aktualizacje, ponieważ mamy więcej informacji.
resolved
Nie zaobserwowaliśmy żadnych dodatkowych problemów z łącznością w naszym centrum danych IT- MIL (Mediolan) i teraz rozważamy rozwiązanie tego incydentu. Jeśli nadal masz problemy, otwórz bilet wsparcia dla pomocy.
postmortem
14 sierpnia 2026 r., począwszy od 17: 30 UTC, podczas wydarzenia w naszym centrum danych IT- MIL\ (Mediolan\), uruchomiono wiele alarmów wskazujących, że wiele hostów w tym centrum danych stało się nieosiągalnych.
Uzasadnienie
Akamai natychmiast rozpoczął śledztwo w tej sprawie i pracował nad przywróceniem wpływowych gospodarzy. Podczas okna zderzeniowego klienci doświadczyli przerw w połączeniach i błędów we wszystkich usługach wprowadzonych w tym centrum danych.
Uzasadnienie
14 sierpnia 2026 roku przywróciliśmy sprawnych gospodarzy i naprawiliśmy problemy z łącznością o godzinie 21: 20 UTC. Nadal badamy przyczynę awarii.
Uzasadnienie
Jesteśmy zaangażowani w zapobieganie przyszłym incydentom i będziemy prowadzić szczegółowe dochodzenie, dlaczego gospodarze stali się nieosiągalni, wdrażając środki w celu zwiększenia stabilności i niezawodności.
Uzasadnienie
Niniejsze podsumowanie zawiera przegląd naszego obecnego rozumienia incydentu, biorąc pod uwagę dostępne informacje. Nasze śledztwo jest w toku, a wszelkie informacje tutaj mogą ulec zmianie.
Nasz zespół bada problem wpływający na tworzenie klastrów Linode Kubernetes Engine Enterprise (LKE- E) w centrum danych IAD2 - Waszyngton. Jest to kontynuacja zgłoszonej wcześniej kwestii. Będziemy udostępniać dodatkowe aktualizacje, ponieważ mamy więcej informacji.
monitoring
Wprowadzono rozwiązanie i monitorujemy wyniki.
resolved
Ten incydent został rozwiązany.
postmortem
Między 17: 25 UTC a 22: 50 UTC w dniu 13 sierpnia 2026, Linode Kubernetes Engine Enterprise\ (LKE- E\) klienci próbujący wdrożyć G7 dedykowane instancje Linode w naszym Washington\ (IAD2\) centrum danych, otrzymał 403 komunikaty o błędach w zaopatrzeniu. Kwestia ta nie miała wpływu na aktywne ładunki robocze i uruchomione instancje.
Nasze dochodzenie wykazało, że chociaż całkowita fizyczna pojemność sprzętu w IAD2 była wystarczająca, wniosek o zasilenie rezerw spowodował niepowodzenie kontroli uprawnień z powodu początkowego progu przydziału miękkich hostów.
Akamai rozwiązał ten problem zwiększając limit linede- per- host z 5 do 20 w IAD2. Pełne możliwości rozmieszczenia zostały przywrócone i ustabilizowane o 22: 50 UTC.
Aby zapobiec ponownemu wystąpieniu, wdrożymy specjalny system ostrzegania o uprawnieniach i możliwościach, bezpośrednio związany z podręcznikami do reagowania na szybkie działania naprawcze. Dodatkowo budujemy scentralizowany przegląd pojemności deski rozdzielczej, aby aktywnie śledzić regionalną centralę.
Niniejsze podsumowanie zawiera przegląd naszego obecnego rozumienia incydentu, biorąc pod uwagę dostępne informacje. Nasze śledztwo jest w toku i wszelkie informacje tutaj mogą ulec zmianie.
Nasz zespół bada pojawiający się problem dotyczący API we wszystkich regionach. Będziemy udostępniać dodatkowe aktualizacje, ponieważ mamy więcej informacji.
monitoring
Od 19: 30 UTC jest w stanie skorygować problem dotyczący API we wszystkich regionach. Będziemy to monitorować, aby zapewnić stabilność usług. Jeśli nadal masz problemy i nie możesz otworzyć Biletu Wsparcia, zadzwoń do nas pod numer 855- 454- 6633 (+ 1-609- 380- 7100 Intl.) lub wyślij e-mail na adres support @ linode.com.
monitoring
Nadal monitorujemy wszelkie dalsze problemy.
resolved
Ten incydent został rozwiązany.
postmortem
W dniu 13 sierpnia 2026 r., około 18: 15 UTC, Akamai zaobserwował krótki przerw w świadczeniu usług mających wpływ na [_ api.linode.com _] (http: / / api.linode.com). Całkowita przerwa w obsłudze trwała około 3 minut, kończąc o 18: 18 UTC. Po przywróceniu początkowej łączności, podwyższone opóźnienie reakcji API utrzymywało się do 19: 06 UTC, powodując spowolnienie czasu reakcji i okresowe opóźnienia dla klientów działających z usługami API.
W celu rozwiązania problemu wpływu na osiągi zespoły inżynieryjne Akamai stwierdziły rozbieżność konfiguracji drugiego węzła infrastruktury buforującej, która uniemożliwiła jej absorpcję całego obciążenia ruchem po awarii. Inżynierowie ukończyli kontrolowaną migrację i przenieśli wniosek do głównego gospodarza. Po tej zmianie opóźnienie API gwałtownie spadło do normalnego poziomu operacyjnego.
Stan początkowy został wywołany przez nieoczekiwany restart głównego gniazda buforującego. Podczas gdy zbędna infrastruktura była aktywna, węzeł drugorzędny nie był w stanie bezproblemowo przetwarzać niesprawności ruchu, powodując wydłużoną degradację wydajności.
Nasze zespoły inżynieryjne prowadzą dalsze badania nad mechanizmami przełączania awaryjnego, aby zoptymalizować prędkość wykonania i wyrównać ustawienia konfiguracji pomiędzy zbędnymi węzłami, zapewniając, że systemy wtórne mogą bezproblemowo obsługiwać ruch w przyszłych wydarzeniach.
Niniejsze podsumowanie zawiera przegląd naszego obecnego rozumienia incydentu, biorąc pod uwagę dostępne informacje. Nasze śledztwo jest w toku i wszelkie informacje tutaj mogą ulec zmianie.
Nasz zespół bada problem dotyczący silnika Linode Kubernetes (LKE). Będziemy udostępniać dodatkowe aktualizacje, ponieważ mamy więcej informacji.
monitoring
W tym czasie udało nam się skorygować kwestie mające wpływ na usługę LKE. Będziemy to monitorować, aby zapewnić jego stabilność. Jeśli nadal masz problemy, otwórz bilet wsparcia dla pomocy.
resolved
Nie zauważyliśmy żadnych dodatkowych problemów z LKE, a teraz rozważamy rozwiązanie tego incydentu. Jeśli nadal masz problemy, otwórz bilet wsparcia dla pomocy.
postmortem
Począwszy od około 14: 50 UTC 13 sierpnia 2026, klienci, którzy próbowali dostarczyć Linode Kubernetes Engine Enterprise\ (LKE- E\) klastry w centrum danych IAD2 nie byli w stanie. Zidentyfikowaliśmy, że problem wynika z wyłączenia dwóch komponentów w IAD2 z najnowszej wersji oprogramowania, co doprowadziło do niedopasowania API.
Zaktualizowaliśmy zidentyfikowane komponenty, aby były zsynchronizowane z oczekiwanym stanem. W dniu 13 sierpnia 2026 r.
Aby zapobiec temu problemowi w przyszłości, przeglądamy procesy aktualizacji oprogramowania LKE, aby zapewnić, że wszystkie komponenty uzupełniają aktualizacje wersji przed ponownym wprowadzeniem do serwisu podczas aktualizacji oprogramowania platformy.
Niniejsze podsumowanie zawiera przegląd naszego obecnego rozumienia incydentu, biorąc pod uwagę dostępne informacje. Nasze śledztwo jest w toku i wszelkie informacje tutaj mogą ulec zmianie.
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.
postmortem
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.
Upstream Issues - Ubuntu
Początek 10 sierpnia 2026 17:15 UTC · 11d 1h
Pending
investigating
Nasz zespół bada problem wpływający na rozmieszczenie Ubuntu. Może to mieć wpływ na możliwość instalacji pakietów i aktualizacji bezpieczeństwa we wszystkich systemach Ubuntu.
investigating
Nadal badamy tę kwestię. Zaangażowani są odpowiedni specjaliści ds. tematycznych. Kolejne aktualizacje dotyczące statusu łagodzenia zmiany klimatu zostaną opublikowane w miarę postępów.
identified
Zidentyfikowaliśmy przyczynę tej kwestii i wprowadza się rozwiązanie. Dostarczymy aktualizację zaraz po wprowadzeniu rozwiązania.
resolved
Możemy potwierdzić, że problem został złagodzony o 06: 30 UTC w dniu 20 sierpnia 2026 i usługa wznowiła normalne operacje.
Nasz zespół bada utratę pakietów na niektórych ścieżkach z centrów danych in- maa & in- bom-2 do regionu USA. W tym czasie użytkownicy mogą doświadczać przerw w połączeniach i błędów z usługami przemierzającymi regiony Indii i Stanów Zjednoczonych. Będziemy udostępniać dodatkowe aktualizacje, ponieważ mamy więcej informacji.
identified
Nasz zespół zidentyfikował przyczynę utraty pakietów w naszych amerykańskich centrach danych. Współpracujemy z naszym dostawcą wyższego szczebla w celu rozwiązania tej kwestii i dostarczymy aktualizację zaraz po wprowadzeniu rozwiązania.
identified
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.
resolved
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.
postmortem
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.
Nasz zespół bada problem wpływający na usługę przechowywania danych w kilku regionach. Kwestia ta w dużej mierze wpływa na przyłączenie i odłączenie magazynów bloku. W tym czasie użytkownicy mogą doświadczyć z tą usługą powieszeń, timeout i błędów dotyczących wolumenu. Będziemy udostępniać dodatkowe aktualizacje, ponieważ mamy więcej informacji.
identified
Nasz zespół zidentyfikował problem wpływający na usługę przechowywania danych w naszych centrach danych. Pracujemy szybko nad wdrożeniem rozwiązania i dostarczymy aktualizację, jak tylko rozwiązanie zostanie wprowadzone.
identified
Chcielibyśmy zaktualizować, że po dodatkowym dochodzeniu wpływ ten ujawniłby się w opóźnionych, a czasem nieudanych miejscach pracy gospodarza, które mogłyby obejmować wiele różnych działań na Linodach, a nie tylko wpływając na przyłączenie i odłączenie woluminów magazynowych bloków, o których wspominaliśmy w naszej początkowej aktualizacji, zaktualizowaliśmy tytuł, aby odzwierciedlić zaktualizowany wpływ. Pracujemy szybko nad wdrożeniem rozwiązania i dostarczymy aktualizację, jak tylko rozwiązanie zostanie wprowadzone.
monitoring
Wprowadzono rozwiązanie i monitorujemy wyniki.
resolved
Nie zaobserwowaliśmy żadnych dodatkowych problemów z degradacją wyników pracy, a teraz rozważmy rozwiązanie tego incydentu. Jeśli nadal masz problemy, otwórz bilet wsparcia dla pomocy.
postmortem
W dniu 27 lipca 2026 r. o godzinie 3: 30 czasu UTC, Akamai zaobserwował wzrost błędów podczas podłączania się do bazy danych hostingowych Linode, głównie wpływając na załączniki wolumenu pamięci bloku. Spowodowało to niepowodzenie pracy gospodarza i ograniczony wpływ na klienta, a niektórzy użytkownicy doświadczają komunikatów błędów i przerywanych przepływów pracy. Podwyższone wskaźniki timeout zostały odnotowane w dziennikach dla niektórych miejsc centrum danych, zbierając się z przyrostowym wprowadzania nowej flagi funkcji.
Wstępne dochodzenie ujawniło przerywane zrzuty pakietów z proxy bazy danych do hostów klienta podczas uścisku dłoni TLS. Obecna teoria sugeruje, że osiągnięto limit ochrony DDoS- związany z pakietem MTU ścieżki zbyt duże wiadomości ICMP. Kiedy proxy wysłał pakiety TCP z dużym MTU, spodziewane wiadomości ICMP zostały wycofane przez wrota Dallas routery z powodu przekroczenia skonfigurowanej dozwolonej stawki. Spowodowało to połączenie proxy bazy danych TCP do timeout do obliczania hostów. Problem został wywołany przez enablement nowej flagi funkcji, która zmieniła ścieżkę routingu i usunęła zaciski MTU zanim pakiety dotarły do bram.
Aby złagodzić tę kwestię, Akamai wycofał niedawne zmiany w sieci w obrębie dotkniętych stron Compute, począwszy od 20: 50 UTC. Począwszy od 22: 57 UTC, wskaźnik usług ponownie wraca do poziomu sprzed incydentu. Akamai planuje również zmianę w celu zwiększenia dopuszczalnego progu dla pakietów zbyt dużych wiadomości ICMP.
Niniejsze podsumowanie zawiera przegląd naszego obecnego rozumienia incydentu, biorąc pod uwagę dostępne informacje. Nasze śledztwo jest w toku i wszelkie informacje tutaj mogą ulec zmianie.
Nasz zespół bada obecnie kwestię łączności z Linodami w regionie Włoch (Mediolan). W tym czasie istniejące w tym miejscu Linody mogą być nieosiągalne. Należy pamiętać, że tworzenie nowych Linodes działa normalnie i pozostaje nienaruszone.
investigating
Nadal badamy tę kwestię. Dostarczymy kolejną aktualizację w miarę postępów.
investigating
Nasz zespół zidentyfikował problem wpływający na łączność w naszym centrum danych Mediolanu (Włochy). Pracujemy szybko nad wdrożeniem rozwiązania i dostarczymy aktualizację, jak tylko rozwiązanie zostanie wprowadzone.
monitoring
W tym czasie udało nam się skorygować problemy wpływające na łączność w naszym centrum danych Mediolanu (Włochy). Będziemy to monitorować, aby zapewnić jego stabilność. Jeśli nadal masz problemy, otwórz bilet wsparcia dla pomocy.
resolved
Nie zaobserwowaliśmy żadnych dodatkowych problemów z łącznością w naszym centrum danych Mediolanu (Włochy) i teraz rozważamy rozwiązanie tego incydentu. Jeśli nadal masz problemy, otwórz bilet wsparcia dla pomocy.
postmortem
Począwszy od około 00: 33 UTC 20 lipca 2026, niektórzy gospodarze w Mediolanie, włoskie centrum danych stały się niedostępne, wpływając na dostęp klientów do Linodes. Dochodzenie wykazało, że problem ten miał miejsce podczas aktualizacji oprogramowania do rutynowych programów operacyjnych. Podczas gdy podążamy za etapowym procesem modernizacji, aby zapobiec zakłóceniom w obsłudze, niespodziewane skrzyżowanie równoległych czynności konserwacyjnych doprowadziło do tymczasowej utraty łączności sieciowej dla poszkodowanych hostów. Usługa została całkowicie przywrócona do 02: 16 UTC 20 lipca 2026, a wszystkie systemy działają zgodnie z oczekiwaniami. Wewnętrznie dokonujemy przeglądu naszych procedur zarządzania zmianami i harmonogramów utrzymania w celu zapewnienia lepszej koordynacji i zapobiegania podobnym problemom w przyszłości. Przepraszamy za wpływ i dziękujemy za cierpliwość i dalsze wsparcie. Jesteśmy zobowiązani do ciągłego ulepszania naszych systemów i zapobiegania nawrotom. Niniejsze podsumowanie zawiera przegląd naszego obecnego rozumienia incydentu, biorąc pod uwagę dostępne informacje. Nasze śledztwo jest w toku, a wszelkie informacje tutaj mogą ulec zmianie.
Nasz zespół bada problem wpływający na usługę przechowywania obiektów. W tym czasie użytkownicy mogą doświadczać przerw w połączeniach i błędów przy pomocy tej usługi.
identified
Nasz zespół zidentyfikował problem wpływający na usługę przechowywania obiektów. Pracujemy szybko nad wdrożeniem rozwiązania i dostarczymy aktualizację, jak tylko rozwiązanie zostanie wprowadzone.
resolved
Nie zaobserwowaliśmy żadnych dodatkowych problemów z usługą przechowywania obiektów, a teraz rozważamy rozwiązanie tego incydentu. Jeśli nadal masz problemy, otwórz bilet wsparcia dla pomocy.
postmortem
W dniu 18 lipca 2026 r., między około 00: 30 UTC a 04: 00 UTC, użytkownicy mogli doświadczyć błędów 5xx podczas próby stworzenia nowego wiadra w magazynie obiektów dla następujących punktów końcowych.
* [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)
Problem rozpoczął się, gdy infrastruktura wspierająca Magazynowanie obiektów weszła w stan zdegradowany we wszystkich węzłach. Dzięki temu usługa nie mogła być rozpatrywana, co doprowadziło do awarii podczas operacji tworzenia wiader.
W celu złagodzenia skutków zastosowaliśmy rozwiązanie w systemie oparcia odpowiedzialnego za tworzenie wiadra. Wpływ ten został złagodzony w wyniku tego działania.
Nasza tematyka ekspertów bada przyczyny i podejmie odpowiednie działania zapobiegawcze.
Przepraszamy za wpływ i doceniamy Państwa cierpliwość i stałe wsparcie. Wprowadzamy do naszych systemów konfigurację i zmiany operacyjne, aby zapobiec ponownemu wystąpieniu tego zjawiska i nadal angażujemy się w ciągłe doskonalenie.
Niniejszy streszczenie zawiera przegląd naszego obecnego rozumienia incydentu, biorąc pod uwagę dostępne informacje. Nasze śledztwo jest w toku, a wszelkie informacje tutaj mogą ulec zmianie.
Nasz zespół badał problem, który wpłynął na łączność w naszym centrum danych US- MIA (Miami) między 21: 20 UTC i około 23: 28 UTC 15 lipca 2026. Podczas tego okna użytkownicy mogli doświadczyć zdegradowanej wydajności sieciowej i utraty pakietów dla usług obliczeniowych wdrożonych w tym regionie.
Problem został rozwiązany po wdrożeniu poprawki. Kontynuujemy współpracę z naszym dostawcą usług trzeciej partii w celu potwierdzenia przyczyny, jak wstępne dowody wskazują na skrzyżowanie kampusu (ciemnego włókna) przerw w ich infrastrukturze.
Nasz zespół prowadzi śledztwo w sprawie pojawiających się usług wpływających na API i CLI. Będziemy udostępniać dodatkowe aktualizacje, ponieważ mamy więcej informacji.
identified
Nasz zespół zidentyfikował problem dotyczący Cloud Manager i API. Pracujemy szybko nad wdrożeniem rozwiązania i dostarczymy aktualizację, jak tylko rozwiązanie zostanie wprowadzone.
monitoring
W tym czasie udało nam się naprawić problem wpływający na Cloud Manager i API. Będziemy to monitorować, aby zapewnić stabilność usług. Jeśli nadal masz problemy i nie możesz otworzyć Biletu Wsparcia, zadzwoń do nas pod numer 855- 454- 6633 (+ 1-609- 380- 7100 Intl.) lub wyślij e-mail na adres support @ linode.com.
monitoring
Nadal monitorujemy wszelkie dalsze problemy.
resolved
Nie zaobserwowaliśmy żadnych dodatkowych problemów z Cloud Manager, API, czy CLI, i teraz uznamy ten incydent za rozwiązany. Jeśli nadal będziesz doświadczał problemów, skontaktuj się z nami pod adresem 855- 454- 6633 (+ 1- 609- 380- 7100 Intl.) lub wyślij e-mail na adres support @ linode.com dla pomocy.
postmortem
W dniu 14 lipca 2026 r., o godzinie 10: 57 UTC, Akamai stwierdził wzrost liczby błędów i opóźnień 502 mających wpływ na klientów korzystających z Linode API, CLI i Cloud Manager. To zakłócenie doprowadziło do umiarkowanego wpływu usług, a klienci zgłaszają podwyższone poziomy błędów. Nasze wstępne śledztwo doprowadziło do opóźnienia w świadczeniu usług IAM, które zostało rozwiązane, ale nadal utrzymywały się wysokie błędy.
Dalsza analiza przeprowadzona przez odpowiednich ekspertów w zakresie tematyki wykazała, że incydent został wywołany przez ręczną awarię głównego balancera obciążenia w Cloud IAM z drugiego balancera obciążenia. Akcja ta została wywołana ostrzeżeniem wskazującym, że drugorzędny balancer ładunkowy działał jak mistrz z cepepalived. Ręczny proces uruchamiania i zatrzymywania usług do inicjowania awarii różnił się od zautomatyzowanego procesu i doprowadził do kaskady przestarzałych połączeń GRPC, powodując wzrost opóźnienia i błędów API. Przywrócenie serwerów API oczyściło nieregularne połączenia i przywróciło normalne operacje. Wpływ na klienta został zmniejszony o około 13: 10 UTC 14 lipca 2026.
Aby zapobiec nawrotom, Akamai bada, dlaczego ręczna awaria spowodowała to zachowanie. Zespół rozważa wdrożenie polecenia odwadniania w celu oczyszczenia połączeń GRPC podczas awarii i ustanowienia alarmów w celu wykrycia połączeń niestawnych dla aktywnej interwencji. Jednakże natychmiastowa koncentracja pozostaje na zrozumieniu zasadniczej przyczyny, z ostrzeżeniem i automatyzacją zaplanowaną na późniejsze etapy.
Kilku klientów potwierdziło rozdzielczość w całym wdrożeniu. Akamai będzie nadal monitorować zdrowie systemu i czeka na dodatkowe opinie klientów przed zadeklarowaniem pełnego odzyskania.
Niniejsze podsumowanie zawiera przegląd naszego obecnego rozumienia incydentu, biorąc pod uwagę dostępne informacje. Nasze śledztwo jest w toku i wszelkie informacje tutaj mogą ulec zmianie.
Nasz zespół zidentyfikował pojawiający się problem usług wpływających na miejsca pracy dla niektórych gospodarzy we wszystkich regionach. Łączność linodowa jest * nie ma wpływu *, ale niektóre zadania na poziomie hosta, takie jak kopie zapasowe lub próby zasilania lub wyłączenia usług mogą być opóźnione. Będziemy udostępniać dodatkowe aktualizacje, ponieważ mamy więcej informacji.
Nasz zespół bada pojawiające się problemy z usługą wpływające na loginy Cloud Manager. Będziemy udostępniać dodatkowe aktualizacje, ponieważ mamy więcej informacji.
investigating
Nadal badamy tę kwestię. Dostarczymy aktualizację w ciągu najbliższych 30 minut.
monitoring
W tym czasie udało nam się naprawić problem wpływający na loginy Cloud Manager. Będziemy to monitorować, aby zapewnić stabilność usług. Jeśli nadal masz problemy i nie możesz otworzyć Biletu Wsparcia, zadzwoń do nas pod numer 855- 454- 6633 (+ 1-609- 380- 7100 Intl.) lub wyślij e-mail na adres support @ linode.com.
resolved
Nie zaobserwowaliśmy żadnych dodatkowych problemów z logowaniem Cloud Manager i uznamy ten incydent za rozwiązany. Jeśli nadal będziesz doświadczał problemów, skontaktuj się z nami pod adresem 855- 454- 6633 (+ 1- 609- 380- 7100 Intl.) lub wyślij e-mail na adres support @ linode.com dla pomocy.
postmortem
W dniu 9 lipca 2026 r., o godzinie 15: 43 UTC, klienci nie mogli zalogować się do [cloudd.linode.com] (http: / / cloudd.linode.com) używając nazwy użytkownika i hasła. Klienci dostawali komunikat błędu "błędne hasło".
Dochodzenie wykazało, że kwestia ta wynika z wydania certyfikatu wewnętrznego.
Aby złagodzić wpływ, ustaliliśmy wydanie certyfikatu na bitych serwerach o 17: 24 UTC 9 lipca 2026. Po pewnym czasie monitorowania naszych systemów potwierdziliśmy, że problem został w pełni rozwiązany.
Akamai wprowadzi stałe rozwiązanie, aby zapobiec powtórzeniu się problemu.
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.
resolved
This incident has been resolved.
Service Issue - Linode Automated Networking
Początek 1 lipca 2026 17:21 UTC · 1h 6m
Pending
Dotknięte komponenty
Cloud Manager and API
identified
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.
monitoring
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.
resolved
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.
Service Issue - Block Storage - Singapore Expansion, SP (sg-sin-2)
Początek 30 czerwca 2026 18:54 UTC · 4h 28m
IssuesDrobny incydent
Dotknięte komponenty
SG-SIN-2 (Singapore 2) Block Storage
investigating
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.
investigating
We are continuing to investigate this issue.
identified
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.
identified
We are continuing to work on a fix for this issue.
monitoring
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.
resolved
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.
postmortem
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.
Numer usługi - ACCP Metrics
Początek 26 czerwca 2026 17:35 UTC · 11d 18h
IssuesDrobny incydent
Dotknięte komponenty
Akamai Cloud Pulse (ACLP) - Metrics
investigating
Nasz zespół bada problem wpływający na wskaźniki pulsu w chmurze (ACLP Metrics), szczególnie wpływając na raportowanie Metrics Managed Database. Wygląda na to, że problem jest przerywany. Będziemy udostępniać dodatkowe aktualizacje, ponieważ mamy więcej informacji.
investigating
Nadal badamy tę kwestię. Będziemy udostępniać dodatkowe aktualizacje, ponieważ mamy więcej informacji.
investigating
Nadal badamy tę kwestię. Dostarczymy dalsze aktualizacje, ponieważ mamy więcej informacji.
investigating
Nadal badamy tę kwestię.
monitoring
Przez kilka godzin nie zaobserwowaliśmy nawrotu problemu wpływającego na wskaźniki pulsu w chmurze (ACLP Metrics). Nasz zespół będzie nadal uważnie monitorować służbę, podczas gdy my będziemy badać przyczynę. Jeśli nadal masz problemy, otwórz bilet wsparcia dla pomocy.
monitoring
Nadal monitorujemy wszelkie dalsze problemy.
resolved
Nie zaobserwowaliśmy żadnych dodatkowych problemów z usługą Cloud Pulse Metrics (ACLP Metrics), a teraz rozważamy rozwiązanie tego incydentu. Jeśli nadal masz problemy, otwórz bilet wsparcia dla pomocy.