Historia awarii Exalate

1. 27 sierpnia 2026 04:36 UTCinvestigating

   Atlassian ma problem z Jirą i innymi systemami - szczegóły: https: / / status.atclassian.com / Może to mieć wpływ na Twoje połączenia Exalate, jeśli podłączasz się do instancji Jira.

2. 27 sierpnia 2026 04:44 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

3. 27 sierpnia 2026 05:09 UTCmonitoring

   Atlassian wprowadził rozwiązanie problemu. Twoja synchronizacja powinna już wrócić do normy, ale proszę sięgać po wsparcie w razie jakichkolwiek problemów.

4. 27 sierpnia 2026 05:27 UTCresolved

   Wszystkie systemy Atlassian wracają do normy, a synchronizacja działa zgodnie z oczekiwaniami. W przypadku jakichkolwiek problemów z synchronizacji, proszę utworzyć bilet wsparcia i będziemy szczęśliwi, aby pomóc.

5. 8 września 2026 05:41 UTCpostmortem

   NIE DOTYCZY

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 24 lipca 2026 06:12 UTCidentified

   W następstwie niezamierzonej zmiany nazwy aplikacji, która powoduje, że użytkownik proxy jest pokazywany z pełną nazwą aplikacji zamiast po prostu "Wyżej". Jest to już zgłoszone Atlassian i czekamy na wymagane działania na ich koniec, aby odwrócić zmianę. Impact: Aktualizacje wykonane przez Exalate będą wyświetlane "Exalate Classic Connector for Jira (Two-way Sync)" jako użytkownik dokonujący zmiany.

2. 24 lipca 2026 09:15 UTCidentified

   Nadal badamy najlepsze podejście do rozwiązania tego problemu z pomocą wsparcia atklasistów.

3. 24 lipca 2026 12:39 UTCidentified

   Aktywnie współpracujemy ze wsparciem Atlassian w celu jak najszybszego określenia najlepszej rezolucji w tej sprawie.

4. 24 lipca 2026 15:47 UTCidentified

   Aktywnie współpracujemy ze wsparciem Atlassian w celu jak najszybszego określenia najlepszej rezolucji w tej sprawie. Kolejna aktualizacja nastąpi w ciągu 6 godzin lub jak tylko uzyskamy odpowiednie informacje.

5. 24 lipca 2026 16:33 UTCresolved

   Nazwa proxy została przywrócona do Exalate. Uznajemy ten incydent za rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 16 lipca 2026 11:28 UTCinvestigating

   Niektóre węzły Jira Cloud doświadczają niestabilności w ciągu ostatnich 30 minut. Problem jest ograniczony i dotyczy tylko niektórych klientów. Wkrótce dostarczymy nowe informacje.

2. 16 lipca 2026 12:03 UTCidentified

   Zastosujemy zmianę w sprawie Górnej Chmury w celu poprawy stabilności. Wpływ na węzeł będzie ograniczony do ponownego uruchomienia węzła przez kilka minut. Żałujemy niedogodności.

3. 16 lipca 2026 13:38 UTCidentified

   Ponowne uruchomienie węzłów jest w toku. Na węzłach JCloud doświadczysz krótkiego wznowienia. Będziemy was informować o postępach.

4. 16 lipca 2026 15:15 UTCidentified

   Ponowne uruchomienie jest nadal w toku i przebiega bez żadnych problemów. Będziemy aktualizować jak tylko zostanie ukończony.

5. 16 lipca 2026 15:57 UTCmonitoring

   Wszystkie węzły wracają do normalnej pracy. Nadal uważnie monitorujemy sytuację.

6. 16 lipca 2026 17:18 UTCresolved

   Po ścisłym monitorowaniu kwestię tę uznaje się za w pełni rozwiązaną. We will be posting a RCA here in right course.

7. 25 października 2026 12:22 UTCpostmortem

   * * Incydent: * * JiraCloud Nodes Experiencing Instability - July 16, 2026 * * Czas trwania: * * 12: 28 czasu środkowoeuropejskiego - 16: 57 czasu środkowoeuropejskiego\ (około 4,5 godziny\). Pełna stabilność potwierdzona o 18: 18 czasu środkowoeuropejskiego. * * Impact: * * Niektóre węzły integracyjne Jira Cloud doświadczyły niestabilności w tym oknie. Typowo ~ 10 węzłów zostały dotknięte jednocześnie. Wydanie synchronizacji na niedotkniętych węzłach nadal działa normalnie. Brak danych. * * Streszczenie: * * 16 lipca 2026 niektóre węzły integracyjne Jira Cloud na platformie Exalate Cloud doświadczyły przerywanych restartów i przerw czasowych. Przyczyną było ograniczenie zasobów jednego z serwerów hostingowych. Przypadkowa aktualizacja oprogramowania początkowo ukierunkowana dochodzenie w kierunku warstwy aplikacji, ale analiza środowiska cross-environment potwierdziła, że węzły na innej infrastrukturze nie zostały naruszone - zawężając problem do jednego serwera hostingowego. * * Timeline: * * * 12: 28 CET - Wykryta emisja, wszczęte dochodzenie * 13: 03 CET - Zastosowane środki stabilizacji, rozpoczęte ponowne uruchomienie * 16: 57 CET - Wszystkie węzły wracają do normalnej pracy * 18: 18 CET - Pełna stabilność potwierdzona * * Root Cause * * Serwer hostingowy osiągnął swój pułap zasobów dzięki skoncentrowanemu obciążeniu pracą podczas rutynowego cyklu aktualizacji oprogramowania. Powodowało to przerywane głodowanie zasobów dla węzłów działających na tym serwerze. * * Resolution: * * Obciążenie pracą było redystrybuowane w całej infrastrukturze hostingowej w celu zrównoważenia wykorzystania zasobów. Wszystkie dotknięte węzły odzyskane bez utraty danych. * * Środki zapobiegawcze: * * * Wprowadzono proaktywne progi ostrzegawcze dotyczące wykorzystania zasobów infrastruktury * Dystrybucja obciążenia roboczego na serwerach hostingowych została zbalansowana, aby zapobiec koncentracji Przepraszamy za zakłócenia. Pozostajemy zaangażowani w niezawodność platformy Exalate.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 13 lipca 2026 22:15 UTCinvestigating

   Otrzymaliśmy wiele raportów o pętli synków po aktualizacji do nowej aplikacji Jira Cloud Forge. Nasze wstępne śledztwo prowadzi nas do przekonania, że dzieje się to z powodu zmiany konta Proxy User. Aktywnie pracujemy nad określeniem przyczyny i zastosowaniem poprawki.

2. 13 lipca 2026 23:48 UTCinvestigating

   Badamy tę sprawę z naszymi inżynierami, by ustalić przyczynę.

