Historia awarii Neo4j Aura

1. 26 października 2026 14:50 UTCinvestigating

   Jesteśmy obecnie świadomi problemu, który wpływa na klientów za pomocą Aura na Azure, próbując pobrać migawki instancji bazy danych.

2. 26 października 2026 15:09 UTCidentified

   Zidentyfikowaliśmy tę kwestię i obecnie pracujemy nad wdrożeniem rozwiązania.

3. 26 października 2026 16:22 UTCidentified

   Fix jest obecnie testowany w niższych środowiskach, przed wdrożeniem.

4. 26 października 2026 17:43 UTCidentified

   Testowanie naprawić jest w toku i rozmieszczenie będzie kontynuowane po zakończeniu badania.

5. 26 października 2026 19:14 UTCresolved

   Nasi inżynierowie z powodzeniem wprowadzili rozwiązanie i sprawa została rozwiązana. Klienci aura na Azure mogą teraz pobrać migawki bazy danych bez problemów.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 20 października 2026 07:35 UTCinvestigating

   Obecnie badamy problem dotyczący regionu Europy Zachodniej 2 w ramach GCP, który wpływa na niektóre operacje, w tym tworzenie instancji baz danych w regionie.

2. 20 października 2026 08:36 UTCinvestigating

   Obecnie nadal badamy tę kwestię, współpracując z GCP w celu znalezienia rezolucji. Obecnie niektóre operacje, w tym tworzenie instancji baz danych w regionie, nadal mają wpływ.

3. 20 października 2026 09:15 UTCidentified

   Zidentyfikowaliśmy źródło problemu dotykającego obecnie klientów w Europie Zachodniej2 w GCP. Dalsze informacje dostępne od GCP statuspage pod adresem https: / / status.cloudd.google.com / invents / Xs2XTHzaAVC9YnafnPyzj. Obecnie niektóre operacje, w tym tworzenie instancji baz danych w regionie, nadal mają wpływ.

4. 20 października 2026 10:42 UTCidentified

   Obecnie wdrażamy działania naprawcze w celu złagodzenia tej kwestii w międzyczasie. Podążaj za najnowszymi informacjami z GCP na stronie statuspage pod adresem https: / / status.cloudd.google.com / invents / Xs2XTHzaAVC9YnafnPyzj.

5. 20 października 2026 12:38 UTCmonitoring

   Funkcjonalność powinna teraz zostać przywrócona w ramach usług Aura, których to dotyczy. Będziemy uważnie monitorować sytuację przed rozważeniem jej rozwiązania.

6. 20 października 2026 14:06 UTCmonitoring

   W chwili obecnej nadal monitorujemy sytuację z GCP i w tym momencie nie widzieliśmy żadnych nowych problemów.

7. 20 października 2026 14:50 UTCresolved

   Ten incydent został rozwiązany

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 13 października 2026 09:15 UTCinvestigating

   Badamy problem wpływający na wskaźniki w konsoli Aura i poprzez punkt końcowy metryczny.

2. 13 października 2026 10:13 UTCidentified

   Zidentyfikowaliśmy, że problem Cloud Service Provider wpływa na obecną sytuację. Otworzyliśmy w Cloud Service Provider sprawę wsparcia i będziemy aktualizować, gdy będziemy mieć więcej szczegółów.

3. 13 października 2026 11:01 UTCmonitoring

   Uważamy, że problem dostawcy usług w chmurze został rozwiązany, ponieważ nie widzimy już problemów z naszych systemów wewnętrznych. Będziemy nadal monitorować sytuację, podczas gdy czekamy na potwierdzenie od dostawcy Cloud Service.

4. 13 października 2026 12:08 UTCresolved

   Dostawca usług w chmurze potwierdził, że sprawa została w pełni rozwiązana.

5. 16 października 2026 17:06 UTCpostmortem

   _ * * Błędy podczas wysyłania pomiarów z GCP europe- west1 * * _ Co się stało? _ We wtorek, 13 października 2026 o godzinie 08: 54 UTC, wskaźniki dla instancji w GCP europe- west1 przestały być dostarczane i nie mogły być odczytywane. Przyczyną był problem po stronie Google Cloud, w którym zmniejszenie przepustowości w usłudze monitorowania doprowadziło do nieprawidłowego odrzucenia ważnych wniosków. Metrics powraca do normy o 10: 49 UTC po zastosowaniu poprawki przez Google Cloud, a my rozwiązujemy ten incydent o 12: 08 UTC, gdy Google Cloud potwierdzi pełną rozdzielczość. _ _ Przypadki pozostawały dostępne przez cały czas trwania zdarzenia, bez wpływu na wydajność zapytania lub integralność danych. Tylko widzialność metryczna została naruszona. * * * How the service was affected * * _ Klienci widzieli kilka krótkich luk na przykład metryki: _ * _ * * Metrics konsoli: * * Przypadki w GCP europe- west1 mogły wykazywać niekompletne lub brakujące dane metryczne w oknie zdarzenia. _ * _ * * Integracja monitorowania chmur\ (CMI\): * * Metryki przekazane do własnych systemów monitorowania z tego regionu również mogły mieć luki. _ _ Nie wszystkie przypadki w regionie zostały naruszone, a inni dostawcy chmur i regiony nie zostały naruszone. Metrics generowane podczas incydentu nie zostały zarejestrowane, więc luka pozostanie w historycznych wykresach dla dotkniętych przypadków. _ Co teraz robimy? _ Fix pochodzi z Google Cloud przy tej okazji, ale nasz rurociąg metryczny opierał się na ścieżce jednego regionu, więc podejmujemy kroki w celu zmniejszenia tej ekspozycji: _ Odporność regionalna: * * Oceniamy trasy w różnych regionach, aby ruch metryczny mógł się nie udać do zdrowego regionu. / Traffic routing: Badamy opcje w naszej warstwie sieciowej w chmurze, aby przekierować odczyty\ (Konsola i CMI\) i pisze\ (Spożycie\) z obszaru dotkniętego. _

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 8 października 2026 14:58 UTCinvestigating

   Badamy problem z metryką w konsoli Aura i poprzez punkt końcowy metryczny.

2. 8 października 2026 15:36 UTCidentified

   Badamy przyczynę. Problem jest ograniczony do klientów na naszym centrali1 na GCP Przypadki aury są uruchomione i nie ma wpływu na działanie.

3. 8 października 2026 16:30 UTCidentified

   Współpracujemy z dostawcą usług w chmurze, aby zbadać charakter problemu. Nasze kontrole potwierdzają, że dotyczy to tylko podzbioru klientów działających w regionach us- central1.

4. 8 października 2026 18:41 UTCidentified

   Kontynuujemy współpracę z dostawcą usług w chmurze, aby uzyskać rozwiązanie.

5. 8 października 2026 19:11 UTCresolved

   Ten incydent został już rozwiązany, pomiary powinny działać jak zwykle.

