История сбоев Neo4j Aura

1. 26 октября 2026 г. в 14:50 UTCinvestigating

   В настоящее время мы знаем о проблеме, которая влияет на клиентов, использующих Aura на Azure, при попытке загрузить снимки экземпляров базы данных.

2. 26 октября 2026 г. в 15:09 UTCidentified

   Мы определили проблему и в настоящее время работаем над развертыванием исправления.

3. 26 октября 2026 г. в 16:22 UTCidentified

   В настоящее время исправление тестируется в более низких средах перед развертыванием.

4. 26 октября 2026 г. в 17:43 UTCidentified

   Тестирование исправления продолжается, и развертывание начнется после завершения тестирования.

5. 26 октября 2026 г. в 19:14 UTCresolved

   Наши инженеры успешно внедрили исправление, и теперь вопрос решен. Клиенты Aura на Azure теперь могут без проблем загружать снимки базы данных.

Автоматический перевод официального обновления инцидента.

1. 20 октября 2026 г. в 07:35 UTCinvestigating

   В настоящее время мы расследуем проблему, затрагивающую регион Европа-Запад 2 в рамках GCP, которая затрагивает некоторые операции, включая создание экземпляров баз данных в регионе.

2. 20 октября 2026 г. в 08:36 UTCinvestigating

   В настоящее время мы продолжаем расследование этого вопроса, работая с ГКП над поиском решения. В настоящее время некоторые операции, включая создание экземпляров баз данных в регионе, по-прежнему остаются затронутыми.

3. 20 октября 2026 г. в 09:15 UTCidentified

   Мы определили источник проблемы, которая в настоящее время затрагивает клиентов на Europe-west2 на GCP. Более подробная информация доступна на странице статуса GCP по адресу https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj. В настоящее время некоторые операции, включая создание экземпляров баз данных в регионе, по-прежнему остаются затронутыми.

4. 20 октября 2026 г. в 10:42 UTCidentified

   В настоящее время мы осуществляем меры по исправлению положения в целях смягчения этой проблемы. Следите за последними из GCP на странице статуса по адресу https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj.

5. 20 октября 2026 г. в 12:38 UTCmonitoring

   Функциональность должна быть восстановлена во всех службах Aura. Мы будем внимательно следить за ситуацией, прежде чем рассматривать это решение.

6. 20 октября 2026 г. в 14:06 UTCmonitoring

   Мы продолжаем следить за ситуацией с GCP в настоящее время, и на данный момент мы не видим никаких новых проблем.

7. 20 октября 2026 г. в 14:50 UTCresolved

   Этот инцидент был урегулирован

Автоматический перевод официального обновления инцидента.

1. 13 октября 2026 г. в 09:15 UTCinvestigating

   Мы изучаем проблему, влияющую на показатели в консоли ауры и через конечную точку метрики.

2. 13 октября 2026 г. в 10:13 UTCidentified

   Мы определили, что проблема, связанная с поставщиком облачных услуг, влияет на текущую ситуацию. Мы открыли дело поддержки с поставщиком облачных услуг и обновим его после получения более подробной информации.

3. 13 октября 2026 г. в 11:01 UTCmonitoring

   Мы считаем, что проблема провайдера облачных услуг решена, поскольку мы больше не видим проблем из наших внутренних систем. Мы продолжим следить за ситуацией, пока ждем подтверждения от поставщика облачных услуг.

4. 13 октября 2026 г. в 12:08 UTCresolved

   Мы получили подтверждение от поставщика облачных услуг, что проблема полностью решена.

5. 16 октября 2026 г. в 17:06 UTCpostmortem

   ** Ошибки при отправке метрик из GCP Europe-west1** Что случилось (What Happened) Во вторник 13 октября 2026 года в 08:54 UTC метрики, например, в GCP Europe-west1, перестали поставляться и не могли быть прочитаны. Причиной стала проблема со стороны Google Cloud, где сокращение пропускной способности сервиса мониторинга привело к неправильному отклонению действительных запросов. Метрики вернулись к норме в 10:49 UTC после того, как Google Cloud применил исправление, и мы разрешили инцидент в 12:08 UTC, как только Google Cloud подтвердил полное разрешение. Случаи оставались доступными на протяжении всего этого события, без влияния на производительность запроса или целостность данных. Пострадала только видимость метрик. ** Как была затронута услуга** Клиенты увидели некоторые короткие пробелы в показателях экземпляров: ** Консольная метрика: ** Случаи в GCP europe-west1, возможно, показали неполные или отсутствующие метрические данные во время окна инцидента. ***Интеграция облачного мониторинга (CMI):** Метрики, отправленные в ваши собственные системы мониторинга из этого региона, также могут иметь пробелы. Не все случаи в регионе были затронуты, а другие облачные провайдеры и регионы не пострадали. Метрики, полученные во время инцидента, не были зарегистрированы, поэтому разрыв останется в исторических картах для пострадавших случаев. Что мы делаем сейчас** Решение пришло из Google Cloud по этому поводу, но наш конвейер метрик опирался на путь одного региона, поэтому мы предпринимаем шаги для снижения этого воздействия. **Региональная устойчивость:** Мы оцениваем маршрутизацию между регионами, чтобы метрики трафика могли выйти из строя в здоровом регионе. *** Маршрутизация движения:** Мы изучаем варианты в нашем облачном сетевом слое, чтобы перенаправить оба чтения \(Консоль и CMI\) и пишет \(предложение\) вдали от затронутой области

Автоматический перевод официального обновления инцидента.

