Historia awarii Jira

1. 21 października 2026 14:28 UTCinvestigating

   Badamy problem wpływający na boczny pasek i nawigację projektu w Jira Cloud. Użytkownicy mogą napotkać timeout lub brakujące menu podczas próby uzyskania dostępu do widoku projektu. Zespoły aktywnie analizują telemetrię w celu określenia łagodzenia skutków. Dostarczymy naszą następną aktualizację za 60 minut, albo wcześniej.

2. 21 października 2026 15:01 UTCmonitoring

   Zakłócenia zostały wprowadzone, a my widzimy ożywienie w obrębie służb nawigacji Jira Cloud. Boki projektu są teraz ładowane zgodnie z oczekiwaniami. Nasze zespoły nadal monitorują sytuację i spodziewamy się potwierdzenia pełnej rezolucji w naszej następnej aktualizacji za godzinę lub wcześniej.

3. 21 października 2026 15:45 UTCresolved

   W dniu 21 października 2026 r. użytkownicy JIRA, JSM, JPD i JWM mogli doświadczyć degradacji wydajności wpływającej na boczny pasek i nawigację projektu. Problem został teraz rozwiązany, a usługa działa normalnie dla wszystkich klientów dotkniętych.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 1 października 2026 02:55 UTCinvestigating

   Przetwarzanie pracy i harmonogram pracy jest degradowany, co wpływa na zaplanowaną i asynchroniczną pracę wielu produktów, w tym Jira, Confluence i Bitbucket Cloud. Dotknięci użytkownicy mogą zobaczyć opóźnione lub brak wykonania zadania, w tym opóźnione przetwarzanie biletów e-mail i harmonogramy, które nie działają zgodnie z oczekiwaniami.

2. 1 października 2026 03:47 UTCidentified

   Nasze zespoły zidentyfikowały przyczynę tego incydentu i teraz aktywnie pracują nad złagodzeniem problemu. Dostarczymy dalsze aktualizacje w ciągu godziny lub wcześniej, jeśli będziemy mieli do przekazania jakiekolwiek znaczące postępy.

3. 1 października 2026 04:03 UTCidentified

   Nasze zespoły podjęły działania naprawcze w celu złagodzenia tej kwestii i obserwują pewne ulepszenia. Kontynuujemy monitorowanie sytuacji i podejmiemy niezbędne działania, aż do całkowitego odzyskania tego incydentu.

4. 1 października 2026 05:00 UTCidentified

   Nasze zespoły nadal pracują nad naprawą, aż do całkowitego rozwiązania tego incydentu. Dostarczymy dalsze aktualizacje, jeśli będziemy mieli znaczący postęp do podzielenia. Wraz z wpływem na zaplanowaną i asynchroniczną pracę wielu produktów, zidentyfikowaliśmy również komponent SLA w Jira Service Management nie pojawia się zgodnie z oczekiwaniami.

5. 1 października 2026 07:01 UTCidentified

   Nasze zespoły nadal pracują nad naprawą, aż do całkowitego rozwiązania tego incydentu. Dostarczymy dalsze aktualizacje, jeśli będziemy mieli znaczący postęp do podzielenia. Istnieje również wpływ na nowe bilety wsparcia utworzone w odniesieniu do brakującego komponentu SLA, powiadomienia, które mogą mieć wpływ na czas reakcji i zarządzanie zaległościami niektórych biletów.

6. 1 października 2026 07:51 UTCresolved

   W dniu 01. października 2026 r., między 01: 00 UTC a 07: 25 UTC, użytkownicy mogli widzieć brakujące wykonanie zadania, w tym opóźnione przetwarzanie biletów e-mail i harmonogramy, które nie działają zgodnie z oczekiwaniami. Teraz wdrożyliśmy naprawę i usługi zostały przywrócone do normalnej eksploatacji dla dotkniętych klientów. Wpływ na wsparcie biletów za pomocą brakującego komponentu SLA i opóźnionych powiadomień potwierdził również odzyskanie. Uwaga: W przypadku klientów Bitbucket, jeżeli w oknie incydentu nie było żadnych zaplanowanych rurociągów, można poczekać na następne zaplanowane wykonanie lub uruchomić je ręcznie.

7. 9 października 2026 18:24 UTCpostmortem

   Podsumowanie W dniu 1 października 2026 r., między 01: 00 a 07: 25 UTC, zdegradowane przetwarzanie i planowanie pracy wpłynęły na produkty Atlassian w tym Bitbucket Cloud, Confluence, Forge aplikacje, Jira, i Jira Service Management we wszystkich komercyjnych regionach chmury. Spowodowało to opóźnione lub pominięte zadania w tle, takie jak przetwarzanie biletów e-mail i planowane rurociągi; interaktywne wykorzystanie produktu nie miało wpływu. Wydarzenie zostało wywołane, gdy niespodziewany wolumen zaplanowanych zadań stał się należny jednocześnie, przytłaczając naszą wspólną platformę planowania zadań. Automatyczne monitorowanie wykryło incydent w ciągu trzech minut. Odzysk rozpoczął się około 03: 45 UTC jako zdolności inżynieryjne skalowane i platforma pracował przez zaległości, z pełną rozdzielczość osiągnąć w 6 godzin i 25 minut. IMPACT Większość zaplanowanych zadań przestała działać o godzinie 01: 00 UTC i została wznowiona od około 03: 45 UTC. Większość opóźnionych prac natknęła się na około 06: 00 UTC, a pozostałe opóźnienia zostały wyjaśnione o 07: 25 UTC. Produkty, na które wpływ ma: - Powtarzanie zaplanowanych zadań pominiętych lub opóźnionych w czasie incydentu; pominięte operacje nie były automatycznie ponownie uruchomione, a zadania wznowione w następnym zaplanowanym czasie. - Większość zaplanowanych zadań była opóźniona; niewielka liczba może nie być uruchomiona. - Zasady automatyzacji, w tym zasady rozkładowe, działały normalnie, z wyjątkiem przypadków wymienionych poniżej. Bitbucket Cloud Zaplanowane rurociągi w godzinach od 01: 00 do około 03: 50 UTC nie działały. Jeśli w czasie incydentu nie uruchomiono zaplanowanego rurociągu, można poczekać na kolejne zaplanowane wykonanie lub uruchomić go ręcznie. Inne rurociągi nie zostały naruszone. Konfluencja Nie wysłano niektórych przypomnień o wydarzeniach kalendarza, które miały miejsce między 01: 00 a około 03: 45 UTC. Aplikacje Forge Zaplanowane detonatory zatrzymały się o 01: 00 UTC i wznowiły się od około 04: 00 UTC; nieodebrane inwokacje nie zostały powtórzone. Cele Początek miesiąca przypomnienia e-mail do aktualizacji celów może być opóźniony. Zarządzanie usługami Jira i Jira Przychodzące maile pozostawały w skrzynkach pocztowych i były przetwarzane automatycznie po odzyskaniu. Zaplanowane powiadomienia, takie jak subskrypcje filtrów, zostały opóźnione. W niektórych projektach usługowych zasady automatyzacji i powiadomienia uruchamiane przez SLA lub czas w statusie były opóźnione. Dane SLA pozostały nienaruszone. Wsparcie atlassian Do 07: 25 UTC problemy z naszymi narzędziami wsparcia mogły spowolnić niektóre z naszych reakcji. Na podstawie dotychczasowego śledztwa nie zidentyfikowaliśmy żadnej utraty przedmiotów, stron, repozytoriów czy przychodzących maili. * * ROOT CAUSE * Nasza wspólna platforma planowania miejsc pracy działa na dużą skalę w normalnych warunkach. Jeden z konsumentów platformy zaplanował nienormalnie dużą liczbę zadań, które mają być wykonywane w tym samym czasie 1 października o godzinie 01: 00 UTC. Ten gwałtowny wzrost wielkości przekroczył nasze granice architektoniczne i skalujące, tworząc zaległości w przetwarzaniu usług zależnych. Konstrukcja ręcznie zwiększona pojemność do obsługi nieprawidłowego obciążenia, co umożliwia obsługę do przetwarzania zaległości i powrót do normalnej pracy. # # # DZIAŁANIA REMERALNE PLAN & NEXT STEPS Wiemy, że opóźnienie i brak pracy wpływa na wydajność. Priorytetem tych działań jest zmniejszenie prawdopodobieństwa i wpływu podobnych incydentów: - * * Wzmocnienie izolacji obciążenia pracą: * * Wdrożenie targów harmonogramowych tak, aby wzrost objętości z jednego źródła nie głodować lub opóźniać zadania w innych produktach. - * * Wzmocnienie kontroli skoku: * * Dodaj możliwości operacyjne, aby szybko przyspieszyć lub wstrzymać zaplanowane ładunki z konkretnych źródeł podczas niespodziewanych skoków ruchu. - * * Poprawa skalowania systemu i odzyskiwania: * * Zwiększyć wydajność platformy i zoptymalizować procesy skalowania do obsługi ekstremalnych skoków popytu i szybciej odzyskać. Przepraszamy klientów, których usługi wpłynęły podczas tego incydentu. Dzięki. Atlassian

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 24 września 2026 13:54 UTCinvestigating

   Nadal badamy problem wpływający na tworzenie problemów Jiry, przeglądanie i ładowanie planszy. Nasze zespoły nadal pracują nad określeniem rozwiązania. Dostarczymy kolejną aktualizację w ciągu 1 godziny, lub wcześniej, jeśli nastąpi postęp materialny.