6. 16 października 2026 17:04 UTCpostmortem

   * * Błędy podczas wysyłania danych z GCP us- central1 * * _ Co się stało? _ W czwartek, 8 października 2026 o 14: 05 UTC, wskaźniki z niektórych przypadków w GCP us- central1 przestał być dostarczany. Przyczyną był problem po stronie Google Cloud, który błędnie odrzucił ważne żądania metryczne. Metric dostawy wznowione o 18: 00 UTC po Google Cloud zastosować fix, a my rozwiązać incydent o 18: 48 UTC. _ _ Przypadki pozostawały dostępne przez cały czas trwania zdarzenia, bez wpływu na wydajność zapytania lub integralność danych. Tylko widzialność metryczna została tymczasowo naruszona. * * * How the service was affected * * _ Klienci widzieli luki w przykładowych danych: _ * _ * * Metrics konsoli: * * Przypadki w systemie GCP us- central1 mogły wykazywać niekompletne lub brakujące dane metryczne w oknie zdarzenia. _ * _ * * Integracja monitorowania chmur\ (CMI\): * * Metryki przekazane do własnych systemów monitorowania z tego regionu również mogły mieć luki. _ _ Nie wszystkie przypadki w regionie zostały naruszone, a inni dostawcy chmur i regiony nie zostały naruszone. _ Co teraz robimy? _ Fix pochodzi z Google Cloud, ale podejmujemy kroki, aby złapać i reagować na podobne zdarzenia wcześniej: _ * _ * * Alerting on metric delivery error: * * Dodajemy ostrzeżenie o wskaźnikach błędów transmisji metrycznej, więc błędy po stronie provider- są wykrywane wcześniej i odróżniane od rutynowych luk. _ * _ * * Kontynuowane monitorowanie: * * Będziemy monitorować region za pomocą Google Cloud w celu ponownego wystąpienia. _

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 6 października 2026 09:22 UTCinvestigating

   Badamy problem, w którym, pomimo pomyślnego uzupełniania kopii zapasowych, pliki do pobierania migawek wracają do pustych wysypisk. Przywracanie z migawki przez konsolę Aura lub API nie jest uważane za naruszone, i sprawdzamy to teraz. Będziemy dzielić się aktualizacją, jak tylko będziemy mieć więcej informacji.

2. 6 października 2026 10:43 UTCinvestigating

   Kontynuujemy badanie tej kwestii. Operacje przywracania nie mają wpływu na tę kwestię.

3. 6 października 2026 13:41 UTCinvestigating

   Nadal badamy tę kwestię.

4. 6 października 2026 13:41 UTCinvestigating

   Nadal badamy ten problem.

5. 6 października 2026 15:19 UTCresolved

   Wprowadzono rozwiązanie; pliki do pobierania migawek zawierają odpowiednie dane.

6. 26 października 2026 08:58 UTCpostmortem

   Co się stało Na Fri, 18 września 2026 14: 33 UTC, zidentyfikowaliśmy, że migawki do pobrania dla aura instancji hostowane na Azure zwracają pliki o około 24KB zamiast oczekiwanych wielowymiarowych rozmiarów. Bazowe kopie zapasowe przechowywane w Azure były właściwe rozmiar, ale ścieżka pobierania w konsoli obsługiwała prawie puste pliki. Podstawową przyczyną był problem Azure creditical, który wystąpił podczas wdrożenia i uniemożliwił backup danych do pobrania. Początkowe poprawki zostały wprowadzone na Mon, 21 września 2026 10: 31 UTC, przywracając prawidłowe rozmiary pobierania. Jednakże ta sama kwestia kredytowa powtórzyła się w Tue, 06 paź 2026 08: 20 UTC, ponownie produkując puste pliki do pobrania migawek na wszystkich poziomach Azure. Nasz zespół inżynieryjny zidentyfikował nawrót, powiązał go z tą samą przyczyną, umieścił w produkcji ukierunkowany, wiarygodny sposób i zweryfikował, że pobrane pliki wróciły do oczekiwanej wielkości. Nie opublikowaliśmy na stronie status 18 września, ponieważ niewielka liczba klientów zostały dotknięte, i współpracowaliśmy z nimi bezpośrednio. Umieściliśmy na 6 października o 09: 22 UTC, około godziny po rozpoczęciu nawrotu, raz było wyraźnie szersze. # How the service was affected Pliki do pobrania migawki wpłynęły na AuraDS Professional and Enterprise, AuraDB Professional, Business Critical i Virtual Dedicated Cloud instancje uruchomione na Azure. * Myślenie pliki do pobrania zwracane nieużyteczne pliki. Kiedy klienci ściągali zdjęcia z konsoli, otrzymywali pliki z około 24KB zamiast rzeczywistych danych kopii zapasowych, które mogą mieć kilka gigabajtów w rozmiarze. Dzięki temu pobrane migawki były bezużyteczne do celów regeneracji lub migracji offline. * Same kopie zapasowe nie zostały utracone. Podstawowe kopie zapasowe artefaktów przechowywane w Azure pozostały nienaruszone i prawidłowo wielkości. Problem był ściśle na ścieżce pobierania, a nie w procesie tworzenia kopii zapasowych lub przechowywania danych. * Przywracanie przez konsolę było nienaruszone. In- platform przywracanie operacji\ (w przeciwieństwie do pobierania pliku pull\) nadal funkcjonować, ponieważ uzyskali dostęp do kopii zapasowych danych bezpośrednio niż przez dotkniętą ścieżkę pobierania. # What we are do now Podjęliśmy wiele kroków w celu rozwiązania tej kwestii i wdrożyliśmy zabezpieczenia zapobiegające ponownemu wystąpieniu. * Credential fix rozmieszczone. Naprawiliśmy problem Azure w produkcji, który natychmiast przywrócił pliki do pobierania migawek we wszystkich przypadkach. * Zapobieganie niezamierzonej rotacji kredytowej. Złożono zmianę kodu w celu odwrócenia logiki, która wywoływała rotację kredytową Azure w każdym rozmieszczeniu. Gwarantuje to, że przyszłe wdrażanie nie będzie nieumyślnie unieważniać istniejących mandatów, co było mechanizmem, który spowodował zarówno początkowy incydent, jak i jego ponowne wystąpienie. * W trakcie monitorowania. Monitorujemy pobieranie migawek Azure na wszystkich poziomach, aby potwierdzić ich stabilność. Poprosiliśmy zainteresowanych klientów, aby zweryfikowali, czy ich pliki do pobrania teraz zwracają oczekiwane rozmiary plików. Zmiany te dotyczą zarówno bezpośrednich objawów, jak i podstawowych zachowań wdrożeniowych, które pozwoliły na powrót problemu

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 6 października 2026 08:07 UTCidentified

   Zidentyfikowaliśmy problem, kiedy próbowaliśmy przywrócić obraz z AuraDS. Mamy gotowy plan i wkrótce go wdrożymy. W międzyczasie możesz odzyskać wsparcie.

2. 6 października 2026 09:07 UTCidentified

   Wyraźnie zidentyfikowaliśmy przyczynę i nadal pracujemy nad rozwiązaniem tej kwestii.

3. 6 października 2026 10:03 UTCidentified

   Nadal pracujemy nad rozwiązaniem tego problemu.

4. 6 października 2026 12:14 UTCidentified

   Niebawem zostanie uruchomiony system naprawczy dla poszkodowanych klientów.

5. 6 października 2026 13:35 UTCmonitoring

   Fix jest toczący się i dotknięci klienci powinni zobaczyć funkcjonalność przywrócony stopniowo.