1. 8 октября 2026 г. в 14:58 UTCinvestigating

   Мы изучаем проблему с метриками в Консоли Ауры и через конечную точку метрики.

2. 8 октября 2026 г. в 15:36 UTCidentified

   Мы продолжаем исследовать первопричину. Проблема ограничивается клиентами на us-central1 на GCP. Случаи ауры работают, и никакая операция не затрагивается.

3. 8 октября 2026 г. в 16:30 UTCidentified

   Мы работаем с поставщиком облачных услуг, чтобы выяснить природу проблемы. Наши проверки подтверждают, что затронуто только подмножество клиентов, работающих в регионах US-central1.

4. 8 октября 2026 г. в 18:41 UTCidentified

   Мы продолжаем работать с поставщиком облачных услуг, чтобы найти решение.

5. 8 октября 2026 г. в 19:11 UTCresolved

   Этот инцидент уже решен, метрики теперь должны работать как обычно.

6. 16 октября 2026 г. в 17:04 UTCpostmortem

   ** Ошибки при отправке метрик из GCP us-central1** Что случилось (What Happened) В четверг, 8 октября 2026 года в 14:05 UTC, метрики из некоторых экземпляров в GCP us-central1 перестали поставляться. Причиной стала проблема со стороны Google Cloud, которая неправильно отклонила действительные метрические запросы. Доставка метрики возобновилась в 18:00 UTC после того, как Google Cloud применил исправление, и мы разрешили инцидент в 18:48 UTC. Случаи оставались доступными на протяжении всего этого события, без влияния на производительность запроса или целостность данных. Временно была затронута только видимость метрик. ** Как была затронута услуга** Клиенты увидели пробелы в показателях: ** Консольная метрика: ** Случаи в GCP us-central1 могут показывать неполные или отсутствующие метрические данные во время окна инцидента. ***Интеграция облачного мониторинга (CMI):** Метрики, отправленные в ваши собственные системы мониторинга из этого региона, также могут иметь пробелы. Не все случаи в регионе были затронуты, а другие облачные провайдеры и регионы не пострадали. Что мы делаем сейчас** Решение пришло из Google Cloud, но мы предпринимаем шаги, чтобы быстрее поймать и отреагировать на подобные события. *** Погрешность в метрической доставке: ** Мы добавляем оповещения об ошибках метрической пересылки, поэтому сбои на стороне провайдера обнаруживаются раньше и отличаются от обычных пробелов. **Продолжение мониторинга:** Мы будем продолжать следить за регионом с помощью Google Cloud для любого повторения

Автоматический перевод официального обновления инцидента.

1. 6 октября 2026 г. в 09:22 UTCinvestigating

   Мы расследуем проблему, когда, несмотря на успешное завершение резервных копий, загрузка снимков возвращает пустые свалки. Восстановление от снимка через консоль Aura или API, как полагают, не затрагивается, и мы проверяем это сейчас. Мы поделимся обновлениями, как только у нас будет больше информации.

2. 6 октября 2026 г. в 10:43 UTCinvestigating

   Мы продолжаем расследование этого вопроса. Операции по восстановлению не затрагиваются как часть этого вопроса.

3. 6 октября 2026 г. в 13:41 UTCinvestigating

   Мы продолжаем расследование этого вопроса.

4. 6 октября 2026 г. в 13:41 UTCinvestigating

   Мы продолжаем расследование этого вопроса.

5. 6 октября 2026 г. в 15:19 UTCresolved

   Было развернуто исправление; скачивание снимков теперь содержит соответствующие данные.

6. 26 октября 2026 г. в 08:58 UTCpostmortem

   # Что случилось На Fri, 18 сентября 2026 14:33 UTC, мы определили, что загрузка снимков для экземпляров Aura, размещенных на Azure, возвращала файлы размером около 24 КБ вместо ожидаемого размера в несколько гигабайт. Базовые резервные копии, хранящиеся в Azure, были правильного размера, но путь загрузки в консоли обслуживал почти пустые файлы. Основной причиной была проблема с учетными данными Azure, которая произошла во время развертывания и предотвратила отправку резервных данных для загрузки. Первоначальное исправление было развернуто на Mon, 21 сентября 2026 10:31 UTC, восстанавливая правильные размеры загрузки. Тем не менее, та же проблема с учетными данными повторилась на Tue, 06 октября 2026 08:20 UTC, снова создав пустые скачивания снимков на всех уровнях Azure. Наша инженерная команда определила рецидив, связала его с той же первопричиной, развернула целевое исправление учетных данных для производства и проверила, что загрузки вернулись к ожидаемому размеру. 18 сентября мы не разместили пост на странице статуса, потому что пострадало небольшое количество клиентов, и мы работали с ними напрямую. Мы опубликовали 6 октября в 09:22 UTC, примерно через час после начала повторения, как только оно стало явно шире. # Как пострадал сервис На загрузку Snapshot повлияли экземпляры AuraDS Professional и Enterprise, AuraDB Professional, Business Critical и Virtual Dedicated Cloud, работающие на Azure. * Загрузка снимков возвращала неиспользуемые файлы. Когда клиенты загружали снимки с консоли, они получали файлы размером около 24 КБ вместо фактических данных резервного копирования, которые могли быть размером в несколько гигабайт. Это сделало загруженные снимки непригодными для восстановления в автономном режиме или миграции. Сами резервные копии не были потеряны. Основные резервные артефакты, хранящиеся в Azure, остались нетронутыми и правильного размера. Проблема была строго в пути загрузки, а не в процессе захвата или хранения резервных копий. Восстановление через консоль не было затронуто. Операции восстановления на платформе \(в отличие от загрузки файла сброса \) продолжали функционировать, потому что они получали доступ к данным резервного копирования непосредственно, а не через затронутый путь загрузки. # Что мы делаем сейчас Мы предприняли несколько шагов для решения проблемы и внедрили меры предосторожности для предотвращения повторения. * Развернуты полномочия. Мы исправили проблему с учетными данными Azure в производстве, которая немедленно восстановила загрузку снимков для всех пострадавших случаев. * Предотвращение непреднамеренной ротации учетных данных. Было представлено изменение кода, чтобы вернуть логику, которая запускала ротацию учетных данных Azure при каждом развертывании. Это гарантирует, что будущие развертывания не будут непреднамеренно аннулировать существующие учетные данные, которые были механизмом, вызвавшим как первоначальный инцидент, так и его повторение. * Текущий мониторинг. Мы отслеживаем загрузку снимков Azure на всех уровнях, чтобы подтвердить их стабильность. Мы попросили пострадавших клиентов проверить, что их загрузки теперь возвращают ожидаемые размеры файлов. Эти изменения касаются как непосредственного симптома, так и основного поведения развертывания, которое позволило проблеме повториться