2. 24 września 2026 14:58 UTCmonitoring

   Zakłócenia zostały wprowadzone i widzimy pozytywne oznaki poprawy w całym Jirze. Problemy z przeglądaniem pozycji roboczych, tablic załadowczych i tworzenia biletów ustępują. Kontynuujemy monitorowanie zdrowia systemu w celu zapewnienia pełnej stabilności i podzielimy się naszą kolejną aktualizacją w ciągu 60 minut.

3. 24 września 2026 15:53 UTCresolved

   W dniu 24 września 2026 r. Problem został teraz rozwiązany, a usługa działa normalnie dla wszystkich klientów dotkniętych.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 24 września 2026 08:52 UTCmonitoring

   Śledziliśmy problem wpływający na Jirę, w którym użytkownicy mogli napotkać błędy lub pogorszyć wydajność dostępu do Jira i problemy z oglądaniem. Zakłócenia zostały wprowadzone i widzimy pozytywne oznaki powrotu do zdrowia. Nasze zespoły nadal monitorują sytuację i spodziewamy się potwierdzenia rezolucji w ciągu najbliższych 60 minut.

2. 24 września 2026 10:34 UTCmonitoring

   Nadal ściśle monitorujemy sytuację, aby zapewnić pełną stabilność w całym regionie Jira. Oznaki zdrowienia pozostają stałe. Nasza następna aktualizacja zostanie udostępniona za 60 minut, albo wcześniej.

3. 24 września 2026 11:46 UTCresolved

   24 września 2026 r., między 07: 28 a 08: 08 UTC, niektórzy użytkownicy programu Jira mogli doświadczyć błędów lub pogorszyć wydajność podczas dostępu do programu Jira i przeglądania problemów. Problem został już rozwiązany i usługa działa normalnie dla wszystkich klientów.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 11 września 2026 07:46 UTCinvestigating

   Prowadzimy śledztwo w sprawie problemów dotyczących Jira Software i Jira Service Management. Dotknięci użytkownicy mogą doświadczać błędów lub opóźnień podczas wczytywania wyświetleń i tablic przeglądania. Pracujemy nad zidentyfikowaniem przyczyny i dostarczymy aktualizację w miarę dostępności większej ilości informacji.

2. 11 września 2026 08:06 UTCmonitoring

   Wprowadzono środki łagodzące, a my obserwujemy ożywienie w całym Jira Software i Jira Service Management wydania widoki i tablice. Nasze zespoły inżynieryjne ściśle monitorują środowisko w celu zapewnienia trwałej stabilności. Dostarczymy kolejną aktualizację po potwierdzeniu pełnej rezolucji lub w ciągu 60 minut.

3. 11 września 2026 08:37 UTCresolved

   W dniu 11 września 2026 r., między 07: 02 UTC a 07: 56 UTC, niektórzy użytkownicy Jira Software i Jira Service Management mogli doświadczyć pogorszonych wyników i błędów przy dostępie do pozycji i tablic roboczych. Sprawa została rozwiązana i wszystkie usługi funkcjonują normalnie.

4. 21 września 2026 22:36 UTCpostmortem

   Podsumowanie W dniach 11 września 2026 r., między 07: 02 a 07: 56 UTC, klienci atklasiści głównie z regionu UE oraz niektórzy z regionu APAC wykorzystujący produkty Jira i Jira Service Management nie byli w stanie konsekwentnie przeglądać elementów roboczych lub tablic dostępu. Zdarzenie zostało wywołane przez niekompatybilną z tyłu wewnętrzną konfigurację w platformie danych wykresu. Incydent został wykryty w ciągu 3 minut przez nasz zautomatyzowany system monitorowania i złagodzony przez przesunięcie stabilnego rozmieszczenia do wszystkich regionów. Całkowity czas do rozwiązania wynosił około 54 minut. IMPACT Ogólny wpływ wystąpił między 11 września, 2026, 07: 02 UTC a 11 września, 2026, 07: 56 UTC na dwa produkty. W tym okresie niektórzy klienci w regionie UE korzystający z Jira i Jira Service Management doświadczyli przerywanych awarii lub pogorszonych wyników. Zauważyliśmy, że awaria konfiguracji uniemożliwiła skalowanie krytycznych usług w zakresie zależności, co doprowadziło do przestoju dla dotkniętych użytkowników. Użytkownicy Jira i Jira Service Management doświadczyli błędów w czasie i nieudanego lub opóźnionego obciążenia strony podczas próby uzyskania dostępu do widoku pozycji roboczej, nawigatora wydania i widoku planszy. * * ROOT CAUSE * Incydent został spowodowany wprowadzeniem zmiany do usługi sklepu graficznego, która służy linkom do podmiotów trzecich, takich jak wnioski o ciągnięcie. Zmiana spowodowała awarię kontroli startowych, zapobiegając przyłączaniu się nowych węzłów do klastra. Podczas ruchu szczytowego usługa nie mogła być wystarczająco skalowana, powodując, że żądania od Jira i Jira Service Management do usługi sklepu graficznego nie powiodły się. # # # DZIAŁANIA REMERALNE PLAN & NEXT STEPS Wiemy, że przestoje wpływają na wydajność. Naszym priorytetem są następujące działania usprawniające, aby uniknąć powtarzania tego typu incydentów: - Wdrożenie konfiguracji opartej na kodzie: Przenosimy pliki definiujące konfigurację do części podstawowej kodebazy, aby zapewnić ich modyfikację i synchronizację z logiką aplikacji. - Gratiful Degradation in Jira: Wdrażamy zmiany w poglądach Jira dotkniętych segregacją podstawowych zapytań z niekrytycznych zapytań zależności, pozwalając stronie zachować funkcjonalność, nawet jeśli usługi niższego szczebla nie. - Optymalizacja rurociągu wdrożeniowego: rurociągi wdrożeniowe są zoptymalizowane, aby umożliwić przyspieszone, równoległe aktualizacje podczas operacyjnych scenariuszy reagowania. Przepraszamy klientów, których usługi zostały dotknięte w trakcie tego incydentu; podejmujemy natychmiastowe kroki w celu poprawy wydajności i dostępności platformy. Dzięki. Obsługa klienta

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 3 września 2026 15:57 UTCinvestigating

   Prowadzimy aktywne śledztwo w sprawie zakłóceń w obsłudze klientów JIRA w USA Wschodnim. Będziemy dzielić się aktualizacjami tutaj, jak więcej informacji jest dostępna.