6. 6 października 2026 14:04 UTCresolved

   Umieściliśmy rozwiązanie dla wszystkich klientów.

7. 26 października 2026 08:51 UTCpostmortem

   Co się stało Wada oprogramowania w centralnym komponencie zarządzania migawki Neo4j Aura przywraca porażkę dla instancji AuraDS Professional i AuraDS Enterprise na AWS. Kiedy zażądano przywrócenia, system sprawdzał instancję używając niewłaściwego typu zasobów i zwrócił błąd. Incydent został ogłoszony w poniedziałek, 05 paź 2026 21: 52 UTC. Nasz zespół inżynieryjny zidentyfikował przyczynę, opracował i zatwierdził fix, i wdrożył go do produkcji we wtorek, 06 października 2026 13: 37 UTC. # How the service was affected Uderzenie zostało zbadane w celu zmiksowania operacji przywrócenia AuraDS Professional i AuraDS Enterprise instancji. Dotknięci klienci nie byli w stanie przywrócić migawek za pośrednictwem konsoli Aura lub API Aura na czas trwania wydania. * Przywracanie prób zwróconych błędów, zakłócających przepływy pracy, które zależą od odtwarzania migawki. * Przypadki pozostawały dostępne przez cały czas trwania tego wydarzenia. Integralność danych nie miała wpływu. Przywracanie z pełnych i eksportowanych kopii zapasowych pozostało dostępne w ramach pracy. # What we are do now * Mamy naprawić wady w warstwie zarządzania Aura, które dotknęły AuraDS Professional i AuraDS Enterprise migawki przywraca i wdrożył fix do produkcji. * Optymalizacja rurociągu wdrożeniowego: Podczas tego incydentu, rurociąg wdrożeniowy trwał dłużej niż idealny ze względu na sekwencyjne tworzenie instancji testowej. Oceniliśmy równoległe tworzenie instancji testowych w celu skrócenia czasu oczekiwania podczas krytycznych rund. Poprawa ta ma na celu skrócenie czasu potrzebnego na zatwierdzenie i wysłanie rozwiązania w przyszłych incydentach, co zmniejszy wpływ na użytkownika

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 17 września 2026 16:46 UTCinvestigating

   Jesteśmy obecnie świadomi problemu, który wpływa na niektóre operacje bazy danych, takie jak tworzenie, usuwanie, klon dla klientów za pomocą Aura na Azure.

2. 17 września 2026 17:11 UTCidentified

   Zidentyfikowaliśmy tę kwestię i pracujemy nad rozwiązaniem. W tym czasie, niektóre operacje baz danych, takie jak tworzenie, usuwanie i klonowanie dla klientów za pomocą Neo4j Aura tylko na Azure, nadal mają wpływ.

3. 17 września 2026 19:06 UTCmonitoring

   Do wszystkich dotkniętych środowisk wprowadzono rozwiązanie. Będziemy monitorować sytuację, aby zapewnić pełne rozwiązanie problemu.

4. 17 września 2026 19:55 UTCresolved

   Po uruchomieniu naprawiacza, monitorowaliśmy dotknięte przypadki, wskaźniki operacyjne i błędy. Ten incydent został rozwiązany. Pośmiertna będzie dostępna jak tylko zostanie ukończona.

5. 16 października 2026 16:23 UTCpostmortem

   Co się stało W czwartek, 17 września 2026 r. o godz. 13: 52 UTC, konflikt czasu rozmieszczania między jednoczesnymi operacjami spowodował usunięcie funkcji kredytowej używanej przez główny komponent Aura w celu uwierzytelnienia infrastruktury obsługiwanej przez Azurea. Po wygaśnięciu istniejących żetonów uwierzytelniających, komponent zaczął zwracać błędy dla niektórych aura instancji na Azure, wpływając na niektóre operacje bazy danych. Namierzyliśmy błędy z brakującym kredytodawcą, stworzyliśmy nowy, przechowywaliśmy go bezpiecznie i wykonywaliśmy ciągłe rozmieszczanie dotkniętego komponentu, który zakończył się o 18: 39 UTC. Niewielka liczba wniosków o utworzenie bazy danych, które były w toku w czasie przerw, pozostawała w niekompletnym stanie i wymagała ręcznej naprawy. Zostało to zakończone o 19: 48 UTC, a zdarzenie zostało zakończone o 19: 55 UTC. # How the service was affected Wpływ był ograniczony do przypadków aury, które miały miejsce w Azure. Inni dostawcy chmur nie zostali dotknięci. * * * Operacje baz danych: * * Klienci nie byli w stanie wykonać pewnych operacji baz danych, takich jak tworzenie, usuwanie i klon, w niektórych przypadkach Azure podczas okna incydentu. Niewielka liczba stworzeń, które były w toku, utknęła i zostały odzyskane ręcznie. * * * Widoczność zarządzania: * * Niektóre przypadki w Azure- hostowane przez Azurea nie były tymczasowo widoczne ani możliwe do zarządzania w konsoli Aura. * * * Szczeliny metryczne: * * Punkty końcowe dla niektórych przypadków Azure zwróciły błędy okresowe, pozostawiając krótkie luki w danych pomiarowych dla danego okresu. Dane te nie zostaną uzupełnione. Przypadki Azure, które były już uruchomione pozostały dostępne i nadal obsługiwać obciążenia pracą normalnie. # What we are do now Podejmujemy następujące kroki, aby zapobiec nawrotom i poprawić naszą reakcję: * * * Wcześniejsze wykrycie i komunikacja: * * Poprawimy monitorowanie i ostrzeganie oraz oceniamy automatyczne kontrole wiarygodności, tak więc problemy są wykrywane i klienci są informowani wcześniej. * * * Odzysk z niekompletnej bazy danych: * * Naprawimy defekt, który może pozostawić tworzenie bazy danych zablokowane, jeśli połączenie infrastrukturalne zawiedzie częściowo, więc system odzyskuje się samodzielnie. * * * Autoryzacja: * * Dokonamy przeglądu sposobu uwierzytelniania tego komponentu przez dostawców chmur w celu usunięcia pojedynczych punktów awarii i zmniejszenia ryzyka powtarzającego się tego rodzaju konfliktu.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 16 września 2026 08:50 UTCidentified

   Nasz dostawca usług dla portalu wsparcia doświadcza pewnego przestoju - Zobacz https: / / status.sellerforce.com / products / Salesforce _ Services Jeśli masz problemy z dostarczeniem nowej sprawy wsparcia, wyślij e-mail na adres support @ neo4j.com

2. 16 września 2026 09:16 UTCidentified

   Nasz dostawca portalu wsparcia nadal pracuje nad rozwiązaniem problemu. Zob. szczegółowe informacje dotyczące https: / / status.sellerforce.com / invents / 20004433

3. 16 września 2026 10:11 UTCidentified

   Nasz dostawca portalu wsparcia nadal pracuje nad rozwiązaniem problemu. Zob. szczegółowe informacje dotyczące https: / / status.sellerforce.com / invents / 20004433