Автоматический перевод официального обновления инцидента.

1. 6 октября 2026 г. в 08:07 UTCidentified

   Мы выявили проблему при попытке восстановить снимки на AuraDS. У нас есть готовое исправление и мы скоро его развернем. В то же время вы можете восстановить из резервной копии.

2. 6 октября 2026 г. в 09:07 UTCidentified

   Мы четко определили первопричину и продолжаем работать над исправлением этого вопроса.

3. 6 октября 2026 г. в 10:03 UTCidentified

   Мы продолжаем работать над исправлением этого вопроса.

4. 6 октября 2026 г. в 12:14 UTCidentified

   В настоящее время внедряется исправление и в ближайшее время будет распространено среди пострадавших клиентов.

5. 6 октября 2026 г. в 13:35 UTCmonitoring

   Исправление разворачивается, и пострадавшие клиенты должны постепенно восстанавливать функциональность.

6. 6 октября 2026 г. в 14:04 UTCresolved

   Мы развернули исправление для всех клиентов.

7. 26 октября 2026 г. в 08:51 UTCpostmortem

   # Что случилось Неисправность программного обеспечения в центральном компоненте управления Neo4j Aura snapshot восстанавливается для экземпляров AuraDS Professional и AuraDS Enterprise, размещенных на AWS. Когда запрашивалось восстановление, система просматривала экземпляр, используя неправильный тип ресурса, и возвращала ошибку. Инцидент был объявлен в понедельник, 05 октября 2026 года 21:52 UTC. Наша инженерная команда определила первопричину, разработала и проверила исправление и развернула его в производство во вторник, 06 октября 2026 года 13:37 UTC. # Как пострадал сервис Воздействие было направлено на операции по восстановлению снимков для экземпляров AuraDS Professional и AuraDS Enterprise. Пострадавшие клиенты не смогли восстановить снимки через Aura Console или Aura API. Попытки восстановления возвращали ошибки, нарушая рабочие процессы, которые зависят от восстановления снимков. *Случаи были доступны на протяжении всего мероприятия. Целостность данных не пострадала. Восстановление из полных и экспортированных резервных копий оставалось доступным в качестве обходного пути. # Что мы делаем сейчас Мы исправили дефект в уровне управления Aura, который повлиял на восстановление снимков AuraDS Professional и AuraDS Enterprise, и внедрили исправление в производство. Оптимизация трубопровода развертывания: во время этого инцидента трубопровод развертывания занимал больше времени, чем идеально, из-за последовательного создания тестового экземпляра. Мы оценили параллелизацию создания тестовых экземпляров, чтобы сократить время ожидания во время критических развертываний. Это улучшение направлено на сокращение времени, необходимого для проверки и исправления будущих инцидентов, уменьшая воздействие на клиентов

Автоматический перевод официального обновления инцидента.

1. 17 сентября 2026 г. в 16:46 UTCinvestigating

   В настоящее время мы знаем о проблеме, которая влияет на определенные операции с базами данных, такие как создание, удаление, клонирование для клиентов, использующих Aura на Azure.

2. 17 сентября 2026 г. в 17:11 UTCidentified

   Мы определили проблему и работаем над ее решением. В настоящее время некоторые операции с базами данных, такие как создание, удаление и клонирование для клиентов, использующих только Neo4j Aura на Azure, продолжают подвергаться воздействию.

3. 17 сентября 2026 г. в 19:06 UTCmonitoring

   Ремонт был развернут во всех затронутых средах. Мы будем следить за ситуацией, чтобы убедиться, что исправление полностью решит проблему.

4. 17 сентября 2026 г. в 19:55 UTCresolved

   После развертывания исправления мы отслеживали затронутые экземпляры, операционные показатели и ошибки. Теперь этот инцидент урегулирован. Вскрытие будет доступно, как только оно будет завершено.