2. 3 września 2026 16:35 UTCmonitoring

   Nasze zespoły podjęły kroki łagodzące w celu zmniejszenia wpływu i poprawy sytuacji wśród poszkodowanych klientów rozpoczęły się o 16: 15 UTC. W dalszym ciągu badamy główną przyczynę problemu i udostępnimy tu dodatkowe aktualizacje, ponieważ więcej informacji jest dostępnych.

3. 3 września 2026 17:02 UTCresolved

   W dniu 3 września 2026 r. Problem został teraz rozwiązany, a usługa działa normalnie dla wszystkich klientów dotkniętych.

4. 10 września 2026 18:15 UTCpostmortem

   Podsumowanie W dniu 3 września 2026 r., między 14: 52 a 17: 02 UTC, klienci atklasiści korzystający z Jira i Jira Service Management w regionie US- East doświadczyli przerywanych błędów i zdegradowanego dostępu do podstawowych doświadczeń Jira, w tym Rovo, problemów z oglądaniem, desek, nawigacji, doświadczeń wspomaganych poszukiwaniami, działań związanych z pracą. Wydarzenie zostało wywołane przez progresywną zmianę w systemie autoryzacji Atlassiana. Zmiana zwiększyła ruch pamięci podręcznej i spowodowała nasycenie w warstwie podręcznej używanej do kontroli autoryzacji, co doprowadziło do przerw czasowych i błędów serwisowych dla niektórych klientów w regionie. Incydent został wykryty przez monitoring w ciągu około 12 minut. Zminimalizowaliśmy poprzez wdrożenie usługi bufora i wyłączenie flag funkcji związanych z nową ścieżką bufora. Całkowity czas do rozwiązania wynosił 2 godziny i 10 minut. IMPACT Ogólny wpływ nastąpił 3 września 2026 r. między 14: 52 a 17: 02 UTC. W tym okresie niektórzy klienci w regionie US- East korzystający z Jira i Jira Service Management doświadczyli przerywanych awarii lub pogorszył wydajność podczas dostępu do doświadczeń, które zależą od kontroli autoryzacji. Obejmowały one widok problemu, Rovo, widok planszy, nawigację, doświadczenia wspomagane poszukiwaniami, API i działania związane z przepływem pracy. * * ROOT CAUSE * Kwestia ta została spowodowana postępującym wprowadzaniem nowej ścieżki pamięci podręcznej w usłudze autoryzacji Atlassiana. Zmiana miała na celu poprawę skalowalności dla klientów z dużymi zbiorami danych autoryzacji poprzez zmianę sposobu buforowania niektórych informacji autoryzacyjnych. Podczas uruchamiania, zarówno istniejące jak i nowe ścieżki pamięci podręcznej były aktywne do kontroli spójności, co zwiększyło liczbę wpisów podręcznych i operacji podręcznych. W regionie US- East, gdzie natężenie ruchu było najwyższe, to dodatkowe nasycone obciążenia części wspólnej warstwy pamięci podręcznej. W miarę upływu czasu od żądania cache, usługa autoryzacji składała więcej wniosków zwrotnych do systemów wyższego szczebla, zwiększając obciążenie i powodując przerwy w obwodach i przerw czasowych. Uzależnione doświadczenia Jiry, które wymagają kontroli autoryzacji, następnie zwrócone błędy przerywane lub nie udało się załadować dla dotkniętych użytkowników. Wstępny monitoring nie ujawnił ryzyka wystarczająco wcześnie, ponieważ regiony o niskim natężeniu ruchu nie wykazywały tego samego poziomu degradacji, a niektóre alarmy nie były analizowane ani kierowane w sposób, który uwypuklił regionalne nasycenie pamięci podręcznej przed wzrostem wpływu na klienta. # # # DZIAŁANIA REMERALNE PLAN & NEXT STEPS Wiemy, że przestoje wpływają na wydajność klientów i przepraszamy klientów, którzy ucierpieli podczas tego incydentu. Traktujemy priorytetowo następujące działania usprawniające, aby zmniejszyć prawdopodobieństwo i wpływ podobnych incydentów: - * * Wzmocnienie zabezpieczeń wdrożeniowych: * * Poprawa praktyk wprowadzania w przypadku zmian w pamięci podręcznej i autoryzacji wysokiego ryzyka poprzez wykorzystanie mniejszych, świadomych regionów przyrostów wprowadzania i walidacji zachowania w regionach o wysokim natężeniu ruchu przed szerszą enablement. - * * Wdrożenie pełnej gracji degradacji: * * Oceniaj opcje graceful- degradation dla kontroli autoryzacji, więc doświadczenia zależne mogą kontynuować pracę, jeśli zależność cache jest niedostępna. - * * Wzmocnienie regionalnej telemetrii i monitorowania przepustowości: * * Wzmocnienie pojemności pamięci podręcznej i monitorowania stanu zdrowia, w tym regionalnych czujników procesora pamięci podręcznej, ciśnienia pamięci, hit rate, szybkość eksmisji, czas i zachowanie połączenia. - * * Badanie obciążenia w skali produkcji: * * Przegląd projektu pamięci podręcznej i planowania pojemności dla danych autoryzacyjnych tak zmiany, że zwiększenie kluczowych operacji cardinality lub cache są ładowane testowane na reprezentatywnej produkcji-skali ruchu przed rozpoczęciem. - * * Wytrzymałość klienta: * * Przegląd czasu klienta cache i ponownie połączyć zachowanie w celu zmniejszenia ryzyka burz połączeń, gdy węzły cache stają się wolne lub nasycone. Będziemy nadal zatwierdzać te działania poprzez proces przeglądu zdarzeń i śledzić je do zakończenia z odpowiedzialnymi zespołami inżynieryjnymi. Dzięki. Obsługa klienta

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 1 września 2026 17:09 UTCinvestigating

   Aktywnie badamy raporty o degradacji wydajności wpływającej na funkcjonalność form. Będziemy dzielić się aktualizacjami tutaj, jak więcej informacji jest dostępna.