4. 16 września 2026 11:30 UTCmonitoring

   Usuwa się fix, a portal z czasem powinien mieć mniejszy wpływ na błędy. Zob. szczegółowe informacje https: / / status.sellerforce.com / invents / 20004433

5. 16 września 2026 12:29 UTCmonitoring

   Nasz dostawca portalu wsparcia nadal wprowadza rozwiązanie.

6. 16 września 2026 14:31 UTCresolved

   Zastosowano rozwiązanie i wszystkie funkcje należy odzyskać.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 9 września 2026 12:31 UTCinvestigating

   Obecnie badamy problem dotyczący konsoli Aura console.neo4j.io i API api.neo4j.io

2. 9 września 2026 12:54 UTCidentified

   Zidentyfikowaliśmy źródło problemu i obecnie pracujemy nad rozwiązaniem.

3. 9 września 2026 13:10 UTCidentified

   Nadal pracujemy nad rozwiązaniem tej kwestii.

4. 9 września 2026 13:26 UTCidentified

   Dokonaliśmy znacznych postępów i odzyskujemy problematyczny element.

5. 9 września 2026 13:36 UTCmonitoring

   Rozmieściliśmy namiar, a poszkodowane służby wracają do zdrowia.

6. 9 września 2026 13:39 UTCresolved

   Wszystkie komponenty zostały w pełni odzyskane.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 3 września 2026 16:43 UTCinvestigating

   Obecnie badamy tę kwestię.

2. 4 września 2026 10:23 UTCidentified

   Zidentyfikowano tę kwestię, nadal dostępne są instancje oraz podjęto kroki w celu rozstrzygnięcia kwestii, które mają wpływ na obecnie dokonywany przegląd.

3. 4 września 2026 15:36 UTCresolved

   Wszystkie instancje są dostępne, ręczne kroki w celu odblokowania pozostałych małych instancji zostały podjęte w celu rozwiązania.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 20 sierpnia 2026 15:49 UTCinvestigating

   Nasz zespół zidentyfikował problem z zbieraniem danych dla aury. To wpłynie na widoczność metryczną i przekazywanie. Obecnie badamy tę sprawę.

2. 20 sierpnia 2026 16:48 UTCinvestigating

   Kontynuujemy śledztwo w sprawie pomiaru aury.

3. 20 sierpnia 2026 19:10 UTCresolved

   Od ostatniej aktualizacji, śledztwo ruszyło dalej. Problem został zidentyfikowany, a my monitorowaliśmy służbę, gdy wyzdrowiała z degradacji. Potwierdzamy, że sprawa została rozwiązana.

4. 17 września 2026 10:09 UTCpostmortem

   Co się stało W czwartek, 20 sierpnia 2026 14: 58: 00 UTC, nasz rurociąg pomiarowy zaczął doświadczać zwiększonych niepowodzeń eksportowych podczas wysyłania danych do Google Managed Prometheus\ (GMP\). Podstawową przyczyną był incydent z usługą Google Cloud Platform w regionie "us- west1", który zakłócił ścieżkę eksportu wykorzystywaną przez naszą infrastrukturę zbierania danych. W rezultacie kolejki wywozu metrycznego zaczęły się gromadzić w podzbiorze środowisk produkcyjnych. Niepowodzenia ujawniły się przede wszystkim jako przerwy w sieci podczas próby dostarczenia danych metrycznych GMP, zapobiegając normalnemu spożyciu w przypadku dotkniętych klastrów. Nasz zespół inżynieryjny zidentyfikował koncentrację geograficzną systemów, w których występują: AWS 'us- west- 2', Google Cloud 'us- west1' i Azure 'westus2' - wszystkie trasy przez infrastrukturę w Oregonie. Po złagodzeniu przez Google incydentu regionalnego GCP, błędy eksportowe ustąpiły i kolejki zaczęły wysysać. # How the service was affected Wpływ był ograniczony do * * widzialności metrycznej * * dla podzbioru środowisk Aura. Wpłynęło na to około 45 środowisk klientów, co oznacza, że dane metryczne z baz danych nie były wchłonięte przez naszą platformę monitorującą w czasie zdarzenia. Najbardziej dotkniętym regionem były: AWS "us-west-2", z dodatkowym wpływem w Google Cloud "us-west1" i Azure "westus2". Klienci z bazami danych w tych regionach mogli doświadczyć luk w swoich tablicach rozdzielczych pomiaru i danych z monitoringu na czas trwania incydentu. Funkcjonowanie podstawowej bazy danych - w tym czytanie, pisanie i dostępność - nie miało wpływu na * *; tylko zbieranie i widoczność wskaźników wydajności zostało zakłócone. Po tym jak Google ograniczył kwestię regionalną, wznowiono spożycie danych metrycznych i dokonano przetwarzania zaległych danych w kolejce. # What we are do now Przeprowadziliśmy gruntowny przegląd tego incydentu i podejmujemy następujące kroki w celu poprawy naszych zdolności odporności i reagowania: * * * Ulepszone tablice obserwacyjne * *: Wzmacniamy nasze deski rozdzielcze eksportera metrycznego, aby zapewnić wyraźniejszą i szybszą widoczność w poziomie błędów zdrowotnych w kolejce i w eksporcie, umożliwiając szybsze wykrywanie i diagnozowanie podobnych problemów. * * * Poprawa agregacji ostrzeżeń * *: Wdrażamy automatyczne grupowanie ostrzeżeń, tak aby incydent regionalny dotykający wiele klastrów był lepiej ujawniony jako jedno skorelowane zdarzenie i traktowany z odpowiednią dotkliwością i uwagą. * * * Proaktywne powiadamianie o wskaźnikach błędu spożycia: * * Dodamy specjalne alarmy, że ogień na podwyższonym GMP poziom błędu połknięcia, dając naszemu zespołowi wcześniejszy sygnał, zanim eksporter kolejki osiągnąć pojemność. Ulepszenia te mają na celu skrócenie czasu wykrywania, uproszczenie procesu oceny incydentów oraz wzmocnienie naszego rurociągu metrycznego przed przyszłymi zakłóceniami dostawców na wcześniejszych etapach łańcucha dostaw.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 5 sierpnia 2026 17:31 UTCinvestigating

   We have identified an issue currently that could result in unexpected query failures when using the trim() Cypher function. Investigations into the cause are in progress.

2. 5 sierpnia 2026 19:27 UTCidentified

   We have found the issue and are working on a fix. A small percentatge of queries using trim may still err. VDC customers with databases set to highest are not impacted at all unless they pause and start their instances.

3. 6 sierpnia 2026 00:58 UTCidentified

   We are testing the fix for the trim() Cypher function issue. We will update before we begin our deployment into the Aura environment.

4. 6 sierpnia 2026 07:13 UTCidentified

   We are actively validating the fix for the trim() Cypher function. Further updates will be provided before we begin deploying to Aura instances

5. 6 sierpnia 2026 11:17 UTCidentified

   We continue to validate the fix for the trim() Cypher function. Further updates will be provided before we begin deploying it to Aura instances.

6. 6 sierpnia 2026 14:54 UTCidentified

   The fix for the trim() Cypher function is undergoing testing and validation before deployment. Further updates will be provided before we begin deploying it to Aura instances.