5. 16 октября 2026 г. в 16:23 UTCpostmortem

   # Что случилось В четверг, 17 сентября 2026 года в 13:52 UTC, конфликт времени развертывания между параллельными операциями привел к удалению учетных данных, используемых основным компонентом Aura для аутентификации с инфраструктурой, размещенной в Azure. По мере истечения срока действия существующих токенов аутентификации компонент начал возвращать ошибки для некоторых экземпляров Aura, размещенных на Azure. Мы отследили ошибки до недостающих учетных данных, создали новый, надежно сохранили его и выполнили развертывание затронутого компонента, которое завершилось в 18:39 UTC. Небольшое количество запросов на создание базы данных, которые осуществлялись во время отключения, были оставлены в неполном состоянии и нуждались в ручном исправлении. Это было завершено в 19:48 UTC, а инцидент был помечен как разрешенный в 19:55 UTC. # Как пострадал сервис Воздействие было ограничено экземплярами Aura, размещенными на Azure. Другие облачные провайдеры не пострадали. *** Базовые операции:** Клиенты не могли выполнять определенные операции с базами данных, такие как создание, удаление и клонирование, в некоторых случаях Azure во время окна инцидента. Небольшое количество созданий, которые находились в процессе разработки, застряли и были восстановлены вручную. ** Видимость управления: ** Некоторые экземпляры, размещенные на Azure, временно не видны или не поддаются управлению в консоли Aura. ** Метрические пробелы:** Конечные точки метрики для некоторых экземпляров Azure возвращали прерывистые ошибки, оставляя короткие пробелы в данных метрик за затронутый период. Эти данные не будут повторно заполнены. Уже запущенные экземпляры Azure оставались доступными и продолжали нормально обслуживать рабочие нагрузки. # Что мы делаем сейчас Мы предпринимаем следующие шаги, чтобы предотвратить рецидив и улучшить нашу реакцию: ** Раннее обнаружение и связь:** Мы улучшим мониторинг и оповещение, а также оценим автоматизированные проверки учетных данных, чтобы проблемы были обнаружены и клиенты были проинформированы раньше. ** Восстановление из неполной базы данных: ** Мы исправим дефект, который может оставить создание базы данных застрявшим, если вызов инфраструктуры не проходит на полпути, поэтому система восстанавливается самостоятельно. *** Обзор аутентификации:** Мы рассмотрим, как этот компонент аутентифицируется с облачными провайдерами, чтобы устранить отдельные точки отказа и снизить риск повторения такого типа конфликтов.

Автоматический перевод официального обновления инцидента.

1. 16 сентября 2026 г. в 08:50 UTCidentified

   Наш поставщик услуг для портала поддержки испытывает некоторые сбои - см. https://status.salesforce.com/products/Salesforce Services Если у вас возникли проблемы с отправкой нового дела о поддержке, отправьте электронное письмо по адресу [email protected]

2. 16 сентября 2026 г. в 09:16 UTCidentified

   Наш провайдер портала поддержки все еще работает над решением этой проблемы. Подробности см. здесь https://status.salesforce.com/incidents/20004433

3. 16 сентября 2026 г. в 10:11 UTCidentified

   Наш провайдер портала поддержки продолжает работать над решением этой проблемы. Подробности см. здесь https://status.salesforce.com/incidents/20004433

4. 16 сентября 2026 г. в 11:30 UTCmonitoring

   В настоящее время осуществляется исправление, и со временем на портал должны оказывать меньшее влияние ошибки. См. подробности https://status.salesforce.com/incidents/20004433

5. 16 сентября 2026 г. в 12:29 UTCmonitoring

   Наш провайдер портала поддержки продолжает внедрять исправления.

6. 16 сентября 2026 г. в 14:31 UTCresolved

   Было развернуто исправление, и теперь все функции должны быть восстановлены.

Автоматический перевод официального обновления инцидента.

1. 9 сентября 2026 г. в 12:31 UTCinvestigating

   В настоящее время мы изучаем проблему, затрагивающую консоль Aura console.neo4j.io и API api.neo4j.io

2. 9 сентября 2026 г. в 12:54 UTCidentified

   Мы определили источник проблемы и сейчас работаем над решением.

3. 9 сентября 2026 г. в 13:10 UTCidentified

   Мы продолжаем работать над решением этого вопроса.

4. 9 сентября 2026 г. в 13:26 UTCidentified

   Мы добились хорошего прогресса и восстанавливаем проблемный компонент.

5. 9 сентября 2026 г. в 13:36 UTCmonitoring

   Мы внедрили исправление, и пострадавшие службы восстанавливаются.

6. 9 сентября 2026 г. в 13:39 UTCresolved

   Все пострадавшие компоненты полностью восстановлены.

Автоматический перевод официального обновления инцидента.

1. 3 сентября 2026 г. в 16:43 UTCinvestigating

   В настоящее время мы расследуем этот вопрос.

2. 4 сентября 2026 г. в 10:23 UTCidentified

   Этот вопрос был выявлен, по-прежнему имеются соответствующие случаи и меры по его разрешению в отношении рассматриваемых в настоящее время случаев.

3. 4 сентября 2026 г. в 15:36 UTCresolved

   Все экземпляры доступны, ручные шаги по разблокированию оставшегося небольшого числа экземпляров были предприняты для разрешения.

Автоматический перевод официального обновления инцидента.

1. 20 августа 2026 г. в 15:49 UTCinvestigating

   Наша команда выявила проблему с сбором показателей для экземпляров Aura. Это повлияет на метрическую видимость и пересылку. В настоящее время мы расследуем этот вопрос.

2. 20 августа 2026 г. в 16:48 UTCinvestigating

   Мы продолжаем исследовать проблему метрик ауры.

3. 20 августа 2026 г. в 19:10 UTCresolved

   С момента последнего обновления расследование продолжается. Проблема была выявлена, и мы следили за сервисом, как он восстанавливался после деградации. Мы подтверждаем, что вопрос сейчас решен.