2. 1 września 2026 18:27 UTCidentified

   Zidentyfikowaliśmy prawdopodobną przyczynę problemu, a nasze zespoły pilnie pracują nad łagodzeniem skutków. Dotknięci użytkownicy mogą doświadczać form niedziałających zgodnie z oczekiwaniami. Będziemy nadal udostępniać dodatkowe aktualizacje tutaj, ponieważ więcej informacji jest dostępnych.

3. 1 września 2026 20:33 UTCidentified

   Nasze zespoły nadal pracują nad łagodzeniem skutków. Będziemy nadal udostępniać dodatkowe aktualizacje tutaj, ponieważ więcej informacji jest dostępnych.

4. 1 września 2026 21:24 UTCmonitoring

   Degradacja wydajności JIRA została rozwiązana, a usługi działają obecnie normalnie dla wszystkich klientów, których to dotyczy. Będziemy nadal uważnie monitorować wyniki, aby potwierdzić stabilność.

5. 1 września 2026 21:35 UTCresolved

   1 września niektórzy użytkownicy JIRA mogli doświadczyć degradacji wydajności wpływającej na funkcjonalność form. Problem został teraz rozwiązany, a usługa działa normalnie dla wszystkich klientów dotkniętych.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 1 września 2026 09:12 UTCinvestigating

   Zdajemy sobie sprawę z problemu wpływającego na zmiany w Jira Work Item. Dotknięci użytkownicy mogą doświadczać błędów podczas prób przejścia. Nasze zespoły aktywnie badają przyczynę. Dostarczymy następną aktualizację w ciągu 60 minut, lub wcześniej, jeśli istnieje aktualizacja materiału.

2. 1 września 2026 10:11 UTCmonitoring

   Zidentyfikowaliśmy główną przyczynę problemu wpływającego na zmiany w Jira Work Item i zastosowaliśmy rozwiązanie. Obecnie widzimy oznaki poprawy i będziemy nadal monitorować. Dostarczymy następną aktualizację w ciągu najbliższych 1 godziny, lub wcześniej, jeśli istnieje aktualizacja materiału.

3. 1 września 2026 11:44 UTCresolved

   W dniu 1 września 2026 r., między 04: 22 UTC a 10: 59 UTC, niektórzy użytkownicy Jira mogli doświadczyć zakłóceń w obsłudze. Problem został już rozwiązany i usługa działa normalnie dla wszystkich klientów.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 31 sierpnia 2026 18:28 UTCidentified

   Wpływ

2. 1 września 2026 00:47 UTCmonitoring

   Jira Coming Email doświadczają zwiększonych niepowodzeń przy pobieraniu poczty z konta Microsoft. Ma to wpływ na tworzenie wiadomości e-mail i aktualizacje przedmiotów roboczych Jira. Użytkownicy mogą zobaczyć 500 wewnętrznych błędów serwera, gdy email pobrać próby wystąpić. Śledzimy aktualizacje z Microsoft i kontynuujemy przegląd wpływu. Aktualizacje te są dostępne publicznie za pośrednictwem https: / / status.cloud.microsoft /

3. 1 września 2026 05:18 UTCresolved

   Teraz widzimy pełną rekonwalescencję wśród usług Atlassian, które zostały dotknięte, i ten incydent został rozwiązany. Dla tych, którzy nadal doświadczają problemów związanych z tym incydentem, zachęcamy do sprawdzenia https: / / status.cloud.microsoft / ponieważ nadal dostarczają one dalszych informacji na temat dodatkowych usług.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 27 sierpnia 2026 04:22 UTCinvestigating

   Nasze zespoły stwierdziły, że problem ten wpływa również na zarządzanie usługami Jira. Będziemy aktualizować jak najszybciej.

2. 27 sierpnia 2026 04:25 UTCinvestigating

   Badamy problem dostępu do produktów, które wpływają na Confluence, Jira Cloud i Jira Serivce Management klientów. Nasz zespół pilnie bada tę kwestię i przedstawimy dalsze szczegóły w ciągu godziny lub wcześniej, jeśli informacje są dostępne.

3. 27 sierpnia 2026 04:33 UTCidentified

   Nasze zespoły zidentyfikowały możliwe rozwiązanie problemów wpływających na Jira Cloud, Jira Service Management i Confluence. Jest to obecnie realizowane w regionach dotkniętych skutkami i w ciągu godziny będziemy aktualizować lub wcześniej, jeśli dostępne są dalsze informacje.

4. 27 sierpnia 2026 04:51 UTCmonitoring

   Kwestie związane z załadowaniem Jira Cloud, Jira Service Management and Confluence są obecnie w fazie zdrowienia. Będziemy nadal uważnie monitorować, aby potwierdzić stabilność i dostarczyć aktualizację w ciągu jednej godziny, lub szybciej, jak więcej informacji staje się dostępne.

5. 27 sierpnia 2026 05:16 UTCresolved

   W dniu 27 sierpnia 2026 r. Problem został teraz rozwiązany, a usługa działa normalnie dla wszystkich klientów dotkniętych. Publiczna sekcja zwłok tego incydentu zostanie udostępniona na tej stronie, kiedy nasze pełne śledztwo w sprawie tego incydentu zostanie zakończone.