3. 14 lipca 2026 04:58 UTCidentified

   Zidentyfikowano przyczynę, nad którą pracujemy. Proszę oczekiwać kolejnej aktualizacji w ciągu godziny.

4. 14 lipca 2026 07:05 UTCidentified

   Fix jest obecnie zatwierdzany, aby znaleźć najlepsze podejście do przodu. Dostarczymy kolejną aktualizację w ciągu godziny.

5. 14 lipca 2026 08:11 UTCidentified

   Niestety, badanie fix ujawniło nieoczekiwany problem i teraz dostrajamy fix w celu zapewnienia, że zawiera wszystkie możliwe przypadki użycia. Za godzinę będziemy mieli nowe informacje.

6. 14 lipca 2026 09:09 UTCidentified

   Nowy fix został stworzony i wstępne testy są obiecujące. Jesteśmy głęboko w QA z nowym fix i zapewni aktualizację w ciągu godziny o wyniki. Żałujemy niedogodności.

7. 14 lipca 2026 10:11 UTCidentified

   Nadal sprawdzamy naprawę i wyniki są dobre. Jesteśmy blisko finalizacji. Następna aktualizacja nastąpi w ciągu godziny.

8. 14 lipca 2026 11:39 UTCidentified

   Rozwiązanie jest gotowe i pracujemy nad podejściem wdrożeniowym, które ma minimalny wpływ na klientów. Będzie ona systematycznie przekazywana wszystkim klientom. Za godzinę dostarczymy nowe informacje o rozmieszczeniu.

9. 14 lipca 2026 12:51 UTCidentified

   Umieściliśmy fix do kilku wybranych klientów i potwierdzone wyniki dalej. Rozkład masowy jest właśnie planowany. Będziemy informować o postępach w ciągu godziny.

10. 14 lipca 2026 14:24 UTCidentified

    Nadal jesteśmy na kursie na wprowadzenie patch, a zwolnienie przechodzi teraz przez dodatkowe zatwierdzenie QA (wymagane do pełnego wdrożenia produkcji). Spodziewamy się następnej aktualizacji w ciągu godziny.

11. 14 lipca 2026 16:11 UTCidentified

    Testy i oceny jakości trwają nieco dłużej, niż się spodziewano, ale spodziewamy się rozpoczęcia rozmieszczenia w ciągu następnej godziny. Zaktualizujemy cię przed rozpoczęciem tego.

12. 14 lipca 2026 17:41 UTCmonitoring

    W trakcie wdrażania hotfix: Exalate Classic 5.35.4 - Jira Cloud (https: / / community.exalate.com / t / jira- cloud- version- 5- 35- 4 / 8215). Rozmieszczanie jest ściśle monitorowane pod kątem anomalii. Będziemy cię informować za godzinę.

13. 14 lipca 2026 18:55 UTCmonitoring

    Rozmieszczanie jest kontynuowane. Zaktualizujemy Państwa w odpowiednim czasie, jak tylko zostanie w pełni ukończony.

14. 14 lipca 2026 22:14 UTCresolved

    Rozmieszczanie zostało zakończone pomyślnie i zgłoszona kwestia pozostaje w pełni rozwiązana. Szczegółowy RCA zostanie opublikowany we właściwym czasie.

15. 28 lipca 2026 20:00 UTCpostmortem

    * * Impact: * * Some Classic Exalate for Jira Cloud connections exposed repeated, duplicated synchronisations after an infrastructure migration to Atlassian 's Forge platform. Na dotkniętych połączeń klienci widzieli: * * * Duplikaty aktywności * * - ta sama aktualizacja, komentarz, lub zmiana pola zastosowana do problemu w kółko jak synchronizacja pętli. * * * Odnowione / wskrzeszone problemy * * - sprawy, które zostały zamknięte, są ponownie otwierane, a inne status lub wartości pola są nadpisywane tam i z powrotem pomiędzy kwestiami sparowanymi. * * * Zróżnicowane tablice rozdzielcze i raporty * * napędzane przez objętość duplikatów zmian. * * * Zniszczone automacje i walidacje przepływu pracy * * - ponieważ nazwa użytkownika integracji\ (i bazowy ID\) zmieniła się, zasady Jira Automation po stronie klienta i walidatory przepływu pracy, które odnosiły się do użytkownika "Wyżej" po nazwie przestał zachowywać się jak skonfigurowany. * * * Stuck or fauld syncs * *, a w niektórych przypadkach połączenie spada, wymagając ręcznych powtórzeń lub odzyskiwania. * Zwiększony wysiłek manualny * * dla zespołów do odklejania synków i korygowania problemów. Nie dotyczy to wszystkich klientów - wpływ zależy od konfiguracji połączenia. Najbardziej narażone były lokalne połączenia i problemy, które zostały wcześniej utworzone lub zaktualizowane w ramach oryginalnej tożsamości "Wyżej", a następnie zostały dotknięte pod nową nazwą. * * Streszczenie: * * W ramach przenoszenia Classic Exalate dla Jira Cloud do platformy Atlassian Forge, nazwa pokazana dla użytkownika integracji Exalate wewnątrz Jira zmieniła\ (z "Exalate" na dłuższy wariant\). Wymień tę nazwę, aby rozpoznać jej własne aktualizacje i uniknąć ich ponownej synchronizacji. Po zmianie nazwy, aplikacja nie rozpoznaje swoich własnych napisów na dotkniętych połączeń i przetwarza je tak, jakby były nowymi zewnętrznymi zmianami - każdy zapis uruchamia inną synchronizację, produkując pętle. Ta sama zmiana tożsamości złamała również automatyzację i walidacje klientów, które odwołały się do użytkownika "Wyrównaj" po imieniu. * * Resolution: * * A patch\ (5.35.4\) that exalate 's own updates by a stable user identifier rather than the display name was applicated on affected customer environments and pusted across the Jira Cloud fleet. Synchronizacja powróciła do normy po zakończeniu rozmieszczenia. Atlassian od tego czasu odrestaurował i potwierdził nazwę użytkownika integracji jako "Wyżej", a teraz jest stabilny - naprawy automatyki, które odnoszą się do niego po nazwie. W przypadku gdy pętle tworzą duplikaty lub ponownie otwierają elementy, współpracujemy z klientami dotkniętymi problemem, aby zidentyfikować i skorygować problemy. * * Środki zapobiegawcze: * * Zapobieganie Loop- już nie zależy od zmiennej nazwy wyświetlacza; dodajemy impact- review i powiadamianie krok wokół zmian platformowych i aktualizacji aplikacji, i automatyczne wykrywanie pętli synchronizacji i nasycenia bazy danych, więc odzysk nie zależy od raportów klientów. Przepraszamy za zakłócenia i pozostajemy zaangażowani w niezawodność platformy Exalate.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 23 czerwca 2026 09:10 UTCinvestigating

   Obecnie badamy problem, próbując załadować połączenie z wywyższenia. strona aplikacji dostaje błąd. Połączenie i synchronizacja nie mają wpływu na przestoje, nadal działają, ale w tej chwili nie można zobaczyć lub zmodyfikować połączenia z wywyższenia. strona aplikacji. Za 2 godziny dostarczymy nowe informacje.