7. 7 sierpnia 2026 01:15 UTCidentified

   Development has completed on the hot-fix for this issue, and we are finalizing the rollout plan for Aura.

8. 7 sierpnia 2026 01:16 UTCidentified

   We are actively working on addressing the issue. The fix for the trim() Cypher function is undergoing testing and validation currently before deployment. Further updates will be provided before we begin deploying it to Aura instances.

9. 7 sierpnia 2026 09:44 UTCidentified

   The fix to the trim() Cypher function has passed testing and validation and is now being deployed.

10. 7 sierpnia 2026 13:49 UTCmonitoring

    The fix to resolve the issue has now completed deployment to the Aura service and we are monitoring the situation.

11. 7 sierpnia 2026 15:34 UTCresolved

    We have monitored the fix and found the service to be stable. This incident is now considered resolved.

1. 23 lipca 2026 10:52 UTCinvestigating

   Obecnie prowadzimy dochodzenie w tej sprawie.

2. 23 lipca 2026 11:08 UTCinvestigating

   Współpracujemy z zespołami inżynieryjnymi i czynimy postępy w śledztwach.

3. 23 lipca 2026 11:24 UTCinvestigating

   Współpracujemy z zespołami inżynieryjnymi i kontynuujemy postępy w śledztwach.

4. 23 lipca 2026 11:38 UTCidentified

   Zidentyfikowaliśmy przyczynę obecnego problemu i aktywnie pracujemy nad jego naprawą.

5. 23 lipca 2026 11:53 UTCidentified

   Wprowadzamy pierwszą część fix i nadal aktywnie pracujemy nad opracowaniem pełnego rozwiązania. Oczekujemy ETA za 1 godzinę.

6. 23 lipca 2026 12:11 UTCidentified

   Zidentyfikowaliśmy podzbiór przypadków, które miały wpływ i w tym momencie nadal wdrażamy rozwiązanie.

7. 23 lipca 2026 12:32 UTCidentified

   Uruchomiliśmy konfigurację i pracujemy teraz nad rozwiązaniem podzbioru przypadków, które miały wpływ.

8. 23 lipca 2026 12:49 UTCidentified

   Po uruchomieniu konfiguracji, kontynuujemy rozwiązywanie podzbioru instancji, które nadal mają wpływ.

9. 23 lipca 2026 14:07 UTCidentified

   Nadal rozwiązujemy podzbiór spraw, które nadal mają wpływ.

10. 23 lipca 2026 14:27 UTCidentified

    Nadal rozwiązujemy podzbiór spraw, które nadal mają wpływ.

11. 23 lipca 2026 14:44 UTCmonitoring

    Nadal rozwiązujemy podzbiór spraw, które nadal mają wpływ.

12. 23 lipca 2026 15:03 UTCmonitoring

    AuraDB Wirtualna dedykowana chmura i AuraDB Biznes Critical powinny być teraz naprawione. Nadal rozwiązujemy podzbiór spraw, które nadal mają wpływ na AuraDB Professional and Free.

13. 23 lipca 2026 15:29 UTCmonitoring

    Nadal rozwiązujemy podzbiór spraw, które nadal mają wpływ na AuraDB Professional and Free.

14. 23 lipca 2026 15:57 UTCmonitoring

    Nadal rozwiązujemy podzbiór spraw, które nadal mają wpływ na AuraDB Professional and Free.

15. 23 lipca 2026 16:32 UTCmonitoring

    Nadal rozwiązujemy podzbiór spraw, które nadal mają wpływ na AuraDB Professional and Free

16. 23 lipca 2026 17:01 UTCmonitoring

    Nadal naprawiamy podzbiór przypadków, które nadal mają wpływ na AuraDB Professional and Free

17. 23 lipca 2026 17:31 UTCmonitoring

    Nadal naprawiamy mały podzbiór przypadków, które nadal mają wpływ na poziomy zawodowe i wolne.

18. 23 lipca 2026 18:07 UTCmonitoring

    Zajęliśmy się tą kwestią we wszystkich instancjach AuraDB Professional. Aura Free może mieć wpływ. Będziemy nadal monitorować i naprawiać pozostałe bazy danych.

19. 23 lipca 2026 19:39 UTCmonitoring

    Nadal naprawiamy mały podzbiór wolnych instancji, które nadal mają wpływ.

20. 24 lipca 2026 06:00 UTCmonitoring

    Nadal uważnie monitorujemy sytuację w odniesieniu do dalszych kwestii.

21. 24 lipca 2026 08:30 UTCmonitoring

    Nadal monitorujemy wszelkie dalsze problemy.

22. 24 lipca 2026 12:59 UTCmonitoring

    Wszystkie zidentyfikowane przypadki zostały naprawione. Skontaktuj się z obsługą klienta w razie dalszych problemów.

23. 24 lipca 2026 15:56 UTCresolved

    Wszystkie poprawki zostały wprowadzone i problem jest teraz oznaczony jako rozwiązany.