4. 17 сентября 2026 г. в 10:09 UTCpostmortem

   # Что случилось В четверг, 20 августа 2026 года, 14:58:00 UTC, наш конвейер приема метрик начал испытывать повышенные экспортные сбои при отправке данных в Google Managed Prometheus (GMP). Основной причиной стал инцидент с сервисом Google Cloud Platform в регионе «us-west1», который нарушил путь экспорта, используемый нашей инфраструктурой сбора метрик. В результате метрические экспортные очереди начали накапливаться в подмножестве производственных сред. Сбои проявлялись в первую очередь в виде сетевых тайм-аутов при попытке доставить метрические данные в GMP, предотвращая нормальное попадание в организм пораженных кластеров. Наша команда инженеров определила географическую концентрацию затронутых систем, охватывающих AWS «us-west-2», Google Cloud «us-west1» и Azure «westus2», которые проходят через инфраструктуру в районе Орегона. Как только региональный инцидент GCP был смягчен Google, ошибки экспорта утихли, и очереди начали истощаться. # Как пострадал сервис Воздействие ограничивалось **метрической видимостью** для подмножества сред Aura. Было затронуто около 45 клиентских сред, что означает, что метрические данные из баз данных не попадали в нашу платформу мониторинга во время окна инцидента. Наиболее пострадавшим регионом был AWS «us-west-2» с дополнительным влиянием в Google Cloud «us-west1» и Azure «westus2». Клиенты с базами данных в этих регионах, возможно, испытывали пробелы в своих метриках и данных мониторинга на протяжении всего инцидента. Основные операции с базами данных, включая чтение, запись и доступность, не были затронуты; был нарушен только сбор и видимость показателей производительности. После того, как Google смягчил основную региональную проблему, метрическое потребление возобновилось, и было обработано отставание данных в очереди. # Что мы делаем сейчас Мы провели тщательный обзор этого инцидента и предпринимаем следующие шаги для повышения нашей устойчивости и возможностей реагирования: *** Улучшенные приборные панели наблюдения**: Мы улучшаем наши информационные панели экспортеров метрик, чтобы обеспечить более четкую и быструю видимость показателей ошибок в очередях и экспорте, что позволяет быстрее выявлять и диагностировать аналогичные проблемы. ***Улучшить агрегацию предупреждений**: Мы внедряем автоматическую группировку оповещений, чтобы региональный инцидент, затрагивающий несколько кластеров, лучше всплыл как одно коррелированное событие и рассматривался с соответствующей серьезностью и вниманием. *** Активное оповещение об ошибках при приеме внутрь:** Мы добавляем специальные оповещения о повышенных показателях ошибок при приеме GMP, давая нашей команде более ранний сигнал, прежде чем очереди экспортеров достигнут мощности. Эти улучшения предназначены для сокращения времени обнаружения, упрощения сортировки инцидентов и укрепления наших метрик против будущих сбоев в работе поставщиков.

Автоматический перевод официального обновления инцидента.

1. 5 августа 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 августа 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 августа 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 августа 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 августа 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 августа 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 августа 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 августа 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 августа 2026 г. в 09:44 UTCidentified

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

10. 7 августа 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 августа 2026 г. в 15:34 UTCresolved

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

Автоматический перевод официального обновления инцидента.

1. 23 июля 2026 г. в 10:52 UTCinvestigating

   В настоящее время мы расследуем вопрос.

2. 23 июля 2026 г. в 11:08 UTCinvestigating

   В настоящее время мы работаем с инженерными командами и добиваемся прогресса в расследованиях.

3. 23 июля 2026 г. в 11:24 UTCinvestigating

   Мы работаем с инженерными командами и продолжаем добиваться прогресса в расследованиях в настоящее время.

4. 23 июля 2026 г. в 11:38 UTCidentified

   Мы определили причину текущего вопроса и сейчас активно работаем над исправлением.

5. 23 июля 2026 г. в 11:53 UTCidentified

   Мы разворачиваем первую часть исправления и продолжаем активно работать над развертыванием полного решения. Мы ожидаем ETA в течение 1 часа.

6. 23 июля 2026 г. в 12:11 UTCidentified

   Мы определили подмножество пострадавших случаев и продолжаем развертывать исправление в настоящее время.

7. 23 июля 2026 г. в 12:32 UTCidentified

   Мы внедрили исправление конфигурации и теперь работаем над решением подмножества затронутых случаев.

8. 23 июля 2026 г. в 12:49 UTCidentified

   С развертыванием исправления конфигурации мы продолжаем разрешать подмножество случаев, все еще затронутых.

9. 23 июля 2026 г. в 14:07 UTCidentified

   Мы продолжаем урегулировать подмножество случаев, которые все еще затрагиваются.

10. 23 июля 2026 г. в 14:27 UTCidentified

    Мы продолжаем устранять подмножество случаев, которые все еще затрагиваются.

11. 23 июля 2026 г. в 14:44 UTCmonitoring

    Мы продолжаем устранять подмножество случаев, которые все еще затрагиваются.

12. 23 июля 2026 г. в 15:03 UTCmonitoring

    AuraDB Virtual Dedicated Cloud и AuraDB Business Critical теперь должны быть исправлены. Мы продолжаем разрешать подмножество случаев, которые все еще влияют на AuraDB Professional и Free.

13. 23 июля 2026 г. в 15:29 UTCmonitoring

    Мы продолжаем разрешать подмножество случаев, которые все еще влияют на AuraDB Professional и Free.

14. 23 июля 2026 г. в 15:57 UTCmonitoring

    Мы продолжаем разрешать подмножество случаев, которые все еще влияют на AuraDB Professional и Free.