2. 23 czerwca 2026 09:26 UTCmonitoring

   Sprawa została rozwiązana. Wyrównaj deskę rozdzielczą nie jest z powrotem online i stabilne. Będziemy nadal monitorować system.

3. 23 czerwca 2026 12:47 UTCresolved

   Ten incydent został rozwiązany.

4. 7 lipca 2026 08:49 UTCpostmortem

   * * Czas trwania: * * 11: 10 CEST - 11: 26 CEST\ (około 16 minut\). Pełna stabilność potwierdzona o 14: 47 CEST. * * Impact: * * Podłączenie Exalate.app i strony deski rozdzielczej nie były dostępne w tym oknie. Nie wpłynęła na synchronizację emisji - integracje nadal przebiegały normalnie. Brak danych. * * Streszczenie: * * W dniu 23 czerwca 2026, interfejs Exalate.app stał się niedostępny po tym, jak wewnętrzny komponent uwierzytelniający nie podłączył się do swojej bazy danych. Niepowodzenie to było spowodowane przez niezgodność kredytową wprowadzoną w trakcie rozmieszczania produkcji. * * Timeline: * * * 11: 10 CEST - Wykryto wydanie, wszczęto dochodzenie * 11: 26 CEST - Poprawiono rozmieszczenie, przywrócono obsługę * 14: 47 CEST - Pełna stabilność potwierdzona * * Root Cause: * * Podczas realizacji produkcji 19 czerwca, baza danych została skonfigurowana niezależnie w dwóch systemach. Podczas późniejszej aktualizacji konfiguracji wprowadzono subtelne niedopasowanie. Niezgodność pozostała utajniona, ponieważ aplikacja utrzymywała istniejące połączenia w bazie danych. Rutynowa impreza konserwacji GKE 23 czerwca poddała recyklingowi aplikację, wymuszając nowe połączenia, które ujawniły niedopasowanie. * * Resolution: * * Baza danych została dostosowana i wniosek został ponownie uruchomiony. Usługa powróciła do pełnej pracy bez utraty danych. * * Środki zapobiegawcze: * * * Kontrole weryfikacji uwierzytelniania po wdrożeniu zostały dodane do podręcznika wdrożenia * Alertowanie o awarie połączeń w bazie aplikacji * Proces konfiguracji kredytowej jest konsolidowana w celu wyeliminowania ryzyka niedopasowania dual- system Przepraszamy za zakłócenia. Pozostajemy zaangażowani w niezawodność platformy Exalate.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 4 maja 2026 13:24 UTCinvestigating

   Mamy doniesienia o niedostępnych węzłach Exlate Cloud. Nasz zespół właśnie bada sprawę.

2. 4 maja 2026 13:42 UTCinvestigating

   Nadal badamy tę kwestię.

3. 4 maja 2026 14:50 UTCidentified

   Nasz zespół w chmurze zidentyfikował przyczynę i aktywnie ją naprawi.

4. 4 maja 2026 15:53 UTCidentified

   dotknięte węzły odzyskują się podczas gdy nasz zespół chmur nadal pracuje nad tym problemem.

5. 4 maja 2026 18:50 UTCmonitoring

   Wszystkie węzły są sprawne, nasz zespół w chmurze nadal przegląda dotknięty klaster i pracuje nad jego konserwacją.

6. 4 maja 2026 21:28 UTCresolved

   System jest pod ścisłą obserwacją i jest stabilny. Zapewnimy pośmiertny wypadek we właściwym czasie.

7. 25 października 2026 10:27 UTCpostmortem

   / Incydent: Wyrównaj zakłócenia usługi w chmurze - 4 maja 2026 r. * * Czas trwania: * * 10: 45 - 22: 10 CEST\ (około 11 godzin 25 minut, przerywany\) * * Impact: * * Kilkaset podświetlonych węzłów chmury w jednym z naszych europejskich klastrów stało się wielokrotnie nieosiągalnych w ciągu dnia roboczego. Synchronizacje na dotkniętych węzłach nie działały podczas tych okien i wznawiały się automatycznie za każdym razem, gdy usługa wracała. Inne klastry nie uległy zmianie. Brak danych nie został utracony i nie było wymagane działanie klienta. * * Streszczenie: * * W dniu 4 maja 2026 r. Jego pamięć masowa współdzieliła urządzenie fizyczne z innym obciążeniem, a przy obciążeniu powstałą konfigurację zwolnił dysk pisze wystarczająco dla naszej automatycznej kontroli zdrowia do czasu. Platforma traktowała timeout jako awarię i ponownie uruchomiła bazę danych, która była raczej zajęta niż zepsuta, odłączając za każdym razem węzły na tym klastrze. * * Timeline: * * * 10: 45 CEST - Węzły zgłoszone nieosiągalne, wszczęte dochodzenie * 15: 24 CEST - Incydent zadeklarowany i opublikowany na naszej stronie statusu * 22: 10 CEST - Replika standby przywrócona, klaster potwierdzone zdrowe * * Root Cause: * * Twierdzenie przechowywania na wspólnym urządzeniu fizycznym spowodowało przerwy w kontrolach zdrowia, które uruchomiły automatyczne ponowne uruchomienie. Odbudowa repliki w trybie czuwania wzmocniła ten sam argument, ponieważ strumieniowanie kopii bazy danych odciągnęło przepustowość dysku od instancji, która nadal obsługuje klientów. * * Resolution: * * Magazynowanie zostało przeniesione do dedykowanego urządzenia, przydzielony dodatkowy procesor, a przepustowość dysku podniesiona na podstawowym, a celowo ograniczona na replice, więc odbudowa narysowała dane bardziej delikatnie. * * Środki zapobiegawcze: * * Oddzielamy pamięć masową bazy danych od innych obciążeń roboczych w całym tym środowisku, retuning progów zdrowia - sprawdzanie tak baza danych pod dużym, ale zdrowym ładunkiem nie jest ponownie uruchomiony, paralelizując ścieżkę odzyskiwania węzłów do skrócenia renowacji, i dodając monitoring na poziomie hosta tak content alerts zanim dotrze do klientów. Przepraszamy za zakłócenia. Pozostajemy zaangażowani w niezawodność platformy Exalate.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 15 kwietnia 2026 09:03 UTCinvestigating

   Obecnie badamy kwestię, w której strona z miejscami pracy nie jest ładowana. Synchronizacja nie jest naruszona, tylko UI New Exalate nie ładuje.