6. 7 września 2026 02:53 UTCpostmortem

   * * STRESZCZENIE W dniu 27 sierpnia 2026 r., w dniach 03: 51-04: 35 UTC, klienci Atlassian w regionach Europy Zachodniej i Południowo-Wschodniej APAC nie byli w stanie dotrzeć do produktów Atlassian Cloud, w tym Atlassian Analytics, Compass, Confluence, Focus, Guard, Jira, JPD, JSM, Opsgenie, Rovo Search i Talent. Zdarzenie zostało wywołane wadliwą zmianą kodu na warstwę routingu jednej z naszych flot proxy. Doprowadziło to do tego, że błędy HTTP 404 są podawane do wszystkich klientów ruchu przez te floty proxy w Europie Zachodniej i południowo-wschodniej APAC regionach. Incydent został wykryty w ciągu 1 minuty przez nasze zautomatyzowane systemy monitorowania i złagodzony przez powrót do poprzedniego wydania konfiguracji, które stawia flotę proxy w znanym dobrym stanie. Po odzyskaniu floty proxy, niektórzy klienci Jira i Confluence (niezależnie od lokalizacji) otrzymali błędy HTTP 503 między 04: 33 a 04: 53 UTC jako flot serwerów dostosowane do napływu ruchu. * * IMPACT * * Ogólny wpływ podzielono na dwa odrębne okresy: - Po pierwsze, 27 sierpnia 2026 r., między 03: 51 a 04: 35 UTC na Atlassian Analytics, Compass, Confluence, Focus, Guard, Jira, JPD, JSM, Opsgenie, Rovo Search i Talent. Incydent spowodował zakłócenia w ruchu usługowym klientów z regionów Europy Zachodniej i Południowo-Wschodniej APAC, a błędy HTTP 404 zostały zwrócone. Nie miało to wpływu na ruch API klientów, niezależnie od miejsca pochodzenia. - Po drugie, w dniu 27 sierpnia 2026 r., między 04: 33 a 04: 53 UTC, niektórzy klienci Jira i Confluence niezależnie od lokalizacji otrzymali błędy HTTP 503 po rozwiązaniu błędów HTTP 404: ~ 32% wniosków w ap- southeas- 2, ~ 4% wniosków w eu- west-1, ~ 2,5% wniosków w us- west- 2 i ap- southeas- -1 oraz < 1% wniosków we wszystkich pozostałych regionach świata. * * ROOT CAUSE * * Wydarzenie zostało wywołane przez zmianę kodu w jednej z naszych flot proxy. Wystąpił jednak błąd w zastosowanym kodzie, który nie został wykryty w drodze badań ręcznych i automatycznych. Doprowadziło to do błędnej konfiguracji funkcji lookup najemcy w poziomie proxy, co doprowadziło do nieposiadania poprawnej ścieżki sieciowej, co doprowadziło do błędów HTTP 404 dla wszystkich klientów za pośrednictwem tych proxy flot w Europie Zachodniej i południowo-wschodniej APAC regionach. Po odzyskaniu efektu proxy, drugi okres oddziaływania został spowodowany przez niektórych klientów Jira i Confluence. Ze względu na zmniejszenie ruchu obsługiwanego przez flotę proxy do Jira i Confluence, poziomy usług Jira i Confluence automatycznie zwiększyły się w liczbie serwerów obsługujących ruch klientów. Po przywróceniu funkcjonalności floty pośredniczącej, napływ ruchu przytłoczył poziom usług Jira, który zwrócił podwyższony wskaźnik HTTP 503s aż automatycznie zmniejszył się ponownie. * * PLAN DZIAŁAŃ REMERALNYCH I NASTĘPNE STAPY * * Wiemy, że przestoje wpływają na wydajność. Chociaż mamy wiele procesów testowych i prewencyjnych, ten szczególny problem nie został zidentyfikowany, ponieważ zmiana była związana z bardzo specyficznym rodzajem przypadku krawędzi, który nie został odebrany przez nasze automatyczne apartamenty ciągłego wdrażania i skrypty ręczne testów. Naszym priorytetem są następujące działania usprawniające, aby uniknąć powtarzania tego typu incydentów: - * * Dodanie dalszych zabezpieczeń wdrożeniowych: * * Rurociąg wdrożeniowy do konfiguracji danego wskaźnika proxy wykorzystywał dotychczasowy system i nie miał odpowiednich wolnych regionalnych funkcji rozruchu skonfigurowanych prawidłowo. Dodaliśmy już odpowiednie zabezpieczenia i przenosimy je do standardowego rurociągu wdrożeniowego naszej firmy, który obejmuje wszystkie nasze systemy kontroli bezpieczeństwa włączone domyślnie. Kontrolujemy również wszystkie usługi sieciowe w celu potwierdzenia, że wszystkie te usługi znajdują się w nowej standardowej usłudze rozmieszczania rurociągów. - * * Wzmocnienie polityki w zakresie skalowania floty usługowej: * * Automatyczna konfiguracja skalowania dla naszych flot serwisowych Jira i Confluence została skonfigurowana tak, aby skalować zbyt agresywnie. Dokładnie dokonujemy przeglądu i aktualizacji wszystkich skomplikowanych zasad automatycznej skalowania Jira i Confluence, aby upewnić się, że nie nastąpi to ponownie. Przepraszamy klientów, których usługi zostały dotknięte w trakcie tego incydentu; podejmujemy natychmiastowe kroki w celu poprawy wydajności i dostępności platformy. Dzięki. Obsługa klienta

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 25 sierpnia 2026 08:42 UTCinvestigating

   Aktywnie badamy raporty o degradacji wydajności, co prowadzi do zwiększenia opóźnień w powiadamianiach e-mail, mobilnych i luźnych dla Jiry, JSM i Confluence. Nasze zespoły badają tę sprawę i więcej informacji zostanie udostępnionych w ciągu najbliższych 1 godziny.

2. 25 sierpnia 2026 09:44 UTCinvestigating

   Nasze zespoły zidentyfikowały dotknięte skutkami regiony i aktywnie pracują nad złagodzeniem problemu. Dostarczymy dalsze aktualizacje w ciągu godziny lub wcześniej, jeśli będziemy mieli znaczący postęp do podzielenia.

3. 25 sierpnia 2026 10:49 UTCinvestigating

   Nasze zespoły podjęły niewiele działań naprawczych w celu złagodzenia tej kwestii w jednym z dotkniętych regionów i obserwują pewne ulepszenia. Kontynuujemy monitorowanie sytuacji i podejmiemy niezbędne działania, aż do całkowitego odzyskania tego incydentu. Dostarczymy dalsze aktualizacje w ciągu najbliższych dwóch godzin lub wcześniej, jeśli będziemy mieli znaczący postęp do podzielenia.

4. 25 sierpnia 2026 13:01 UTCmonitoring

   Nasze zespoły nadal łagodzą tę kwestię i obserwują pewne ulepszenia. Kontynuujemy monitorowanie sytuacji i podejmiemy niezbędne działania, aż do całkowitego odzyskania tego incydentu. Dostarczymy dalsze aktualizacje w ciągu najbliższych dwóch godzin lub wcześniej, jeśli będziemy mieli znaczący postęp do podzielenia.

5. 25 sierpnia 2026 14:33 UTCresolved

   W dniu 25 sierpnia 2026 r. niektórzy użytkownicy mogli doświadczyć zwiększonej latencji w powiadomieniach e-mail, mobilnych i nieaktywnych. Problem został teraz rozwiązany, a usługa działa normalnie dla wszystkich klientów.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 24 sierpnia 2026 19:22 UTCinvestigating

   Aktywnie badamy raporty o degradacji wydajności, co prowadzi do zwiększonego opóźnienia w zakresie powiadomień e-mail, mobilnych i Slack dla JIRA, JSM i Confluence. Będziemy dzielić się aktualizacjami tutaj, jak więcej informacji jest dostępna.

2. 24 sierpnia 2026 20:25 UTCinvestigating

   Nasze zespoły zidentyfikowały trzy dotknięte skutkami regiony i kontynuują badanie zwiększonego opóźnienia w zakresie e-maili, telefonów komórkowych i powiadomień Slack dla JIRA, JSM i Confluence.

3. 24 sierpnia 2026 21:30 UTCidentified

   Zidentyfikowaliśmy prawdopodobną przyczynę problemu, a nasze zespoły pilnie pracują nad łagodzeniem skutków. Dotknięci użytkownicy mogą doświadczyć zwiększonej latencji w powiadomieniach e-mail, mobilnych i Slack dla JIRA, JSM i Confluence. Będziemy nadal udostępniać dodatkowe aktualizacje tutaj, ponieważ więcej informacji jest dostępnych.

4. 24 sierpnia 2026 23:15 UTCresolved

   W dniu 24 sierpnia 2026 r. niektórzy użytkownicy JIRA, JSM i Confluence mogli doświadczyć degradacji wydajności, co mogło doprowadzić do zwiększenia opóźnienia w powiadomieniach e-mail, mobilnych i Slack. Kwestia ta została rozwiązana w przypadku nowo utworzonych powiadomień, a usługa działa normalnie. Mogą istnieć starsze powiadomienia, które są obecnie przetwarzane i oczekujemy, że zostaną one ukończone w ciągu najbliższych kilku godzin.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 7 sierpnia 2026 11:30 UTCinvestigating

   Badamy sprawy wpływające na twoje usługi. Aktywnie pracujemy nad określeniem przyczyny i rozwiązaniem problemu. Dostarczymy dalsze aktualizacje w ciągu godziny.