15. 23 июля 2026 г. в 16:32 UTCmonitoring

    Мы продолжаем разрешать подмножество случаев, которые все еще влияют на AuraDB Professional и Free

16. 23 июля 2026 г. в 17:01 UTCmonitoring

    Мы продолжаем исправлять подмножество случаев, которые все еще влияют на AuraDB Professional и Free

17. 23 июля 2026 г. в 17:31 UTCmonitoring

    Мы продолжаем фиксировать небольшое подмножество случаев, которые все еще влияют на уровни AuraDB Professional и Free.

18. 23 июля 2026 г. в 18:07 UTCmonitoring

    Мы рассмотрели этот вопрос во всех профессиональных инстанциях AuraDB. Aura Free может пострадать. Мы продолжим отслеживать и исправлять оставшиеся базы данных.

19. 23 июля 2026 г. в 19:39 UTCmonitoring

    Мы продолжаем фиксировать небольшое подмножество свободных экземпляров, которые все еще затронуты.

20. 24 июля 2026 г. в 06:00 UTCmonitoring

    Мы продолжаем внимательно следить за ситуацией по любым дальнейшим вопросам.

21. 24 июля 2026 г. в 08:30 UTCmonitoring

    Мы продолжаем отслеживать любые дополнительные проблемы.

22. 24 июля 2026 г. в 12:59 UTCmonitoring

    Все выявленные случаи были исправлены, продолжая отслеживать. Свяжитесь со службой поддержки клиентов для дальнейших вопросов.

23. 24 июля 2026 г. в 15:56 UTCresolved

    Все исправления были развернуты, и проблема теперь помечена как решенная.

24. 29 июля 2026 г. в 21:58 UTCpostmortem

    ### ** Что случилось** В четверг, 23 июля 2026 года 10:33 UTC в Aura было развернуто изменение конфигурации, которое непреднамеренно изменило способ вычисления выделений памяти для экземпляров баз данных. В результате подмножество экземпляров получило недостаточную память, в результате чего некоторые экземпляры базы данных стали недоступны или не смогли завершить обновления. Скорректированное распределение памяти привело к условиям, не связанным с памятью, в результате чего экземпляры баз данных неоднократно перезагружались из-за недостаточного количества ресурсов памяти или застряли в обновлении. Эта проблема затронула несколько облачных провайдеров и несколько уровней продуктов. После того, как проблема была выявлена, мы немедленно изменили конфигурацию, предотвратив получение некорректной конфигурации. Исправленная конфигурация была развернута в производство к четвергу, 23 июля 2026 года 11:56 UTC. Однако экземпляры баз данных, которые уже получили неправильную конфигурацию, требовали отдельных действий по восстановлению, прежде чем они могли вернуться к нормальной работе. К четвергу 23 июля 2026 года 17:59 UTC были восстановлены все известные экземпляры баз данных, влияющие на клиентов. Мониторинг продолжался на следующий день, инцидент был полностью разрешен в пятницу, 24 июля 2026 года 16:30 UTC. ### ** Как это произошло Основное воздействие на клиентов заключалось в том, что несколько экземпляров базы данных AuraDB стали недоступны или вошли в деградировавшее состояние. Затрагиваемые случаи не могли завершить обычные обновления программного обеспечения и в некоторых случаях неоднократно перезагружались из-за недостаточной памяти. ** Доступность услуг: ** Влияние клиентов зависит от уровня обслуживания. Профессиональные экземпляры AuraDB, которые не обеспечивают высокую доступность, испытали наибольший уровень сбоев в обслуживании, причем подмножество стало недоступным и неспособным обрабатывать чтения или записи. В случаях AuraDB Business Critical и Virtual Dedicated Cloud (VDC) влияние, как правило, ограничивалось временной потерей отказоустойчивости при сохранении доступности сервиса. В меньшем числе случаев также стали недоступны экземпляры Business Critical и VDC. ** Обновления **: Дополнительные экземпляры оставались доступными, но застряли в состоянии «обновления», которое блокировало инициированные клиентами операции, такие как изменения размеров или конфигурации. *** Межплатформенный охват**: Влияние охватило все три поддерживаемых облачных провайдера и несколько регионов, затрагивая клиентов по всему миру. Случаи поддержки клиентов были подняты, и наша команда сортировала и вручную восстанавливала пострадавшие случаи в приоритетном порядке. Большинство экземпляров AuraDB продолжали работать в штатном режиме. Влияние клиента было полностью смягчено за счет возврата конфигурации и целевого ручного восстановления каждого пострадавшего экземпляра. ### ** Что мы делаем сейчас Мы провели тщательный анализ этого инцидента и определили следующие действия: ** Профилактика** *** Улучшенная проверка развертывания:** Мы усиливаем процесс проверки релиза, чтобы лучше идентифицировать изменения конфигурации. ** Компонентная развязка**: Мы оцениваем улучшения в последовательности развертывания компонентов, чтобы снизить риск непреднамеренных изменений, включаемых в релизы. *** Прогрессивная стратегия развертывания**: Мы рассматриваем процесс развертывания для пострадавших компонентов, чтобы привести их в соответствие с элементами управления развертыванием, используемыми для других критически важных компонентов. ** Обнаружение** *** Лучше предупредить**: Мы улучшаем наш мониторинг для более быстрого и надежного обнаружения аномального увеличения частоты отказов (например, потери отказоустойчивости или доступности). ** Смягчение наказания** *** Развертывание конфигурации сейфера** Мы улучшаем способ развертывания изменений производственной конфигурации, чтобы их можно было отключить или откатить быстрее, не требуя более широкого выпуска программного обеспечения. **Быстрый ручной инструмент восстановления**: Мы совершенствуем наши инструменты восстановления, чтобы сократить время, необходимое для выявления и ручного восстановления пострадавших случаев. Мы признаем нарушения, вызванные этим инцидентом, и приносим извинения за воздействие на пострадавших клиентов. Мы завершили немедленные корректирующие действия, и долгосрочные улучшения, описанные выше, уже осуществляются для снижения вероятности и воздействия подобных инцидентов в будущем.