2. 15 kwietnia 2026 09:04 UTCidentified

   Zidentyfikowaliśmy główną przyczynę problemu i obecnie pracujemy nad jego rozwiązaniem.

3. 15 kwietnia 2026 10:16 UTCmonitoring

   Kwestie techniczne zostały w pełni rozwiązane, a aplikacja już działa. Dokładnie monitorujemy sytuację.

4. 15 kwietnia 2026 12:16 UTCresolved

   Aplikacja działa sprawnie bez żadnych problemów i nie widzimy żadnych anomalii. W odpowiednim czasie zostanie przeprowadzona sekcja zwłok.

5. 7 lipca 2026 12:41 UTCpostmortem

   * * Incydent: * * Exalate.app Niewczytywanie miejsc pracy - 15 kwietnia 2026 * * Czas trwania: * * 11: 03 CEST - 12: 16 CEST\ (około 73 minut\). * * Uderzenie: * * Interfejs Exalate.app był niedostępny w tym oknie. Nie miało to wpływu na synchronizację emisji. Brak danych. * * Podsumowanie: * * 15 kwietnia 2026, interfejs Exalate.app stał się niedostępny po planowanej aktualizacji kredytowej infrastruktury. Drugorzędna zależność konfiguracji nie została zaktualizowana w ramach zmiany, co uniemożliwia podłączenie aplikacji do jej bazy danych. * * Timeline: * * * 11: 03 CEST - wykryta emisja, wszczęte dochodzenie * 11: 04 CEST - Zidentyfikowana przyczyna korzenia * 12: 16 CEST - Poprawianie rozmieszczone, usługi przywrócone * * Root Cause: * * Zależność od konfiguracji pominięta podczas aktualizacji kredytowej nie pozwala na uwierzytelnienie aplikacji w bazie danych. Było to związane z incydentem z 6 kwietnia; dodatkowe uzależnienie zostało obecnie zidentyfikowane i włączone do procedury rotacji. * * Resolution: * * Zmodyfikowana konfiguracja została zregenerowana i aplikacja została ponownie uruchomiona. Usługa powróciła do pełnej pracy bez utraty danych. * * Środki zapobiegawcze: * * * Wszystkie zależności kredytowe zostały w pełni odwzorowane, a procedura rotacji została zaktualizowana, aby objąć je pojedynczą operacją atomową Przepraszamy za zakłócenia. Pozostajemy zaangażowani w niezawodność platformy Exalate.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 6 kwietnia 2026 11:07 UTCinvestigating

   Obecnie badamy problem, gdy miejsca pracy nie ładują informacji. Synchronizacja nie jest naruszona, ale interfejs z New Exalate nie ładuje.

2. 6 kwietnia 2026 11:28 UTCmonitoring

   Zidentyfikowaliśmy i wdrożyliśmy rozwiązanie. Exalate.app jest obecnie operacyjny i działa zgodnie z oczekiwaniami, będziemy nadal monitorować sytuację i wkrótce dostarczyć aktualizację.

3. 6 kwietnia 2026 15:31 UTCresolved

   Ten incydent został rozwiązany.

4. 7 lipca 2026 12:30 UTCpostmortem

   * * Incydent: * * Exalate.app Niewczytywanie miejsc pracy - 6 kwietnia 2026 * * Czas trwania: * * 13: 07 CEST - 13: 28 CEST\ (około 21 minut\). * * Uderzenie: * * Interfejs Exalate.app był niedostępny w tym oknie. Nie wpłynęła na synchronizację emisji - integracje nadal przebiegały normalnie. Brak danych. * * Streszczenie: * * W dniu 6 kwietnia 2026, interfejs Exalate.app stał się niedostępny po tym, jak w ramach zaplanowanego programu poprawy bezpieczeństwa zmieniono instrument kredytowy infrastruktury. Składnik odpowiedzialny za dostęp do bazy danych zapisuje dane uwierzytelniające przy starcie i nie przeładowuje ich automatycznie. Poprzednia karta kredytowa została usunięta przed ponownym uruchomieniem komponentu, aby odebrać nowy, powodując błędy uwierzytelniania. * * Timeline: * * * 13: 07 CEST - wykryta emisja, wszczęte dochodzenie * 13: 28 CEST - Poprawiono rozmieszczenie, przywrócono obsługę * * Root Cause: * * Rotacja kredytowa zakończona z sekwencji - stary kredytodawca został usunięty przed ponownym uruchomieniem nowego składnika. * * Resolution: * * Zagrożone składniki zostały ponownie uruchomione z poprawnymi referencjami. Usługa powróciła do pełnej pracy bez utraty danych. * * Środki zapobiegawcze: * * * Ustanowiono procedurę rotacji kredytowej egzekwującą obowiązkową sekwencję: uaktualnić, ponownie uruchomić konsumentów, zweryfikować, a następnie usunąć stare referencje * Bezpośrednie monitorowanie błędów uwierzytelniania połączeń w bazie danych jest wdrażany * Migracja do zautomatyzowanego zarządzania kredytami, które eliminuje ręczną rotację dla tego obciążenia pracą jest w toku Przepraszamy za zakłócenia. Pozostajemy zaangażowani w niezawodność platformy Exalate.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 2 kwietnia 2026 15:41 UTCinvestigating

   Prowadzimy śledztwo w sprawie niedostępnych węzłów Exalate. Wkrótce dostarczymy nowe informacje na temat śledztwa. Następna aktualizacja w ciągu 2 godzin - lub jak tylko będziemy mieli odpowiednie aktualizacje

2. 2 kwietnia 2026 16:37 UTCidentified

   Problem został zidentyfikowany i obecnie pracujemy nad jak najszybszym przywróceniem węzłów. Następna aktualizacja w ciągu 2 godzin lub jak tylko będziemy mieli odpowiednie aktualizacje

3. 2 kwietnia 2026 18:25 UTCidentified

   Kontynuujemy prace remontowe. Niektóre węzły są już dostępne. Następna aktualizacja odbędzie się w ciągu 2 godzin lub jak tylko będziemy mieć odpowiednie aktualizacje.

4. 2 kwietnia 2026 19:18 UTCmonitoring

   Wszystkie węzły zostały przywrócone. Nasz zespół ściśle monitoruje system, aby zapewnić stałą stabilność.

5. 2 kwietnia 2026 21:26 UTCresolved

   Ten incydent został rozwiązany.