2. 7 sierpnia 2026 12:22 UTCmonitoring

   Some customers experienced issues accessing affected services in the Central European region. We have been able to apply the fix to mitigate the issues and we are seeing recovery. We continue to monitor the situation and should be fully recovered soon. We should be able to provide more updates in the next one hour or earlier.

3. 7 sierpnia 2026 12:52 UTCresolved

   On August 7th - 2026, between 10:27 UTC to 11:49 UTC, some users in the Central European region may have experienced service access issues. The issue has now been resolved and the service is operating normally for all the customers.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 7 sierpnia 2026 01:24 UTCinvestigating

   We are actively investigating reports of performance degradation affecting JIRA. Affected users may experience errors viewing issues and boards. We will share updates here as more information is available.

2. 7 sierpnia 2026 01:33 UTCinvestigating

   We are actively investigating reports of performance degradation affecting JIRA and JSM. Affected users may experience errors viewing issues and boards. We will share updates here as more information is available.

3. 7 sierpnia 2026 01:39 UTCmonitoring

   The performance degradation of JIRA has been resolved, and services are now operating normally for all affected customers. We'll continue to monitor performance closely to confirm stability.

4. 7 sierpnia 2026 01:46 UTCresolved

   On August 7, 2026, JIRA, JWM, and JSM users may have experienced performance degradation when viewing issues and boards. The issue has now been resolved, and the service is operating normally for all affected customers.

1. 20 lipca 2026 20:18 UTCinvestigating

   Aktywnie badamy raporty o degradacji wydajności wpływającej na zasady Automatyzacji dla Jira i Jira Service Management. Będziemy dzielić się aktualizacjami tutaj, jak więcej informacji jest dostępna.

2. 20 lipca 2026 21:27 UTCinvestigating

   Nasze zespoły nadal badają opóźnienia w automatyzacji Jira i Jira Service Management dla niektórych klientów. Widzimy oznaki poprawy, ale dotknięci mogą nadal wystąpić opóźnienia. Będziemy dzielić się aktualizacjami tutaj, jak więcej informacji jest dostępna.

3. 21 lipca 2026 04:53 UTCidentified

   Zespół zidentyfikował przyczynę i po początkowych testach, wprowadza zmiany skalowania, aby zapobiec tym opóźnieniom w wykonaniu przepisów. Będziemy monitorować wydajność w ciągu najbliższych 24 godzin i dostarczyć aktualizację w tym czasie lub wcześniej, jeśli możemy potwierdzić poprawę jest na miejscu.

4. 22 lipca 2026 00:56 UTCresolved

   Nasz zespół był w stanie potwierdzić, że wszystkie egzekucje są wykonywane normalnie i ten problem został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 20 lipca 2026 16:03 UTCinvestigating

   Aktywnie badamy raporty o degradacji wydajności wpływającej na zasady Automatyzacji dla Jira i Jira Service Management. Będziemy dzielić się aktualizacjami tutaj, jak więcej informacji jest dostępna.

2. 20 lipca 2026 16:58 UTCidentified

   Zidentyfikowaliśmy prawdopodobną przyczynę problemu, a nasze zespoły pilnie pracują nad łagodzeniem skutków. Obecnie widzimy oznaki poprawy, jednak użytkownicy dotknięci mogą doświadczyć opóźnień w Jira i Jira Zarządzanie usługi Automatyzacja zasady. Będziemy nadal udostępniać dodatkowe aktualizacje tutaj, jak więcej informacji jest dostępna.

3. 20 lipca 2026 17:23 UTCresolved

   W dniu 20 lipca 2026 r. niektórzy użytkownicy Jira i Jira Service Management mogli doświadczyć degradacji wydajności wykonywania przepisów automatyki. Problem został teraz rozwiązany, a usługa działa normalnie dla wszystkich klientów dotkniętych.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 6 lipca 2026 16:11 UTCinvestigating

   Aktywnie badamy raporty o degradacji wydajności wpływającej na Automatyzację JIRA. Będziemy dzielić się aktualizacjami tutaj, jak więcej informacji jest dostępna.

2. 6 lipca 2026 17:12 UTCinvestigating

   W dalszym ciągu badamy degradację wydajności wpływającą na automatyzację JIRA w regionach Europy. Będziemy dzielić się aktualizacjami tutaj, jak więcej informacji staje się dostępna.

3. 6 lipca 2026 17:57 UTCidentified

   Zidentyfikowaliśmy prawdopodobną przyczynę problemu, a nasze zespoły pilnie pracują nad łagodzeniem skutków. Dotknięci użytkownicy mogą doświadczyć degradacji wydajności wpływającej na Automatyzację JIRA w regionach Europy. Będziemy nadal udostępniać dodatkowe aktualizacje tutaj, ponieważ więcej informacji jest dostępnych.

4. 6 lipca 2026 18:41 UTCmonitoring

   Degradacja wydajności systemu Automation for JIRA w regionach Europy została rozwiązana, a usługi funkcjonują obecnie normalnie dla wszystkich zainteresowanych klientów. Będziemy nadal uważnie monitorować wyniki, aby potwierdzić stabilność.

5. 6 lipca 2026 18:52 UTCresolved

   W dniu 6 lipca 2026 r. niektórzy użytkownicy w regionach Europy mogli doświadczyć degradacji wydajności przy pomocy Automation for JIRA. Problem został teraz rozwiązany, a usługa działa normalnie dla wszystkich klientów dotkniętych. Jeśli uważasz, że problem nadal trwa, prosimy o kontakt z naszym zespołem wsparcia w celu dalszej pomocy i rozwiązywania problemów.