24. 29 lipca 2026 21:58 UTCpostmortem

    - Co się stało? W czwartek, 23 lipca 2026 10: 33 UTC wprowadzono zmianę konfiguracji do Aury, która nieumyślnie zmieniła sposób obliczania przydziałów pamięci dla instancji baz danych. W rezultacie podzbiór instancji otrzymał niewystarczającą pamięć, co spowodowało, że niektóre instancje bazy danych stały się niedostępne lub nie mogły zakończyć aktualizacji. Dostosowana alokacja pamięci doprowadziła do braku pamięci, powodując wielokrotne ponowne uruchomienie instancji baz danych z powodu niewystarczających zasobów pamięci lub utknięcie w aktualizacji. Kwestia ta dotyczyła instancji wielu dostawców chmur i wielu poziomów produktu. Po zidentyfikowaniu problemu natychmiast cofnęliśmy zmianę konfiguracji, uniemożliwiając dodatkowe przypadki otrzymywania nieprawidłowej konfiguracji. Skorygowana konfiguracja została wprowadzona do produkcji w czwartek, 23 lipca 2026 11: 56 UTC. Jednakże przypadki w bazie danych, które otrzymały już nieprawidłową konfigurację, wymagały indywidualnych działań naprawczych, zanim mogły powrócić do normalnej eksploatacji. Do czwartku 23 lipca 2026 17: 59 UTC, wszystkie znane instancje bazy danych wpływające na klienta zostały odzyskane. Monitoring trwał przez kolejny dzień, a incydent został w pełni rozwiązany w piątek, 24 lipca 2026 16: 30 UTC. * * * How the service was affected * * Głównym skutkiem dla klientów było to, że kilka przypadków w bazie danych AuraDB stało się niedostępne lub weszło w stan degradacji. Dotknięte przypadki nie były w stanie zakończyć rutynowych aktualizacji oprogramowania, a w niektórych przypadkach, wielokrotnie wznowione, ponieważ niewystarczająca pamięć została przydzielona. * * * Dostępność usługi: * * Wpływ klienta zróżnicowany według poziomu usług. AuraDB Profesjonalne instancje, które nie zapewniają wysokiej dostępności, doświadczyły największego poziomu zakłóceń usług, z podzbiór staje się niedostępny i nie może przetwarzać czytanie lub pisanie. W przypadku dotkniętych przez AuraDB przypadków krytycznych dla działalności gospodarczej i wirtualnej, dedykowanej chmurze\ (VDC\), wpływ był na ogół ograniczony do tymczasowej utraty tolerancji błędów podczas utrzymywania dostępności usług. W mniejszej liczbie przypadków, instancje Business Critical i VDC stały się również niedostępne. * * * Stuck updates * *: Dodatkowe przypadki pozostały dostępne, ale utknęły w stanie "updating", który zablokował operacje inicjowane przez klienta, takie jak rezyzecje lub zmiany konfiguracji. * * * Zakres Cross- platform * *: Wpływ obejmował wszystkich trzech wspieranych dostawców chmur i wiele regionów, dotykając klientów na całym świecie. Podniesiono sprawy wsparcia klienta, a nasz zespół testował i ręcznie odzyskiwał poszkodowane przypadki w kolejności priorytetowej. Większość instancji AuraDB nadal funkcjonowała normalnie. Wpływ na klienta został w pełni złagodzony dzięki przywróceniu konfiguracji i ukierunkowanemu ręcznemu odzyskaniu każdej dotkniętej instancji. * * * What we are doing now * * Przeprowadziliśmy dokładną analizę tego incydentu i zidentyfikowaliśmy następujące działania: * * * Zapobieganie * * * * * Poprawa walidacji rozmieszczenia: * * Wzmacniamy proces zatwierdzania wydania, aby lepiej zidentyfikować zmiany konfiguracji. * * * Odłączenie od produkcji części * *: Omawiamy ulepszenia w sekwencjonowaniu rozmieszczenia komponentów w celu zmniejszenia ryzyka niezamierzonych zmian w wydaniach. * * * Progressive rollout strategy * *: Przeglądamy proces wprowadzania na rynek dla składników, które zostały dotknięte, aby dostosować je do kontroli wprowadzania na rynek stosowanych do innych składników krytycznych. * * * Detection * * * * * Better alerting * * Wzmacniamy nasze monitorowanie, aby wykryć nieprawidłowy wzrost liczby awarii\ (takich jak utrata tolerancji błędów lub dostępność\) szybciej i niezawodniej. * * * Litigation * * * * * Bezpieczniejsze wdrażanie konfiguracji: * * Poprawiamy sposób wprowadzania zmian w konfiguracji produkcji, aby można je było wyłączyć lub szybciej zwinąć bez konieczności szerszego udostępniania oprogramowania. * * * Szybsze ręczne oprzyrządowanie do odzyskiwania * *: Poprawiamy nasze oprzyrządowanie do odzyskiwania, aby skrócić czas potrzebny do identyfikacji i ręcznego odzyskiwania poszkodowanych przypadków. Zdajemy sobie sprawę z zakłóceń wywołanych przez ten incydent i przepraszamy za wpływ na klientów. Zakończyliśmy natychmiastowe działania naprawcze, a opisane powyżej długoterminowe ulepszenia są już w toku, aby zmniejszyć prawdopodobieństwo i wpływ podobnych incydentów w przyszłości.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 10 lipca 2026 17:18 UTCinvestigating

   Obecnie badamy problem dotykający konsoli Aura, gdzie niektórzy klienci mogą nie być w stanie zobaczyć swoich instancji. Ta kwestia jest spowodowana porażką w usłudze trzeciej partii, od której zależy Aura. Dotknięte przypadki nadal działają normalnie, a łączność z bazą danych nie ma wpływu. Nasz zespół aktywnie bada sprawę.

2. 10 lipca 2026 17:23 UTCinvestigating

   Nadal badamy tę kwestię.

3. 10 lipca 2026 17:51 UTCmonitoring

   Usługa trzeciej partii, od której zależy Aura, przywróciła normalne operacje i systemy Neo4j Aura odzyskały moc. Nasz zespół aktywnie monitoruje sprawę, aby potwierdzić, że Aura Console działa zgodnie z oczekiwaniami.

4. 10 lipca 2026 19:23 UTCresolved

   Potwierdzono, że usługi są operacyjne i nie oczekuje się dalszych przerw.

5. 27 lipca 2026 04:28 UTCpostmortem

   # Co się stało Aura Console i inne komponenty Aura doświadczyły zakłóceń na 2026- 07- 10 o 16: 14 UTC, powodując awarie i pętle. W związku z tym segment klientów miał problemy z widocznością w swoich przypadkach. Został on spowodowany brakiem dostępu do zewnętrznej usługi trzeciej partii zintegrowanej z Aurą. Zasadnicze znaczenie ma to, że łączność z bazą danych pozostaje niezakłócona, a dotknięte nią przypadki kontynuowały swoje normalne działania. Usługa LaunchDarkly została przywrócona, aby rozwiązać problem # # How the service was affected Wiele komponentów Aura, w tym konsola Aura, doświadczyło zakłóceń. Użytkownicy napotkali błędy HTTP 500 na stronach i operacjach związanych z bazą danych, chociaż nadal można było uzyskać dostęp do organizacji i projektów. Bezpośrednie połączenia z konkretnymi instancjami baz danych nie zostały całkowicie naruszone Płaszczyzna kontrolna stała się niedostępna, co oznaczało, że użytkownicy nie mogli tworzyć, usuwać, zmieniać rozmiaru ani regulować ustawień dla instancji za pośrednictwem API lub konsoli Aura. Istniejące przypadki nadal jednak funkcjonowały. Problem ten został spowodowany brakiem dostępu do LaunchDarkly, a nasze służby nie poradziły sobie z tą wadą zależności z gracją podczas startu. Wszystkie uszkodzone systemy wróciły do normalnego działania do 2026- 07- 10 o 17: 07 UTC Co teraz robimy? Zespół Neo4j Engineering szybko rozpoznał przyczynę i przywrócony usługi. Oceniając ten incydent, zidentyfikowaliśmy kluczowe obszary, aby przyspieszyć przyszłe rezolucje i zmniejszyć ryzyko ponownego wystąpienia: * Analizowane kluczowe wskaźniki incydentów, koncentrujące się na czasie trwania alarmowania o reakcji w celu określenia możliwości przyspieszenia skuteczności reakcji * Przeprowadził kompleksową retrospektywną prezentację udanych wyników, w tym szybkiej analizy przyczyn root- poprzez przezroczyste wycinki, bezproblemowe dopasowanie za pomocą narzędzia zarządzania incydentami, a także odporną, pełną gracji degradację wielu komponentów, które utrzymały łączność z płaszczyzną danych nienaruszone * Aktywnie rozwijając bardziej gratiful fallback domyślnie dla flag funkcji w celu zabezpieczenia podstawowych operacji w czasie przestojów sprzedawcy * Wzmocnienie odporności architektonicznej poprzez zintegrowanie zaawansowanego planowania, praktyk inżynieryjnych w zakresie chaosu oraz testowania błędów na poziomie produkcyjnym, aby prewencyjnie odkryć i złagodzić potencjalne ścieżki awarii * Dostosowane ograniczenia logiczne w buforowaniu flag operatora, podkreślając konieczność przechowywania przez operatorów ocenionych flag lokalnie w celu zachowania ciągłości działania w przypadku awarii zewnętrznych zależności.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 30 czerwca 2026 14:45 UTCidentified

   Uruchomienie CREATE VECTOR INDEX nie powiodło się z błędem 51N31 błąd: konfiguracja systemu lub wyjątek operacyjny - nie jest obsługiwany. Tworzenie indeksu wektorowego z podanymi ustawieniami nie jest obsługiwane w V2026 _ 02. Wymaganą wersją do pracy jest V2026 _ 06. Proszę uaktualnić DBMS.. Dotyczy to jedynie nowego indeksu, istniejący VECTOR INDEX pozostaje bez zmian. Każdy indeks wektorowy utworzony przed 2026- 06- 30 o 09: 00 nadal działa normalnie.