6. 25 października 2026 10:25 UTCpostmortem

   / Incydent: Wyrównaj zakłócenie usługi w chmurze - 2 kwietnia 2026 r. * * Czas trwania: * * 16: 30 - 21: 25 CEST\ (4 godziny 55 minut\) * * Impact: * * Około 60 węzłów chmurowych w naszym belgijskim klastrze było niedostępnych. Synchronizacje na tych węzłach nie działały przez cały czas przestoju i zostały automatycznie wznowione po przywróceniu węzłów. Brak danych. * * Streszczenie: * * Podczas planowanej rotacji wewnętrznych certyfikatów Kubernetes, każdy węzeł pracy w klastrze ponownie uruchomił swój agent w tym samym czasie. Każdy pracownik jednocześnie poprosił API przechowywania o ponowne zweryfikowanie swoich dysków, a ilość jednoczesnych wniosków przytłoczyła API. Z pamięci API nie reaguje, dotknięte węzły nie mógł dołączyć swoje dyski i pozostał offline. * * Resolution: * * Ruch do magazynu API został odizolowany, a komponent ponownie zaczął usuwać zaległości. Węzły zostały następnie przywrócone do służby w kontrolowanej kolejności, jeden pracownik na raz, aż wszystkie węzły były online o 21: 25 CEST. * * Środki zapobiegawcze: * * Procedura rotacji certyfikatu jest zmieniana w taki sposób, że restart węzła jest przyspieszony i złączony, a nie wykonywany jednocześnie, a to przejście jest wbudowane w oprzyrządowanie, a nie stosowane ręcznie. Ponadto współpracujemy z naszym partnerem w zakresie infrastruktury nad ograniczeniem stawki ochronnej dla API przechowywania, nad zmianą sterownika przechowywania, tak aby węzły weryfikowały swoje dyski lokalnie zamiast wywoływać API, oraz nad monitorowaniem alarmów o nasyceniu API, zanim wpłynie to na klientów. Przepraszamy za zakłócenia. Pozostajemy zaangażowani w niezawodność platformy Exalate.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 16 marca 2026 15:13 UTCinvestigating

   We are investigating reports by some users that the Exalate app is not available right now.

2. 16 marca 2026 15:56 UTCidentified

   We have identified the problem and the team is working to rectify this. We will provide an update of progress shortly.

3. 16 marca 2026 16:09 UTCmonitoring

   The services are fully functional again. We are very closely monitoring the situation.

4. 16 marca 2026 17:13 UTCresolved

   All systems are functional. We will be providing a post-mortem of the incident here in due course.

5. 31 marca 2026 09:44 UTCpostmortem

   **Incident:** Exalate Application Unavailability — March 16, 2026 **Duration:** 16:13 CET – 17:09 CET \(approximately 56 minutes\) **Impact:** The Exalate UI was inaccessible during this window. Issue synchronisation was not affected — integrations continued to run normally throughout. No data was lost. **Summary:** On March 16, 2026, the Exalate application became unavailable following a production infrastructure configuration change. A resource allocation adjustment applied to a critical authentication component proved insufficient under production load, causing repeated service interruptions. **Timeline:** * 16:13 CET — Issue reported, investigation initiated * 16:56 CET — Root cause identified, remediation initiated * 17:09 CET — Fix deployed, service restored * 18:13 CET — Full stability confirmed **Root Cause:** A resource limit adjustment deployed without cross-team review under-provisioned a critical authentication component. Under production load, the platform repeatedly terminated the component, rendering the application inaccessible. **Resolution:** Resource limits were corrected, restoring service. A further optimisation was applied during a subsequent scheduled maintenance window following joint engineering review. **Preventive Measures:** * All production infrastructure configuration changes now require joint sign-off from infrastructure and engineering leads before deployment * Resource and capacity parameters validated against production load baselines prior to deployment

1. 13 marca 2026 11:56 UTCinvestigating

   We are currently investigating an issue causing the Exalate website to be temporarily unavailable. Our team is actively working to identify the root cause and restore access as quickly as possible. This issue is strictly isolated to the Exalate.com webpage. Please note that Exalate.app and individual Nodes are not affected, and there is no impact on active integrations. We will provide an update within 4 hours, or sooner if new information becomes available.

2. 13 marca 2026 13:03 UTCinvestigating

   Update: We are continuing to investigate the performance issues affecting Exalate.com. We have identified an ongoing incident with our hosting provider, Hostinger, and are currently verifying the extent of the impact on our services. You can track their status directly here: https://statuspage.hostinger.com We will provide another update as soon as we have more information, or within the next 4 hours.

3. 13 marca 2026 14:31 UTCmonitoring

   We have identified and mitigated the issue that was causing performance degradation and intermittent unavailability of the Exalate.com website. After implementing mitigation measures, the website is now fully accessible and performing as expected. We have confirmed that Exalate.app, individual Nodes, and all active integrations remained unaffected throughout this incident. Our team will continue to monitor the situation closely to ensure continued stability. We will provide further updates only if the situation changes.

4. 13 marca 2026 18:19 UTCresolved

   This incident has been resolved.