6. 27 lipca 2026 06:57 UTCpostmortem

   Podsumowanie W dniu 6 lipca 2026 r., między 06: 51 a 20: 17 UTC, klienci atklasiści korzystający z produktów w chmurze w regionach europejskich (UE) doświadczyli zakłóceń w obsłudze mających wpływ na wykonanie zasad automatyzacji, wyszukiwanie użytkowników, wybieranie użytkowników oraz powiązane przepływy pracy. Incydent rozpoczął się, gdy podstawowa usługa tożsamości doświadczyła wysycenia bazy danych w regionach UE, zwiększając opóźnienie i poziom błędów. Podczas gdy respondenci pracowali nad przywróceniem zdolności produkcyjnej, zastosowano awaryjne środki łagodzące, które blokowały zasady automatyzacji dostępu do punktu końcowego tożsamości. Równolegle, podwyższone opóźnienie tożsamości przyczyniło się do awarii kaskadowej w dalszej usługi wyszukiwania użytkowników, degradując wyszukiwanie użytkowników oraz doświadczenia w zakresie wyboru użytkowników w wielu produktach. Usługa została stopniowo przywrócona po dodaniu dodatkowej pojemności odczytu bazy danych, usunięciu bloku awaryjnego, a usługa wyszukiwania użytkownika została ręcznie skalowana. # # Impact Incydent dotyczył klientów w wielu produktach Atlassian w regionach UE w dniu 6 lipca 2026 r. między 06: 51 a 20: 17 UTC. - * * Degradacja usług identyfikacji bazowej: * * w regionach UE zaobserwowano podwyższone wskaźniki przerywanego dostępu. - * * Automation rule execution failed: * * Automation rules using the default user (Automation for Jira) in Jira, Jira Service Management, and Jira Product Discovery in EU regions failed with a permissions error. - * * Wyszukiwarka użytkowników i niepowodzenia użytkowników: * * wskaźniki sukcesu wyszukiwania użytkowników znacznie spadły w regionach UE, z możliwością wybierania użytkowników w dużej mierze niedostępne dla wszystkich produktów. # # Root Cause # Incydent powstał z niedawnej zmiany konfiguracji, która skróciła żywotność pamięci podręcznej dla podstawowej usługi tożsamości. W związku z tym, że w dniu pracy w UE ruch drogowy wzrósł 6 lipca 2026 r., większa część wniosków zaczęła docierać bezpośrednio do bazy danych, zamiast być obsługiwana z pamięci podręcznej. Bazy danych UE nie dysponowały wystarczającymi zdolnościami regionalnymi do absorpcji zwiększonego obciążenia, a CPU w bazie danych osiągnęło nasycenie, powodując wyższe stawki przerywanego dostępu. W ramach tego ograniczenia zastosowano blok awaryjny w celu zmniejszenia obciążenia bazy danych nasyconych usług tożsamości i priorytetowego traktowania przywrócenia podstawowej usługi tożsamości. To niechcący uniemożliwiło automatyzację zdawania ich kontroli przed wykonaniem, powodując ich niepowodzenie. Przedłużony czas trwania był głównie spowodowany wtórną falą awarii przepisów automatyki spowodowanej przez przepustowość granicy przetwarzania. Równolegle trwała degradacja spowodowała wzrost opóźnień i przerywanych awarii w odniesieniu do produktów, które zależą od tych kontroli, i przyczyniła się do awarii kaskadowej w usłudze wyszukiwania dalszych użytkowników. W związku z tym w regionach UE, do czasu odzyskania uprawnień, a także do momentu, gdy usługa wyszukiwania użytkowników została skalowana w celu przywrócenia przepustowości, doświadczenia w zakresie wyszukiwania użytkowników stały się w dużej mierze niedostępne. # # Remedial Actions Plan & Next Steps Wiemy, że braki wpływają na wydajność klientów. Atakujący traktuje priorytetowo następujące działania, aby zapobiec podobnym incydentom w przyszłości: - * * Ulepszenie zabezpieczeń na wypadek poważnych awarii: * * Mocne oprzyrządowanie operacyjne, dzięki czemu kroki łagodzące, które mogłyby wyłączyć przepływy pracy stojące przed użytkownikami wymagają dodatkowego przeglądu. - * * Wzmocnienie przepustowości infrastruktury tożsamości i bezpieczeństwo zmiany: * * Przegląd regionalnej bazy danych o wielkości i zdolności przepustowej w celu zmniejszenia ryzyka nasycenia w okresach szczytowego natężenia ruchu oraz udoskonalenie procesu oceny zmian konfiguracji, tak aby wpływ obciążenia niższego szczebla został oceniony przed rozpoczęciem produkcji. - * * Wzmocnienie odporności na uszkodzenia kaskadowe spowodowane degradacją: * * Audyt obsługi przeciwciśnienia, konfiguracja wyłączników obwodów i autoskalowanie zachowania w usługach, tak, że degradacja w górę nie powoduje szerszy wpływ produktu w poszukiwaniu użytkowników, użytkownika picker, i związanych z tym doświadczeń. - * * Mechanizmy powtórki Harden dla awarii reguły Automation: * * Zwiększenie odporności przepisów dotyczących automatyzacji w celu ograniczenia skutków związanych z zdarzeniami występującymi w zależności. Zdajemy sobie sprawę z tego, jak ważne są dla naszych klientów wiarygodne przepływy pracy produktów i przepraszamy klientów, którzy zostali dotknięci tym incydentem. Dzięki. Obsługa klienta

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 6 lipca 2026 09:23 UTCinvestigating

   Badamy sprawy wpływające na twoje usługi. Aktywnie pracujemy nad określeniem przyczyny i rozwiązaniem problemu. Dostarczymy dalsze aktualizacje w ciągu godziny.

2. 6 lipca 2026 10:04 UTCmonitoring

   Udało nam się to naprawić i widzimy powrót do zdrowia. Możliwości automatyki są odnawiane i powinny działać normalnie. Wnioski o przetwarzanie danych złożone w okresie wyłączenia nie zostały wypełnione z powodu niedostępności usług. Nadal monitorujemy sytuację i oczekujemy pełnego powrotu do zdrowia w ciągu następnej godziny. Dostarczymy dodatkowe aktualizacje w ciągu następnej godziny lub wcześniej.

3. 6 lipca 2026 11:46 UTCinvestigating

   Nadal mamy do czynienia z pewnymi problemami z wyszukiwaniem użytkowników, wybieraniem użytkowników i aktywami w całym regionie UE. Kontynuujemy badanie sytuacji i dostarczymy dodatkowe aktualizacje w ciągu najbliższej godziny lub wcześniej.

4. 6 lipca 2026 12:25 UTCmonitoring

   Zastosowaliśmy rozwiązanie w celu złagodzenia tej kwestii i widzimy ożywienie. Nadal monitorujemy sytuację i wkrótce powinniśmy w pełni ją odzyskać. Powinniśmy być w stanie dostarczyć więcej aktualizacji w ciągu następnej godziny lub wcześniej.

5. 6 lipca 2026 13:04 UTCresolved

   W dniu 6 lipca 2026 r., między 06: 51 UTC a 09: 39 UTC niektórzy użytkownicy mogli doświadczyć problemów związanych z Automatyzacją, a między 08: 10 UTC a 11: 50 UTC niektórzy użytkownicy mogli doświadczać problemów związanych z wyszukiwaniem użytkowników, wybieraniem użytkowników i aktywami w regionie UE. Kwestie te zostały już rozwiązane i usługi działają normalnie dla wszystkich klientów.