2. 30 czerwca 2026 15:41 UTCidentified

   Rozpoczynamy prace nad ustaleniem rozwiązania tej kwestii i wkrótce przedstawimy aktualizację postępów.

3. 30 czerwca 2026 16:05 UTCmonitoring

   Naprawa idzie w dobrym kierunku. Będziemy aktualizować z postępem.

4. 30 czerwca 2026 17:45 UTCresolved

   Naprawa została w pełni wdrożona we wszystkich przypadkach. Ten incydent został rozwiązany.

5. 20 lipca 2026 08:40 UTCpostmortem

   # Co się stało Problem został zidentyfikowany po wdrożeniu wersji 2026.06 w 2026- 06- 30 o godzinie 08: 00 UTC, gdzie uruchomienie "CREATE VECTOR INDEX" w zmodernizowanych instancjach aury wywołało wyjątek systemowy. Ta awaria w generowaniu indeksu nastąpiła, ponieważ podstawowy magazyn i jądro wymagały dodatkowych aktualizacji, aby wesprzeć operację Problem ten tylko wpłynął na tworzenie nowych indeksów; istniejące indeksy wektorowe nie są naruszone. Każdy indeks wektorowy utworzony przed 09: 00 na 2026- 06- 30 nie uległ zmianie i nadal działał normalnie. # # How the service was affected Po uruchomieniu wersji 2026.06, wykonanie instrukcji CREATE VECTOR INDEX nie powiodło się, wpływając na aplikacje, które zależały od dodania nowych indeksów wektorowych. Dotknięci klienci otrzymali błąd: _ Tworzenie indeksu wektorowego z podanymi ustawieniami nie jest obsługiwane w V2026\ _ 02. Wymaganą wersją obsługi jest V2026\ _ 06. Proszę uaktualnić DBMS _. Istniejące indeksy\ (utworzone przed tym incydentem\) i inne zapytania pozostały niezmienione i w pełni funkcjonalne. Co teraz robimy? Zespoły Neo4j zidentyfikowały przyczynę początkową jako błąd w planowaniu szyfru i rozwiązały problem za pomocą poprawki kodu. Ten fix został zastosowany do wszystkich przypadków Aura dotkniętych, w pełni rozwiązać błąd Aby zapobiec przyszłym zdarzeniom, udoskonalamy nasze systemy monitorowania i ostrzegania w celu wykrycia podobnych problemów wcześniej, szczególnie w środowiskach inscenizacji, zanim pojawią się wyjazdy. Równocześnie udoskonalamy nasze procesy wdrożeniowe, aby zminimalizować wpływ klientów i czas odzyskiwania Dodatkowo, badamy opcje wdrożenia zautomatyzowanych testów walidacji po aktualizacji specjalnie dla operacji krytycznych, takich jak tworzenie indeksu wektorowego

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 23 czerwca 2026 11:25 UTCidentified

   Konsola Aura doświadcza chwilowych błędów: "Nasz system doświadcza teraz problemów. spróbuj ponownie później lub skontaktuj się ze wsparciem, jeśli problem utrzymuje się". Może to wymagać przeładowania lub dłużej czekać na nawigację w konsoli Operacje i API Aury pozostają nienaruszone Aktywnie pracujemy nad naprawą

2. 23 czerwca 2026 13:03 UTCidentified

   Kontynuujemy śledztwo w tej sprawie

3. 23 czerwca 2026 13:39 UTCidentified

   Kontynuujemy prace nad rozwiązaniem tego problemu.

4. 23 czerwca 2026 15:43 UTCmonitoring

   Wprowadzamy zmiany. Będziemy monitorować i aktualizować.

5. 23 czerwca 2026 19:27 UTCmonitoring

   Kontynuowanie monitorowania wprowadzonych zmian. Następna aktualizacja spodziewana 6 / 24 / 2026 10am UTC.

6. 24 czerwca 2026 09:14 UTCmonitoring

   Sprawdziliśmy i potwierdziliśmy, że problem jest teraz w pełni rozwiązany.

7. 24 czerwca 2026 09:14 UTCresolved

   Ten incydent został rozwiązany.

8. 10 lipca 2026 14:50 UTCpostmortem

   # Co się stało Około godziny 12: 00 UTC 22 stycznia 2026 roku, użytkownicy napotkali przerywane banery błędów w konsoli Aura wyświetlanie, "Mamy problem. Spróbuj jeszcze raz"., który wystąpił obok 500 błędów z konsoli API punktów końcowych. Zakłócenia te były przemijające i spowodowane przez wewnętrzny czas API w trakcie procesu uścisku dłoni TLS, zazwyczaj ustępujące w ciągu około 10 sekund lub po odświeżeniu strony # # How the service was affected Aura Console i Aura API doświadczyły zdegradowanego działania, które przejawiało się jako przerywane banery błędów w konsoli Aura UI. Śledztwo zidentyfikowało przyczynę jako wysokie wykorzystanie procesora i przepustowość w konsoli API. Kwestia ta była przede wszystkim spowodowana powtarzającymi się listami dużych podmiotów i kosztownymi wnioskami o pogodzenie Aby rozwiązać ten problem, ukierunkowane poprawki zostały pomyślnie wdrożone zarówno do konsoli Aura i API Aura. Następnie dokonano dostosowań w konfiguracji zasobów w celu zwiększenia operacyjnej zagłówka i zapewnienia stabilności Co teraz robimy? W celu zmniejszenia prawdopodobieństwa wystąpienia podobnych incydentów wprowadzono następujące środki reaktywne i proaktywne: * Opracował monitoring deski rozdzielczej do obserwacji spadku prośby na podstawie wewnętrznych danych dziennika API do wdrożenia zautomatyzowanego monitorowania i ostrzegania do problemów połowów, zanim wystąpią * Wdrożenie rozłożone opóźnienie między postronnym pojednawcy wnioski o ograniczenie wysokiego zużycia zasobów i poprawę stabilności API * Ulepszone obliczenia zasobów wiedzy infrastrukturalnej w celu poprawy wydajności * Wprowadzono nowy filtr dla zapytań opartych na poziomach usług w celu optymalizacji napowietrznych procesora dla każdego połączenia wykonanego przez konwelatora * Dezaktywowany zbędny wniosek przetwarzania middleware w celu optymalizacji połączeń API

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 26 maja 2026 18:23 UTCinvestigating

   Aura Console is currently not accessible. Our team is investigating the issue. Aura instances are running normally and are not impacted. They remain accessible via https://browser.neo4j.io/ and https://bloom.neo4j.io/ Console-related administration and configuration procedures may be unavailable. We will provide updates as soon as more information is available.