5. 31 marca 2026 09:46 UTCpostmortem

   **Date:** March 17, 2026 **Duration:** 12:10 CET - 15:00 CET \(2 hours, 50 minutes\) **Impact:** The [exalate.com](http://exalate.com) website was completely inaccessible to all users for the duration of the incident. **Summary:** The hosting environment experienced resource exhaustion triggered by a sudden surge in web traffic. This was further exacerbated by a malfunctioning security plugin. **Timeline:** 12:10 CET: Incident start \(resource exhaustion begins\) 12:28 CET: Issue detected 14:40 CET: Root cause identified 15:00 CET: Service fully restored **Root Cause:** A spike in unique visitors has led to resource depletion on the hosting server. During the investigation, it was discovered that an installed security plugin was behaving inefficiently under high load, significantly compounding the CPU and memory usage, preventing the server from recovering. **Resolution:** Identified and blocked specific IP addresses responsible for an anomalous volume of requests. Deactivated and removed the problematic security plugin. Implemented an alternative solution to handle the plugin's core functionality without the performance overhead. **Preventive Measures:** Investigate and implement automated rate-limiting and IP blocking solutions \(e.g., WAF rules\) to handle traffic spikes.

1. 9 marca 2026 06:59 UTCinvestigating

   We have reports of some Exlate cloud nodes being unavailable. Our team is currently investigating the issue.

2. 9 marca 2026 07:11 UTCidentified

   Our cloud team has identified the root cause and is actively engaged in rectifying it.

3. 9 marca 2026 07:20 UTCmonitoring

   The issue has been fully rectified and all nodes are fully restored. We are closely monitoring the situation.

4. 9 marca 2026 09:00 UTCresolved

   After close monitoring, we consider the issue fully resolved. An RCA would be published here in due course.

5. 1 kwietnia 2026 03:39 UTCpostmortem

   **Incident:** Exalate Cloud Service Disruption - March 9, 2026 **Duration:** 07:30 CET – 08:10 CET \(approximately 40 minutes\) **Impact:** Some Exalate Cloud nodes experienced temporary service disruption. Database write operations were briefly affected. Issue synchronisation resumed automatically once the issue was resolved. No data was lost. **Summary:** On March 9, 2026, the primary database instance serving part of the Exalate Cloud infrastructure reached full storage capacity. This prevented the database from processing write operations, temporarily impacting node availability. **Timeline:** * 07:30 CET - Issue detected, investigation initiated * 08:05 CET - Storage expanded, database operations resumed * 08:10 CET - Fix verified, nodes confirmed operational * 10:00 CET - Full stability confirmed after extended monitoring **Root Cause:** The primary database storage volume gradually reached full capacity under normal operational growth. Proactive storage monitoring did not fire in time. **Resolution:** Database storage was expanded and the service returned to full operation automatically. Additional alerting configured.

1. 23 stycznia 2026 09:59 UTCinvestigating

   We have identify an incident with exalate.app that is currently not loading. We are currently investigating the issue and will be providing updates within the hour. This is not affecting the sync of issues but the UI for exalate is currently unavailable.

2. 23 stycznia 2026 10:18 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

3. 23 stycznia 2026 12:18 UTCresolved

   This incident has been resolved.

4. 31 marca 2026 09:43 UTCpostmortem

   **Incident:** Exalate Application Unavailability — January 23, 2026 **Duration:** 10:59 CET – 11:18 CET \(approximately 19 minutes\) **Impact:** The Exalate UI was inaccessible during this window. Issue synchronisation was not affected — integrations continued to run normally throughout. No data was lost. **Summary:** On January 23, 2026, our monitoring detected a service outage affecting the Exalate application. The root cause was a deployment configuration change that unintentionally removed an active compute resource from the production environment. **Timeline:** * 10:59 CET — Issue detected, investigation initiated * 11:18 CET — Fix deployed, service restored * 13:18 CET — Full stability confirmed **Root Cause:** A deployment configuration change targeted the wrong resource section, resulting in an active production compute resource being removed and the application becoming inaccessible. **Resolution:** The affected resource was recreated and all services returned to full operation with no data loss. **Preventive Measures:** * Infrastructure-as-code changes must be validated in a non-production environment before production deployment * Peer review steps introduced to verify configuration targets prior to execution

1. 12 grudnia 2025 16:15 UTCinvestigating

   There is an outage on one of the clusters in Exalate cloud that might affect access to the nodes temporarily. We are currently investigating the issue to ensure that service is restored as soon as possible. A new update will be provided within 1 hour

2. 12 grudnia 2025 16:31 UTCidentified

   We have root caused the issue and the restoration process is underway already. The next update will be provided in 30mins.

3. 12 grudnia 2025 16:58 UTCidentified

   The recovery process is still ongoing. We will provide an update within an hour.

4. 12 grudnia 2025 19:11 UTCidentified

   We continue to work on the restoration of the affected nodes. We will be providing a new update in one hour.

5. 12 grudnia 2025 20:20 UTCidentified

   Nodes are being restored now, most nodes are now online, a full operational message will be posted once all nodes are back online.

6. 13 grudnia 2025 01:51 UTCidentified

   Most nodes are back on operational status, a full operational message will be posted once all nodes are back.

7. 13 grudnia 2025 02:56 UTCmonitoring

   All nodes are back to operational status now. We continue to monitor the stability closely.

8. 13 grudnia 2025 04:26 UTCresolved

   All Exalate nodes are stable and working normally. A post-mortem for the incident will be published in due course.

9. 22 grudnia 2025 04:43 UTCpostmortem

   **Incident: Service Outage - December 12, 2025** **Duration:** 16:35 CET - 03:01 CET \(approximately 10 hours\) **Impact:** A significant number of Exalate Cloud nodes experienced service unavailability, resulting in temporary disruption to data synchronization services. No data was lost during this incident. **Summary:** On December 12, 2025, our infrastructure monitoring detected a service outage affecting Exalate Cloud customers on our production clusters. The root cause was identified as a storage system failure triggered by network latency on a legacy infrastructure component, which caused storage connectivity issues for customer workloads. **Timeline:** * 16:35 CET - Issue detected by monitoring systems * 17:31 CET - Root cause identified, restoration initiated * 21:20 CET - Majority of nodes restored to service * 03:01 CET - Full service restoration confirmed **Root Cause:** A storage management component became unresponsive due to elevated network latency caused by a legacy networking layer. This resulted in storage disconnection for customer workloads. **Resolution:** The storage system was restored, all affected workloads were rescheduled, and the external dependency was updated to a supported version. All nodes were returned to full operation with no data loss. **Preventive Measures:** * Deploying patches to address the storage component stability issue * Accelerating migration away from the legacy networking layer to modern infrastructure * Implementing internal mirroring of critical external dependencies to eliminate reliance on third-party availability * Enhancing operational safeguards for infrastructure management procedures We sincerely apologize for the disruption this incident caused. Our team remains committed to improving the reliability and resilience of the Exalate Cloud platform.

1. 27 listopada 2025 11:47 UTCinvestigating

   We are investigating reports of some Exalate nodes being unavailable. We will be providing an update shortly on the investigation.

2. 27 listopada 2025 12:33 UTCidentified

   We have identified the problem and are working to restore full service as soon as possible.

3. 27 listopada 2025 13:47 UTCidentified

   Most nodes are currently running but we are still experiencing intermittent service failures. The full fix is being implemented now.

4. 27 listopada 2025 15:31 UTCmonitoring

   All nodes are back online and we are closely monitoring the cluster health.

5. 27 listopada 2025 16:51 UTCidentified

   We have detected some instability again and are investigating why some nodes are not reachable again.

6. 27 listopada 2025 20:48 UTCidentified

   All nodes are now back online and our team is working on stabilizing the services

7. 27 listopada 2025 22:04 UTCmonitoring

   All nodes are now fully operational. Any communication error reported in the console should now disappear after hitting "Resolve and retry". If you encounter any further problem please reach out to our support team. We continue to monitor the cluster closely and investigate to root cause the incident.

8. 28 listopada 2025 07:08 UTCresolved

   We have closely monitored the health of the affected Exalate nodes, and they are all performing as per expectation. A post-mortem of the incident will be published in due course.

9. 12 grudnia 2025 12:02 UTCpostmortem

   **Incident: Service Degradation - November 27, 2025** **Duration:** 11:26 CET - 21:37 CET \(~10 hours\) **Impact:** Approximately 700 Exalate Cloud nodes experienced intermittent connectivity issues, resulting in temporary disruption to data synchronization services. No data was lost during this incident. **Summary:** On November 27, 2025, our infrastructure monitoring detected service degradation affecting a subset of Exalate Cloud customers. The root cause was identified as storage I/O contention on the underlying database infrastructure, which caused the primary database to become unresponsive intermittently. **Timeline:** * 11:26 CET - Issue detected by monitoring systems * 11:30 CET - Engineering team began investigation * 15:30 CET - Initial mitigation applied \(infrastructure scaling\) * 18:30 CET - Root cause identified and permanent remediation initiated * 21:37 CET - Full service restoration confirmed **Root Cause:** Database storage was experiencing resource contention due to shared infrastructure components, causing elevated I/O latency. This triggered automated health checks to restart the database service repeatedly, compounding the connectivity issues. **Resolution:** The database was migrated to dedicated storage resources and allocated additional compute capacity. All affected nodes were restored to full operation with no data loss. **Preventive Measures:** * Implementing enhanced storage latency monitoring and alerting * Reviewing infrastructure health check configurations for database workloads * Auditing storage allocation across all database clusters to prevent similar contention We apologize for any inconvenience this incident may have caused. Our team remains committed to maintaining the reliability and performance of the Exalate Cloud platform.

1. 20 listopada 2025 09:43 UTCidentified

   We have identified an issue when trying to access the SyncRoom page, caused by a significant increase in DNS traffic originating from an external problem between Hostinger and Cloudflare. This external issue is currently impacting our service and is preventing the SyncRoom page and the community from loading Important Note: This issue does not affect the core Exalate functionality. Synchronization is continuing to work as expected. We are actively working to resolve this and will provide an update within the next two hours. Thank you for your patience.

2. 20 listopada 2025 10:29 UTCmonitoring

   A fix has been implemented by Hostinger and the services have been restored (Exalate community and SyncRoom) We will continue to monitor the results.

3. 20 listopada 2025 11:23 UTCresolved

   This incident has been resolved.

4. 1 kwietnia 2026 04:08 UTCpostmortem

   timeout

1. 4 października 2025 06:18 UTCinvestigating

   We are investigating reports of users unable to access the Exalate console on some systems. We will be providing an update soon.

2. 4 października 2025 06:30 UTCmonitoring

   The problem has been identified and the fix has been put in place.

3. 4 października 2025 06:54 UTCresolved

   The issue is fully resolved and all nodes are operational. A post-mortem will be provided here in due course.

4. 14 listopada 2025 12:23 UTCpostmortem

   ## **Summary** On October 4, 2025, Exalate Cloud experienced an issue that caused some Exalate nodes to become temporarily inaccessible at 04:00 CEST. This resulted in UI access issues and potential synchronization interruptions for part of our customer base. All services were fully restored by 09:00 CEST. ## **Impact** Customers using Exalate cloud nodes experienced: * Inability to access nodes * Sync failures or delays * Temporary disruption of workflow automations No data loss occurred. ## **Root Cause** There was an error in the certification renewal process. This prevented affected nodes from completing required secure connections, making them temporarily unreachable. ## **Resolution** After identifying the cause, the certificate was renewed and deployed. Services began recovering immediately and full functionality was validated shortly thereafter. ## **Preventive Measures** We are implementing several improvements to prevent recurrence, including: * Expanded automated monitoring for certificate validity * Additional service health checks, including customer-facing endpoints * Automated renewal processes for critical certificates * Strengthened operational procedures around certificate lifecycle management

1. 3 października 2025 09:43 UTCmonitoring

   We've released a configuration update for Jira Cloud connections running version 5.28.5. Who is affected: Customers using external script repositories in their Jira Cloud connections may experience script-related errors after upgrading to 5.28.5. Resolution: If you're experiencing issues with your scripts, please contact our support team at [email protected] - we'll assist you with a quick configuration update. Status: We're actively monitoring and reaching out to affected customers.

2. 5 listopada 2025 14:17 UTCresolved

   This incident has been resolved.

3. 1 kwietnia 2026 04:09 UTCpostmortem

   timeout

1. 24 września 2025 10:56 UTCinvestigating

   There is an outage on one of the clusters in Exalate cloud that might affect access to the nodes temporarily. We are currently investigating the issue to ensure that service is restored as soon as possible.

2. 24 września 2025 11:18 UTCidentified

   We have root caused the issue and the restoration process is underway already. The next update will be provided in 30mins.

3. 24 września 2025 11:47 UTCidentified

   The recovery process is still ongoing. We will provide an update within an hour.

4. 24 września 2025 13:00 UTCmonitoring

   All nodes are fully recovered. We continue to closely monitor the situation.

5. 24 września 2025 14:50 UTCidentified

   Our monitoring uncovered a problem still lingering with the cluster. We are working to restore full functionality as soon as possible.

6. 24 września 2025 16:56 UTCidentified

   Node recovery has presented some challenges and is taking longer than expected. We continue to strive to bring all nodes back online as soon as possible. Next update will be provided within 2 hours.

7. 24 września 2025 18:47 UTCidentified

   Infrastructure component failures have been addressed by our Engineering team. Next step: We are restarting the individual Exalate nodes impacted by the failure. More information will be provided in an hour.

8. 24 września 2025 19:54 UTCidentified

   We continue restarting the individual Exalate nodes impacted by the failure. 5% of the affected nodes have been brought back online. Further updates to be expected in an hour

9. 24 września 2025 20:51 UTCidentified

   The team is actively working through the restart sequence for all individual Exalate nodes. This is a deliberate, multi-step process to ensure stability upon full restoration. Further updates to be expected in an hour.

10. 24 września 2025 21:45 UTCidentified

    Following the deliberate, multi-step sequence, the engineering team has now moved into the main restoration phase. We are actively scaling up the restart of the affected Exalate nodes. We'll continue to monitor stability closely. We will provide the next update in one hour.

11. 24 września 2025 22:49 UTCidentified

    The engineering team continue working on the main restoration phase. We'll continue to monitor stability closely. Further updates to be expected in an hour

12. 24 września 2025 23:50 UTCidentified

    During the scale-up phase, the restoration process has presented some challenges that are taking longer than initially expected to resolve. The engineering team is actively working to address these stability issues. We will provide the next update within one hour.

13. 25 września 2025 00:48 UTCidentified

    The previous technical challenges have been addressed. We have re-initiated the scale-up of the Exalate nodes and are closely monitoring the environment for stability. We will provide the next update within one hour.

14. 25 września 2025 01:44 UTCidentified

    We are continuing the scale-up of the Exalate nodes. The team is maintaining a close monitoring posture to ensure stability throughout this process. We will provide the next update in one hour.

15. 25 września 2025 03:23 UTCmonitoring

    All nodes are fully restored and functioning normally now. We continue to monitor the cluster carefully to ensure stability.

16. 25 września 2025 14:21 UTCresolved

    We have extensively monitored the cluster health and there have been no outstanding issues found.

17. 10 października 2025 10:41 UTCpostmortem

    ## Executive Summary On September 24, 2025, Exalate experienced a service interruption lasting 17 hours and 28 minutes that affected our cloud-hosted integration nodes. During this time, customers were unable to synchronize data between their integrated systems. **No customer data was lost.** We sincerely apologize for the inconvenience and want to share what happened and how we're preventing future issues. ## What Happened **Timeline:** * **10:02 UTC \(Sept 24\):** Infrastructure issue detected through customer reports * **13:00 UTC:** Partial service restoration achieved * **13:45 UTC:** Secondary technical issue caused complete service unavailability * **17:24 UTC:** Core infrastructure restored * **21:00 UTC:** Priority customer services online * **03:30 UTC \(Sept 25\):** Full service restoration completed **Root Cause:** A network connectivity issue on our hosting platform triggered a cascading infrastructure failure. The recovery process was complex due to database resilience challenges and infrastructure management system complications. ## Customer Impact **During the outage:** * Data synchronization between systems \(Jira, ServiceNow, etc.\) was unavailable * Automated workflow processes were temporarily halted **What was NOT affected:** * **No customer data was lost or corrupted** * All existing synchronized data remained intact * Customer configurations and sync histories were preserved ## Our Response We immediately activated our 24/7 incident response team, maintained continuous status page updates, directly contacted Enterprise customers, and coordinated with infrastructure providers throughout the recovery. ## Prevention Measures We're implementing comprehensive improvements on an accelerated timeline: **Immediate \(October 2025\):** * Enhanced infrastructure monitoring and alerting systems * Comprehensive disaster recovery documentation **Short-term \(November 2025\):** * Infrastructure resilience improvements * Automated recovery procedures * Regular disaster recovery testing **Medium-term \(Q1 2026\):** * Multi-cloud architecture implementation * Advanced predictive monitoring ## Customer Support If you need assistance related to this outage: * **Enterprise Customers:** Use your dedicated support channels * **Standard Support:** Submit tickets through our support portal * **Status Updates:** Monitor our status page for ongoing information We apologize for this service disruption and appreciate your patience. Your trust is essential to our business, and we're committed to earning it through reliable service delivery and continuous improvement.

1. 29 sierpnia 2025 16:18 UTCinvestigating

   We are investigating a problem where IssueLinks are being removed from Jira cloud tickets. Progress and actions will be notified accordingly, if you encountered this problem please reach us on support portal.

2. 29 sierpnia 2025 16:57 UTCidentified

   The issue has been identified and we are performing remediation actions.

3. 29 sierpnia 2025 21:04 UTCidentified

   All nodes have been moved from the affected version and a workaround to remediate the possible effects on issue links is being investigated.

4. 31 sierpnia 2025 19:00 UTCmonitoring

   We identified the affected instances and provided remediation steps to all affected clients to restore the removed links.

5. 5 września 2025 11:56 UTCresolved

   The issue affecting Jira Cloud issue links has been fully resolved. A detailed postmortem will be published soon outlining the root cause and preventive measures being implemented.

6. 18 września 2025 06:57 UTCpostmortem

   # Exalate v5.28 Issue Links Synchronization - Technical Incident Report **Incident Date:** 29/Aug/2025 **Duration:** ~4 hours from detection to rollback completion **Impact:** Issue link synchronization behavior change affecting multiple customer instances **Status:** Resolved with data restoration completed ## Timeline The incident was first detected  on 29/Aug at 17:56 when a customer reported issue links being removed after upgrading to v5.28. Within eight minutes, at 18:04, the support team received multiple similar reports and immediately requested a rollback. The formal incident response was initiated at 18:17, and the rollback process to v5.27.0 began at 18:48. The rollback was completed across all affected instances by 22:12 the same day, approximately four hours after initial detection. Recovery efforts continued over the weekend. On 30/Aug at 09:43, the data restoration team was assembled and began developing recovery procedures. The comprehensive customer communication deployment occurred on 01/Sep at 17:05, providing affected customers with restoration instructions and individualized support. _\(All times CET\)_ ‌ ‌ ## Root Cause Analysis The technical issue stemmed from a synchronization enhancement in v5.28 that compared issue links between source and destination systems. The implementation operated under the assumption that links present on the destination but not on the source represented synchronization inconsistencies requiring removal. This approach failed to distinguish between links managed by Exalate and links created independently outside the synchronization scope. Several contributing factors enabled this issue to reach production. The scope definition did not account for mixed environments where synchronized and non-synchronized links coexist on the same system. Test coverage focused primarily on standard synchronization flows rather than these mixed data environments. Additionally, the modification affected a broader scope than initially anticipated during the development and review process. The impact characteristics were significant but recoverable. Multiple customer instances experienced removal of issue links that existed outside the intended synchronization scope. However, service functionality continued throughout the incident, and comprehensive audit logs preserved all affected link data, which enabled complete restoration of the removed links.Regarding data security and privacy, the audit logs contain only metadata elements such as issue identifiers, link types, and relationship mappings. No sensitive customer content, comments, or detailed issue information was captured in these logs. This metadata-only approach ensured that the restoration process could proceed while maintaining appropriate data protection standards. ## Learnings On the positive side, the incident response team made a rapid rollback decision, quickly identifying this as the appropriate technical solution rather than attempting a forward fix. The comprehensive logging infrastructure proved invaluable, enabling complete data restoration from audit trails. Cross-functional coordination worked well across engineering, customer success, and operations teams. The structured communication approach maintained clarity and transparency throughout the resolution process. The incident also revealed important areas for system enhancement. Synchronization logic in complex integration scenarios requires better handling of mixed data environments where multiple systems manage different subsets of the same data types. Testing scope needs expansion to cover mixed synchronized and non-synchronized environments comprehensively. Change evaluation processes require enhancement for modifications that affect customer data. Monitoring capabilities need improvement to enable proactive detection of synchronization behavior changes before customer impact. Several process improvements have been \(or are being\) implemented as a result. Enhanced code review procedures now include additional requirements specifically for data modification operations. Expanded testing protocols cover scenarios involving mixed data environments and include dedicated data preservation validation. Improved monitoring systems detect synchronization pattern changes and unusual data modification activities. Updated release procedures include enhanced evaluation criteria for data-affecting changes and improved rollback automation capabilities.