6. 17 lipca 2026 16:59 UTCpostmortem

   Podsumowanie W dniu 6 lipca 2026 r., między 06: 51 a 20: 17 UTC, klienci atklasiści korzystający z produktów w chmurze w regionach europejskich (UE) doświadczyli zakłóceń w obsłudze mających wpływ na wykonanie zasad automatyzacji, wyszukiwanie użytkowników, wybieranie użytkowników oraz powiązane przepływy pracy. Incydent rozpoczął się, gdy podstawowa usługa tożsamości doświadczyła wysycenia bazy danych w regionach UE, zwiększając opóźnienie i poziom błędów. Podczas gdy respondenci pracowali nad przywróceniem zdolności produkcyjnej, zastosowano awaryjne środki łagodzące, które blokowały zasady automatyzacji dostępu do punktu końcowego tożsamości. Równolegle, podwyższone opóźnienie tożsamości przyczyniło się do awarii kaskadowej w dalszej usługi wyszukiwania użytkowników, degradując wyszukiwanie użytkowników oraz doświadczenia w zakresie wyboru użytkowników w wielu produktach. Usługa została stopniowo przywrócona po dodaniu dodatkowej pojemności odczytu bazy danych, usunięciu bloku awaryjnego, a usługa wyszukiwania użytkownika została ręcznie skalowana. # # Impact Incydent dotyczył klientów w wielu produktach Atlassian w regionach UE w dniu 6 lipca 2026 r. między 06: 51 a 20: 17 UTC. - * * Degradacja usług identyfikacji bazowej: * * w regionach UE zaobserwowano podwyższone wskaźniki przerywanego dostępu. - * * Automation rule execution failed: * * Automation rules using the default user (Automation for Jira) in Jira, Jira Service Management, and Jira Product Discovery in EU regions failed with a permissions error. - * * Wyszukiwarka użytkowników i niepowodzenia użytkowników: * * wskaźniki sukcesu wyszukiwania użytkowników znacznie spadły w regionach UE, z możliwością wybierania użytkowników w dużej mierze niedostępne dla wszystkich produktów. # # Root Cause # Incydent powstał z niedawnej zmiany konfiguracji, która skróciła żywotność pamięci podręcznej dla podstawowej usługi tożsamości. W związku z tym, że w dniu pracy w UE ruch drogowy wzrósł 6 lipca 2026 r., większa część wniosków zaczęła docierać bezpośrednio do bazy danych, zamiast być obsługiwana z pamięci podręcznej. Bazy danych UE nie dysponowały wystarczającymi zdolnościami regionalnymi do absorpcji zwiększonego obciążenia, a CPU w bazie danych osiągnęło nasycenie, powodując wyższe stawki przerywanego dostępu. W ramach tego ograniczenia zastosowano blok awaryjny w celu zmniejszenia obciążenia bazy danych nasyconych usług tożsamości i priorytetowego traktowania przywrócenia podstawowej usługi tożsamości. To niechcący uniemożliwiło automatyzację zdawania ich kontroli przed wykonaniem, powodując ich niepowodzenie. Przedłużony czas trwania był głównie spowodowany wtórną falą awarii przepisów automatyki spowodowanej przez przepustowość granicy przetwarzania. Równolegle trwała degradacja spowodowała wzrost opóźnień i przerywanych awarii w odniesieniu do produktów, które zależą od tych kontroli, i przyczyniła się do awarii kaskadowej w usłudze wyszukiwania dalszych użytkowników. W związku z tym w regionach UE, do czasu odzyskania uprawnień, a także do momentu, gdy usługa wyszukiwania użytkowników została skalowana w celu przywrócenia przepustowości, doświadczenia w zakresie wyszukiwania użytkowników stały się w dużej mierze niedostępne. # # Remedial Actions Plan & Next Steps Wiemy, że braki wpływają na wydajność klientów. Atakujący traktuje priorytetowo następujące działania, aby zapobiec podobnym incydentom w przyszłości: - * * Ulepszenie zabezpieczeń na wypadek poważnych awarii: * * Mocne oprzyrządowanie operacyjne, dzięki czemu kroki łagodzące, które mogłyby wyłączyć przepływy pracy stojące przed użytkownikami wymagają dodatkowego przeglądu. - * * Wzmocnienie przepustowości infrastruktury tożsamości i bezpieczeństwo zmiany: * * Przegląd regionalnej bazy danych o wielkości i zdolności przepustowej w celu zmniejszenia ryzyka nasycenia w okresach szczytowego natężenia ruchu oraz udoskonalenie procesu oceny zmian konfiguracji, tak aby wpływ obciążenia niższego szczebla został oceniony przed rozpoczęciem produkcji. - * * Wzmocnienie odporności na uszkodzenia kaskadowe spowodowane degradacją: * * Audyt obsługi przeciwciśnienia, konfiguracja wyłączników obwodów i autoskalowanie zachowania w usługach, tak, że degradacja w górę nie powoduje szerszy wpływ produktu w poszukiwaniu użytkowników, użytkownika picker, i związanych z tym doświadczeń. - * * Mechanizmy powtórki Harden dla awarii reguły Automation: * * Zwiększenie odporności przepisów dotyczących automatyzacji w celu ograniczenia skutków związanych z zdarzeniami występującymi w zależności. Zdajemy sobie sprawę z tego, jak ważne są dla naszych klientów wiarygodne przepływy pracy produktów i przepraszamy klientów, którzy zostali dotknięci tym incydentem. Dzięki. Obsługa klienta

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 19 czerwca 2026 22:46 UTCmonitoring

   Klienci Jira i JSM używający Microsoft OAuth do automatycznego tworzenia biletów Jira z e-mailem nie byli w stanie odczytać e-maila. Jest to teraz stałe i funkcjonalne dla wszystkich nowych przychodzących przetwarzania poczty elektronicznej. Klienci, którzy mieli wpływ w okresie incydentu, muszą ponownie upoważnić serwer pocztowy Microsoft do przywrócenia i poniżej są instrukcjami. Aby ponownie autoryzować przychodzący serwer poczty Microsoft: Zaloguj się w Jira jako admin Wybierz > System Wybierz wiadomość > Przychodząca wiadomość. Wybierz Edytuj serwer poczty przychodzącej. Wybierz ponowny autoryzację. Wprowadź swoje referencje Microsoft, aby kontynuować korzystanie z serwera poczty Microsoft.

2. 26 czerwca 2026 05:13 UTCresolved

   Nasz zespół aktywnie skontaktował się ze wszystkimi wpływowymi organizacjami dostarczającymi poniższych instrukcji, aby ponownie autoryzować swój serwer poczty Microsoft. Jeśli nadal doświadczasz tego problemu, spróbuj zakończyć ponowną autoryzację zgodnie z poniższymi zaleceniami. Jeśli nadal występują dalsze problemy, które uważają Państwo za związane z tym incydentem, prosimy o kontakt z Alaski o dalsze wsparcie.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 10 czerwca 2026 04:55 UTCinvestigating

   We are investigating reports of extended delays being experienced across tasks such as processing of Incoming Emails, Notifications relating to changes or creation of Work Items, in addition to delays in processing Scheduled Triggers from Marketplace apps. Our team is looking into this with urgency and we will provide further update within one hour as our investigation continues.

2. 10 czerwca 2026 05:39 UTCidentified

   Our team has identified the root cause for this issue and has now deployed a fix that is rolling out across impacted products. At this time we are monitoring for the recovery of these events across Jira Service Management, Jira Cloud and Ecosystem app Scheduled Triggers. We will provide further update within one hour or when we have seen a full recovery of all task processing across these products.

3. 10 czerwca 2026 06:14 UTCmonitoring

   Our team has now determined that performance has returned to expected levels for those impacted by this incident. Additional products that are now known to have been impacted by this incident are Confluence, Customer Service Management, and Jira Product Discovery. These products would have seen similar impact where email notifications or processing of events may have been delayed while this incident was underway. We are now monitoring for the full recovery of performance across all products and will update when we are confident this issue is fully resolved, or within one hour, whichever is sooner.

4. 10 czerwca 2026 06:31 UTCresolved

   We are now confident that any of the tasks that were impacted by this incident and were delayed should now be operating as expected. We apologize for any inconvenience that this issue may have caused.