Автоматический перевод официального обновления инцидента.

1. 10 июля 2026 г. в 17:18 UTCinvestigating

   В настоящее время мы расследуем проблему, затрагивающую консоль Aura, когда некоторые клиенты могут быть не в состоянии увидеть свои экземпляры. Эта проблема вызвана сбоем в стороннем сервисе, от которого зависит Aura. Затронутые экземпляры продолжают работать нормально, и подключение к базе данных не влияет. Наша команда активно изучает этот вопрос.

2. 10 июля 2026 г. в 17:23 UTCinvestigating

   Мы продолжаем расследование этого вопроса.

3. 10 июля 2026 г. в 17:51 UTCmonitoring

   Сторонний сервис, от которого зависит Aura, восстановил нормальную работу, а системы Neo4j Aura восстановились. Наша команда активно следит за этим вопросом, чтобы подтвердить, что Aura Console работает так, как ожидалось.

4. 10 июля 2026 г. в 19:23 UTCresolved

   Подтверждено, что службы работают, и никаких дальнейших перерывов не ожидается.

5. 27 июля 2026 г. в 04:28 UTCpostmortem

   ##Что случилось Консоль Aura и другие компоненты Aura испытали сбои в 2026-07-10 в 16:14 UTC, что привело к сбоям и аварийным взлётам. Следовательно, сегмент клиентов столкнулся с проблемами видимости в отношении своих случаев. Это было вызвано сбоем во внешнем стороннем сервисе, интегрированном с Aura. Важно отметить, что подключение к базе данных оставалось бескомпромиссным, и пострадавшие экземпляры продолжали свою обычную работу. Сервис LaunchDarkly восстановлен для решения проблемы ## Как это отразилось на сервисе Несколько компонентов Aura, включая Aura Console, испытали сбои. Пользователи сталкивались с ошибками HTTP 500 на страницах и операциях, связанных с базой данных, хотя к организациям и проектам все еще можно было получить доступ. Прямые соединения с конкретными экземплярами баз данных не были затронуты. Плоскость управления стала недоступной, что означало, что пользователи не могли создавать, удалять, изменять размер или корректировать настройки, например, через API или консоль Aura. Вместе с тем существующие случаи остаются оперативными. Проблема была вызвана сбоем в LaunchDarkly, и наши службы не справились с этим отказом во время запуска. Все пострадавшие системы вернулись к нормальной работе к 2026-07-10 в 17:07 UTC ##Что мы делаем сейчас Команда Neo4j Engineering быстро диагностировала первопричину и восстановила обслуживание. При оценке этого инцидента мы определили ключевые области для ускорения будущих решений и снижения рисков повторения: • Анализ ключевых показателей инцидентов с акцентом на продолжительность реагирования для выявления возможностей для ускорения эффективности реагирования Проведена комплексная ретроспектива, освещающая успешные результаты, включая быстрый анализ первопричин с помощью прозрачной регистрации, бесшовное выравнивание с помощью инструмента управления инцидентами и устойчивую, изящную деградацию нескольких компонентов, которые сохранили связь с плоскостью данных нетронутой. Активно разрабатывая более изящные резервные по умолчанию для флагов функций для защиты основных операций во время простоев поставщиков Укрепление архитектурной устойчивости за счет интеграции передовых методов планирования, инжиниринга хаоса и испытаний на впрыскивание неисправностей на уровне производства для упреждающего выявления и смягчения потенциальных путей отказа * Устранены логические ограничения в кэшировании флага оператора, что подчеркивает необходимость для операторов хранить оцениваемые флаги локально, чтобы сохранить непрерывность работы, если внешние зависимости выходят из строя.

Автоматический перевод официального обновления инцидента.

1. 30 июня 2026 г. в 14:45 UTCidentified

   Запуск CREATE VECTOR INDEX с ошибкой 51N31 Ошибка: конфигурация системы или исключение операции - не поддерживается. Создание векторного индекса с предоставленными настройками не поддерживается в V2026 02. Требуемая версия для работы — V2026 06. Пожалуйста, обновите СУБД. Это влияет только на новый индекс, существующие индексы не затронуты. Любой векторный индекс, созданный до 2026-06-30 в 09:00, продолжает работать в штатном режиме.

2. 30 июня 2026 г. в 15:41 UTCidentified

   Сейчас мы начинаем внедрять исправления для решения этой проблемы и вскоре предоставим обновленную информацию о прогрессе.

3. 30 июня 2026 г. в 16:05 UTCmonitoring

   Исправление разворачивается и хорошо прогрессирует. Мы будем обновляться с прогрессом.

4. 30 июня 2026 г. в 17:45 UTCresolved

   Это исправление было полностью развернуто во всех пострадавших случаях. Теперь этот инцидент урегулирован.