2. 26 maja 2026 19:19 UTCmonitoring

   The Aura Console issue has now been resolved. The root cause was a failure while fetching public certificates from Auth0. We are reaching out to the Auth0 team to gather more detailed information about the incident.

3. 26 maja 2026 23:06 UTCresolved

   This incident has been resolved.

4. 9 czerwca 2026 16:50 UTCpostmortem

   **What Happened** During the incident window, users attempting to log in to the Aura Console were unable to do so. Auth0, the authentication provider for Aura Console, experienced an issue that prevented new authentication requests from completing. Existing sessions with valid cached tokens were largely unaffected. Aura database instances were running normally throughout and were not impacted, and access via the Aura API to database instances was also unaffected. **How the service was affected** Authentication requests from the Aura Console to Auth0 began failing, preventing new logins and session refreshes. Affected users received 503 errors when accessing the Aura Console. Once Auth0 recovered, access was restored. **What are we doing now** We've made two changes as a result of this incident: * Client identification: Authentication requests now include a clearer client identifier, reducing the chance of requests being incorrectly blocked in the future. * Observability: We've improved logging and alerting for authentication failures, including better visibility into errors from external services,so we can detect and escalate issues like this faster.

1. 6 marca 2026 10:18 UTCidentified

   We identified an issue with the availability of console.neo4j.io - we are investigating

2. 6 marca 2026 10:24 UTCmonitoring

   We have made a code change and we believe the console is available again.

3. 6 marca 2026 10:25 UTCresolved

   We have checked and confirm that the issue is now fully addressed.

4. 30 marca 2026 07:25 UTCpostmortem

   ## What Happened On March 6, at 10:04 AM UTC,  the Aura Console became inaccessible following a recent deployment. The deployment included changes related to user organizations and switching to an org memberships entity. This change caused the console to become inaccessible for a short period. ## How the service was affected A deployment to the Aura Console introduced an issue that caused an unexpected increase in backend requests related to access validation. This led to elevated CPU usage, which impacted the availability of the console and dependent services. We rolled back to a previous version to restore access. The rollback ensured the full restoration of access to the Aura Console, resolving the core issue within the incident window ## What are we doing now We are currently implementing a comprehensive strategy to bolster system resilience and prevent future recurrence. Our immediate actions include integrating stricter and more robust safeguards into the deployment pipeline. Crucially, we are significantly enhancing our validation processes to proactively detect and flag any potential performance impacts _before_ code is promoted to the production environment

1. 3 marca 2026 21:35 UTCidentified

   A recent update resulted in MERGE queries which referenced the same merged property on both the left and right hand side of an ON MATCH SET or ON CREATE SET clause deleting that property from the node, or setting it to an invalid value during query runtime. The node being matched against must have had at least one property uniqueness constraint present. A fix has been identified and will be applied as soon as possible. Instances marked as "Production" are not impacted.

2. 4 marca 2026 01:39 UTCidentified

   The fix is being deployed and the status page will be updated upon completion of the full deployment of the fix.

3. 4 marca 2026 04:52 UTCidentified

   The fix is being deployed and the status page will be updated upon completion of the full deployment

4. 4 marca 2026 14:07 UTCmonitoring

   The fix has now been deployed to those instances impacted and we are monitoring the situation.

5. 4 marca 2026 15:19 UTCresolved

   The fix has been fully deployed to all impacted instances. This incident is now resolved.

6. 8 kwietnia 2026 06:39 UTCpostmortem

   ## What Happened An issue was introduced in the Neo4j 2026.02 release where MERGE queries that referenced the same property on both the left and right sides of an `ON MATCH SET` or `ON CREATE SET` clause could potentially delete that property from the node or set it to an invalid value during query execution. This behaviour was observed specifically when the node being matched had at least one property uniqueness constraint. ## How the service was affected A change in the Neo4j 2026.02 release introduced a potential risk of writes failing or invalid data being returned for queries using MERGE together with `ON MATCH`. This issue affected instances across Aura tiers and required immediate investigation by Neo4j Engineering. The team identified the root cause and deployed a fix in version 2026.02.1. ## What are we doing now The following proactive measures have been implemented to reduce the likelihood of similar incidents: * We have strengthened test coverage for `ON CREATE` and `ON MATCH` clauses, particularly those involving more complex expressions. * We are investigating additional safeguards to improve our ability to control MergeInto/MergeUnique behaviour more flexibly, as well as potential rollback capabilities to support recovery in future incidents

1. 2 marca 2026 19:55 UTCidentified

   We are aware of issues in the Middle East regions via our cloud partner AWS, affecting AWS me-central-1 (United Arab Emirates) and AWS me-south-1 (Bahrain). The most up-to-date information from AWS is available at: https://health.aws.amazon.com/health/status We are actively working to limit the impact on the Aura service. However, customers should expect that new deployments in the affected regions may be impaired. Additionally, existing services deployed in these regions may experience reduced availability. Customers with services in these or nearby regions who are concerned about potential operational impact are encouraged to contact Neo4j Customer Support through the usual channels. Our team is available to advise and assist as needed.

2. 3 marca 2026 15:26 UTCidentified

   We continue to monitor the situation in the affected AWS Middle East regions. The most up-to-date information from AWS is available at: https://health.aws.amazon.com/health/status We will provide additional updates as soon as more information becomes available.

3. 6 marca 2026 14:29 UTCidentified

   We continue to monitor the situation in the affected AWS Middle East regions. The latest information from AWS is available at: https://health.aws.amazon.com/health/status We will provide additional updates as more information becomes available. Please review the AWS recommendation on the website above.

4. 6 marca 2026 16:06 UTCresolved

   While AWS continues working on this situation, we are closing this incident and invite our customers to monitor the AWS Status on our main Neo4j Status Page under AWS (Amazon Web Services). The latest information from AWS can be found at: https://health.aws.amazon.com/health/status

5. 29 marca 2026 15:16 UTCpostmortem

   ## What Happened On March 1, at 12:51 PM UTC, AWS services in the ME-CENTRAL-1 & ME-SOUTH-1 Region were impacted. Connectivity and power issues affected APIs and AWS core services essential to run Neo4j Aura prompting AWS to initiate an investigation ## How the service was affected Operations \(clone, backup, resuming/pausing, resizing\) that require additional resources like EC2 Instances, EBS Volumes, and other resources were impaired in the ME-CENTRAL-1 and ME-SOUTH-1 Region. Other AWS Services also experienced error rates and latencies for some workflows. Due to the ongoing conflict in the Middle East, both affected regions have experienced physical impacts to infrastructure. A detailed summary of the AWS regional incident can be found here:[ https://health.aws.amazon.com/health/status](https://health.aws.amazon.com/health/status) ## What are we doing now We are actively working to limit the impact on the Neo4j Aura service. However, customers should expect that new deployments in the affected regions may be impaired. Additionally, existing services deployed in these regions may experience reduced availability. Customers with services in these or nearby regions who are concerned about potential operational impact are encouraged to contact Neo4j Customer Support through the usual channels Please visit AWS Status page for more info:[https://health.aws.amazon.com/health/status](https://health.aws.amazon.com/health/status)