5. 20 июля 2026 г. в 08:40 UTCpostmortem

   ##Что случилось Проблема была выявлена после развертывания версии 2026.06 на 2026-06-30 в 08:00 UTC, где запуск «CREATE VECTOR INDEX» на модернизированных экземплярах Aura вызвал системное исключение. Этот сбой в генерации индексов произошел из-за того, что основной магазин и ядро требовали дополнительных обновлений для поддержки операции. Эта проблема повлияла только на создание новых индексов; существующие векторные индексы не затрагиваются. Любой векторный индекс, созданный до 09:00 2026-06-30, не пострадал и продолжал нормально работать. ## Как это отразилось на сервисе После развертывания версии 2026.06 исполнение заявления CREATE VECTOR INDEX не удалось, что повлияло на приложения, которые зависели от добавления новых векторных индексов. Пострадавшие клиенты получили ошибку: Создание векторного индекса с предоставленными настройками не поддерживается в V2026\ 02. Требуемая версия для работы — V2026\ 06. Пожалуйста, обновите DBMS. Существующие индексы и другие запросы остались полностью незатронутыми и функциональными. ##Что мы делаем сейчас Команды Neo4j определили первопричину ошибки в планировщике Cypher и решили проблему с помощью исправления кода. Это исправление было развернуто во всех пострадавших случаях Aura, полностью устранив ошибку. Чтобы предотвратить будущие инциденты, мы совершенствуем наши системы мониторинга и оповещения для выявления подобных проблем ранее, особенно в промежуточных средах, до развертывания. Одновременно мы совершенствуем процессы развертывания, чтобы свести к минимуму воздействие на клиентов и время восстановления. Кроме того, мы изучаем варианты внедрения автоматизированных тестов валидации после обновления специально для критических операций, таких как создание векторного индекса

Автоматический перевод официального обновления инцидента.

1. 23 июня 2026 г. в 11:25 UTCidentified

   Консоль Aura испытывает некоторые прерывистые ошибки: «Наша система испытывает проблемы прямо сейчас. Попробуйте еще раз позже или обратитесь в службу поддержки, если проблема сохраняется". Это может потребовать перезагрузки или более длительного ожидания навигации в консоли. Операции и Aura API остаются неизменными Мы активно работаем над исправлением

2. 23 июня 2026 г. в 13:03 UTCidentified

   Мы продолжаем расследовать решение этого вопроса

3. 23 июня 2026 г. в 13:39 UTCidentified

   Мы продолжаем работать над решением этой проблемы.

4. 23 июня 2026 г. в 15:43 UTCmonitoring

   Мы вносим изменения. Мы будем следить и обновлять.

5. 23 июня 2026 г. в 19:27 UTCmonitoring

   Продолжение мониторинга развернутых изменений. Следующее обновление ожидается 6/24/2026 10 утра UTC.

6. 24 июня 2026 г. в 09:14 UTCmonitoring

   Мы проверили и подтвердили, что вопрос сейчас полностью решен.

7. 24 июня 2026 г. в 09:14 UTCresolved

   Этот инцидент был урегулирован.

8. 10 июля 2026 г. в 14:50 UTCpostmortem

   ##Что случилось Примерно в 12:00 UTC 22 января 2026 года пользователи столкнулись с прерывистыми баннерами ошибок в дисплее консоли Aura: «У нас проблема. Попробуйте еще раз.», что произошло вместе с 500 ошибками с консольных конечных точек API. Эти сбои были временными и вызваны внутренним временем API во время процесса рукопожатия TLS, обычно разрешающимся в течение примерно 10 секунд или после обновления страницы. ## Как это отразилось на сервисе Aura Console и Aura API испытали ухудшение производительности, которое проявилось как прерывистые баннеры ошибок в интерфейсе консоли Aura. Исследование определило первопричину как высокое использование процессора и дросселирование в консольном API. Этот вопрос был в основном обусловлен повторяющимися крупными листингами организаций и дорогостоящими запросами посредников. Чтобы решить эту проблему, целевые исправления были успешно развернуты как на консоли Aura, так и на API Aura. За этим последовали корректировки конфигурации ресурсов для увеличения операционного зала и обеспечения стабильности. ##Что мы делаем сейчас Для снижения вероятности подобных инцидентов были приняты следующие реактивные и упреждающие меры: Разработана панель мониторинга для наблюдения за перепадами запросов на основе внутренних данных журнала API для реализации автоматизированного мониторинга и оповещения о проблемах с улавливанием до их возникновения Реализована пошатнувшаяся задержка между асфальтированными запросами на согласование для снижения высокого потребления ресурсов и повышения стабильности API * Расчеты ресурсов, учитывающих состояние инфраструктуры, для повышения эффективности Введен новый фильтр для запросов на основе уровней обслуживания для оптимизации накладных расходов на процессор для каждого вызова, выполняемого примирителем * Деактивированная обработка промежуточного программного обеспечения с избыточным запросом для оптимизации вызовов API

Автоматический перевод официального обновления инцидента.

1. 26 мая 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 мая 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 мая 2026 г. в 23:06 UTCresolved

   This incident has been resolved.

4. 9 июня 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 марта 2026 г. в 10:18 UTCidentified

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

2. 6 марта 2026 г. в 10:24 UTCmonitoring

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

3. 6 марта 2026 г. в 10:25 UTCresolved

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

4. 30 марта 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 марта 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 марта 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 марта 2026 г. в 04:52 UTCidentified

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

4. 4 марта 2026 г. в 14:07 UTCmonitoring

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

5. 4 марта 2026 г. в 15:19 UTCresolved

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

6. 8 апреля 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 марта 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 марта 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 марта 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 марта 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 марта 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)