Histórico de interrupções do Neo4j Aura

1. 26 Here 2026 da 14:50 UTCinvestigating

   Atualmente estamos cientes de um problema que está impactando os clientes usando Aura no Azure, ao tentar baixar instantâneos de instância de banco de dados.

2. 26 Here 2026 da 15:09 UTCidentified

   Identificámos a questão e estamos actualmente a trabalhar na implantação da solução.

3. 26 Here 2026 da 16:22 UTCidentified

   A correção está sendo testada atualmente em ambientes inferiores, antes de ser implantada.

4. 26 Here 2026 da 17:43 UTCidentified

   O teste da correção está em andamento e a implantação prosseguirá assim que o teste estiver concluído.

5. 26 Here 2026 da 19:14 UTCresolved

   Nossos engenheiros implantaram uma solução com sucesso, e o problema agora está resolvido. Os clientes Aura no Azure agora podem baixar instantâneos de banco de dados sem problemas.

Traduzido automaticamente da atualização oficial do incidente.

1. 20 Here 2026 da 07:35 UTCinvestigating

   Estamos actualmente a investigar uma questão que afecta a região Europa Ocidental 2 no GCP, que está a afectar algumas operações, incluindo a criação de uma base de dados na região.

2. 20 Here 2026 da 08:36 UTCinvestigating

   Continuamos a investigar a questão atualmente, trabalhando com o GCP para encontrar uma resolução. Neste momento, algumas operações, incluindo a criação de instância de banco de dados na região continuam a ser impactadas.

3. 20 Here 2026 da 09:15 UTCidentified

   Identificámos a fonte da questão que afecta actualmente os clientes da Europa-Oeste no GCP. Mais detalhes disponíveis na página de status da GCP em https://status.cloud.google.com/incidentes/Xs2XTHzAVC9YnafnPyzj. Neste momento, algumas operações, incluindo a criação de instância de banco de dados na região continuam a ser impactadas.

4. 20 Here 2026 da 10:42 UTCidentified

   Estamos actualmente a implementar medidas correctivas para atenuar a questão. Siga o mais recente do GCP na página de status em https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj.

5. 20 Here 2026 da 12:38 UTCmonitoring

   A funcionalidade deve agora ser restaurada nos serviços Aura afetados. Vamos acompanhar de perto a situação antes de considerarmos esta solução.

6. 20 Here 2026 da 14:06 UTCmonitoring

   Continuamos a acompanhar a situação com o GCP no momento actual e, neste momento, não vimos novas questões.

7. 20 Here 2026 da 14:50 UTCresolved

   Este incidente foi resolvido

Traduzido automaticamente da atualização oficial do incidente.

1. 13 Here 2026 da 09:15 UTCinvestigating

   Estamos investigando um problema impactando métricas no Console Aura e através do endpoint métrico.

2. 13 Here 2026 da 10:13 UTCidentified

   Identificamos que um problema relacionado ao provedor de serviços na nuvem está impactando a situação atual. Abrimos um caso de suporte com o Provedor de Serviços da Cloud e atualizaremos ainda mais quando tivermos mais detalhes.

3. 13 Here 2026 da 11:01 UTCmonitoring

   Acreditamos que o problema do provedor de serviços na nuvem foi resolvido, pois não estamos mais vendo problemas de nossos sistemas internos. Continuaremos a monitorar a situação, enquanto esperamos pela confirmação do provedor do Cloud Service.

4. 13 Here 2026 da 12:08 UTCresolved

   Tivemos a confirmação do Provedor de Serviços da Cloud de que o problema já foi totalmente resolvido.

5. 16 Here 2026 da 17:06 UTCpostmortem

   **Erros ao enviar métricas do GCP europe-west1** ** O que aconteceu** Na terça-feira, 13 de outubro de 2026 às 08:54 UTC, as métricas para instâncias no GCP europe-west1 deixaram de ser entregues e não puderam ser lidas. A causa foi um problema do lado do Google Cloud, onde uma redução de capacidade em seu serviço de monitoramento levou a solicitações válidas serem incorretamente rejeitadas. Metrics retornou ao normal às 10:49 UTC após o Google Cloud aplicar uma correção, e resolvemos o incidente às 12:08 UTC uma vez que o Google Cloud confirmou a resolução completa. Instâncias permaneceram disponíveis durante todo este evento, sem impacto no desempenho da consulta ou integridade dos dados. Apenas a visibilidade das métricas foi afetada. **Como o serviço foi afetado** Os clientes viram algumas lacunas curtas nas métricas de instância: * **Metricas de consola:** As instâncias do GCP europe-west1 podem ter mostrado dados métricos incompletos ou em falta durante a janela do incidente. * ** Integração de Monitoramento de Nuvem \(CMI\):** Métricas encaminhadas para seus próprios sistemas de monitoramento desta região também podem ter tido lacunas. Nem todas as instâncias na região foram impactadas, e outros provedores de nuvem e regiões não foram afetados. Métricas geradas durante o incidente não foram registradas, então a lacuna permanecerá em gráficos históricos para instâncias afetadas. O que estamos a fazer agora? A correção veio do Google Cloud nesta ocasião, mas nosso pipeline de métricas dependia de um caminho de uma única região, então estamos tomando medidas para reduzir essa exposição: * **Resistência regional:** Estamos avaliando o roteamento entre regiões para que as métricas de tráfego possam falhar em uma região saudável. * **Roteamento de tráfego:** Estamos explorando opções em nossa camada de rede em nuvem para redirecionar tanto as leituras \(Console e CMI\) e escreve \(ingestion\) longe de uma região impactada.

Traduzido automaticamente da atualização oficial do incidente.

1. 8 Here 2026 da 14:58 UTCinvestigating

   Estamos investigando um problema com métricas no Console Aura e através do endpoint métrico.

2. 8 Here 2026 da 15:36 UTCidentified

   Continuamos a investigar a causa raiz. A questão é limitada aos clientes em us-central1 em GCP As instâncias Aura estão em execução e nenhuma operação é afetada.

3. 8 Here 2026 da 16:30 UTCidentified

   Estamos trabalhando com o provedor de serviços na nuvem para investigar a natureza do problema. Nossos cheques confirmam que apenas um subconjunto de clientes que operam nas regiões centro-americanas1 são afetados.

4. 8 Here 2026 da 18:41 UTCidentified

   Continuamos trabalhando com o provedor de serviços na nuvem para obter uma solução.

5. 8 Here 2026 da 19:11 UTCresolved

   Este incidente foi agora resolvido, as métricas devem agora funcionar como normal.

6. 16 Here 2026 da 17:04 UTCpostmortem

   **Erros ao enviar métricas do GCP us-central1** ** O que aconteceu** Na quinta-feira, 8 de outubro de 2026, às 14:05 UTC, métricas de algumas instâncias do GCP us-central1 deixaram de ser entregues. A causa foi um problema no lado do Google Cloud que rejeitou incorretamente solicitações métricas válidas. A entrega métrica foi retomada às 18:00 UTC após o Google Cloud ter aplicado uma correção, e resolvemos o incidente às 18:48 UTC. Instâncias permaneceram disponíveis durante todo este evento, sem impacto no desempenho da consulta ou integridade dos dados. Apenas a visibilidade das métricas foi temporariamente afetada. **Como o serviço foi afetado** Os clientes viram lacunas em métricas de exemplo: * **Metricas de consola:** As instâncias no us-central1 do GCP podem ter mostrado dados métricos incompletos ou ausentes durante a janela incidente. * ** Integração de Monitoramento de Nuvem \(CMI\):** Métricas encaminhadas para seus próprios sistemas de monitoramento desta região também podem ter tido lacunas. Nem todas as instâncias na região foram afetadas, e outros provedores de nuvem e regiões não foram afetados. O que estamos a fazer agora? A correção veio do Google Cloud, mas estamos tomando medidas para capturar e responder a eventos semelhantes mais cedo: * **Alertando erros de entrega métrica:** Estamos adicionando alerta sobre taxas de erro de encaminhamento métrico, então falhas no lado do provedor são detectadas mais cedo e distinguidas de falhas de rotina. * ** Monitorização continuada:** Continuaremos monitorando a região com o Google Cloud para qualquer recorrência.

Traduzido automaticamente da atualização oficial do incidente.

1. 6 Here 2026 da 09:22 UTCinvestigating

   Estamos investigando um problema onde, apesar de backups completando com sucesso, downloads instantâneos estão retornando lixeiras em branco. Não se acredita que a restauração de um instantâneo através do console ou API Aura seja afetada, e estamos verificando isso agora. Vamos compartilhar uma atualização assim que tivermos mais informações.

2. 6 Here 2026 da 10:43 UTCinvestigating

   Continuamos a investigar a questão. As operações de restauração não são afetadas como parte deste problema.

3. 6 Here 2026 da 13:41 UTCinvestigating

   Continuamos a investigar esta questão.

4. 6 Here 2026 da 13:41 UTCinvestigating

   Continuamos investigando o problema.

5. 6 Here 2026 da 15:19 UTCresolved

   Uma correção foi implantada; downloads instantâneos agora contêm os dados apropriados.

6. 26 Here 2026 da 08:58 UTCpostmortem

   # O que aconteceu Em Fri, 18 Set 2026 14:33 UTC, identificamos que os downloads instantâneos para instâncias Aura hospedadas no Azure estavam retornando arquivos de aproximadamente 24KB em vez do tamanho esperado multi-gigabyte. Os backups subjacentes armazenados no Azure eram o tamanho correto, mas o caminho de download no console estava servindo arquivos quase vazios. A causa raiz foi um problema de credencial Azure que ocorreu durante uma implantação e impediu que os dados de backup fossem servidos para download. Uma correção inicial foi implantada em Mon, 21 Set 2026 10:31 UTC, restaurando tamanhos corretos de download. No entanto, a mesma questão credencial voltou em Tue, 06 Oct 2026 08:20 UTC, novamente produzindo downloads em branco instantâneos em todas as camadas Azure. Nossa equipe de engenharia identificou a recorrência, ligou-a à mesma causa raiz, implantou uma correção credencial direcionada à produção e verificou que os downloads retornaram ao tamanho esperado. Nós não postamos para a página de status em 18 de setembro porque um pequeno número de clientes foram afetados, e trabalhamos com eles diretamente. Postamos no dia 6 de outubro às 09:22 UTC, cerca de uma hora após o início da recidiva, uma vez que era claramente mais ampla. Como o serviço foi afectado Os downloads de instantâneo foram impactados para as instâncias AuraDS Professional e Enterprise, AuraDB Professional, Business Critical e Virtual Dedicated Cloud em execução no Azure. * Os downloads dos instantâneos retornaram arquivos inutilizáveis. Quando os clientes baixaram instantâneos do console, eles receberam arquivos de aproximadamente 24KB em vez dos dados de backup reais, que podem ser vários gigabytes de tamanho. Isso tornou os instantâneos baixados inutilizáveis para fins de restauração ou migração offline. * Os backups em si não foram perdidos. Os artefatos de backup subjacentes armazenados em Azure permaneceram intactos e corretamente dimensionados. O problema estava estritamente no caminho de download, não no processo de captura ou armazenamento de backup. * Restaurar através do console não foi afetado. Operações de restauração na plataforma \ (em oposição ao download de um arquivo de descarga\) continuou a funcionar porque eles acessaram os dados de backup diretamente ao invés de através do caminho de download afetado. O que estamos a fazer agora Tomámos várias medidas para resolver a questão e implementámos salvaguardas para evitar a recorrência. * Correção credencial implantada. Corrigimos o problema de credencial Azure na produção, que imediatamente restaurou downloads instantâneos para todas as instâncias afetadas. * Prevenir a rotação não intencional da credencial. Uma mudança de código foi submetida para reverter a lógica que estava desencadeando a rotação credencial Azure em cada implantação. Isso garante que futuras implantações não inadvertidamente invalidarão as credenciais existentes, que foi o mecanismo que causou tanto o incidente inicial quanto sua recorrência. * Monitoramento contínuo. Estamos monitorando downloads de instantâneo Azure em todos os níveis para confirmar que eles permanecem estáveis. Pedimos aos clientes afetados para verificar se seus downloads agora retornam os tamanhos de arquivos esperados. Essas mudanças abordam tanto o sintoma imediato quanto o comportamento de implantação subjacente que permitiu a repetição do problema

Traduzido automaticamente da atualização oficial do incidente.

1. 6 Here 2026 da 08:07 UTCidentified

   Identificamos um problema ao tentar restaurar a partir de instantâneos no AuraDS. Temos uma solução pronta e vamos lançar isto em breve. Enquanto isso, você pode restaurar de um backup em vez disso.

2. 6 Here 2026 da 09:07 UTCidentified

   Identificámos claramente a causa principal e continuamos a trabalhar numa solução para esta questão.

3. 6 Here 2026 da 10:03 UTCidentified

   Continuamos a trabalhar numa solução para esta questão.

4. 6 Here 2026 da 12:14 UTCidentified

   Uma correção está sendo implantado e vai rolar para os clientes afetados em breve.

5. 6 Here 2026 da 13:35 UTCmonitoring

   A correção está rolando e os clientes afetados devem ver a funcionalidade restaurada progressivamente.

6. 6 Here 2026 da 14:04 UTCresolved

   Implementámos a solução para todos os clientes.

7. 26 Here 2026 da 08:51 UTCpostmortem

   # O que aconteceu Um defeito de software em um componente de gerenciamento central do Neo4j Aura snapshot restaura para falhar para instâncias AuraDS Professional e AuraDS Enterprise hospedadas no AWS. Quando uma restauração foi solicitada, o sistema procurou a instância usando um tipo de recurso incorreto e retornou um erro. O incidente foi declarado na segunda-feira, 05 out 2026 21:52 UTC. Nossa equipe de engenharia identificou a causa raiz, desenvolveu e validou uma correção, e a implantou na produção na terça-feira, 06 out 2026 13:37 UTC. Como o serviço foi afectado O impacto foi escopo para operações de restauração de instantâneo para instâncias AuraDS Professional e AuraDS Enterprise. Os clientes afetados foram incapazes de restaurar instantâneos através do Console Aura ou API Aura durante a duração do problema. * Restaurar tentativas de erros retornados, interrompendo fluxos de trabalho que dependem de restaurações de instantâneo. * As instâncias permaneceram disponíveis durante todo este evento. A integridade dos dados não foi impactada. Restabelecer backups completos e exportados permaneceu disponível como uma solução alternativa. O que estamos a fazer agora * Consertamos o defeito na camada de gerenciamento da Aura que afetou o AuraDS Professional e AuraDS Enterprise snapshot restaura e implantou a correção para a produção. * Otimização do oleoduto de implantação: Durante este incidente, o oleoduto de implantação levou mais tempo do que o ideal devido à criação sequencial de instância de teste. Avaliamos a criação de instância de teste paralelizadora para reduzir os tempos de espera durante os lançamentos críticos. Esta melhoria visa reduzir o tempo que leva para validar e enviar uma correção em futuros incidentes, reduzindo o impacto frente ao cliente

Traduzido automaticamente da atualização oficial do incidente.

1. 17 Gwengolo 2026 da 16:46 UTCinvestigating

   Atualmente estamos cientes de um problema que está impactando certas operações de banco de dados, como criar, excluir, clonar para clientes usando Aura no Azure.

2. 17 Gwengolo 2026 da 17:11 UTCidentified

   Identificámos a questão e estamos a trabalhar para uma solução. Neste momento, certas operações de banco de dados, tais como criar, excluir e clonar para clientes usando Neo4j Aura apenas no Azure, continuam a ser impactadas.

3. 17 Gwengolo 2026 da 19:06 UTCmonitoring

   Uma correção foi implantada em todos os ambientes afetados. Vamos acompanhar a situação para garantir que a correção resolve completamente a questão.

4. 17 Gwengolo 2026 da 19:55 UTCresolved

   Após implantar a correção, monitoramos as instâncias impactadas, métricas operacionais e erros. Este incidente está agora resolvido. Uma autópsia estará disponível assim que estiver concluída.

5. 16 Here 2026 da 16:23 UTCpostmortem

   # O que aconteceu Na quinta-feira, 17 de setembro de 2026, às 13:52 UTC, um conflito de tempo de implantação entre operações simultâneas fez com que uma credencial usada por um componente Aura central para autenticar com a infraestrutura hospedada Azure fosse removida. Como os tokens de autenticação existentes expiraram, o componente começou a retornar erros para algumas instâncias do Aura hospedadas no Azure, afetando certas operações de banco de dados. Rastreamos os erros até a credencial em falta, criamos uma nova, a armazenamos com segurança e realizamos uma implantação contínua do componente afetado, que foi concluída às 18:39 UTC. Um pequeno número de solicitações de criação de banco de dados que estavam em andamento durante a interrupção foram deixadas em estado incompleto e necessitaram de remediação manual. Isso foi concluído às 19:48 UTC, e o incidente foi marcado resolvido às 19:55 UTC. Como o serviço foi afectado O impacto foi limitado às instâncias Aura hospedadas em Azure. Outros provedores de nuvem não foram afetados. * ** Operações de base de dados:** Os clientes foram incapazes de executar certas operações de banco de dados, como criar, excluir e clonar, em algumas instâncias Azure durante a janela incidente. Um pequeno número de criações que estavam em progresso ficou preso e foram recuperados manualmente. * **Visibilidade do gerenciamento:**Algumas instâncias hospedadas no Azure foram temporariamente não visíveis ou gerenciáveis no Console Aura. * **Lacunas métricas:** Os endpoints de métricas para algumas instâncias do Azure retornaram erros intermitentes, deixando lacunas curtas em dados de métricas para o período afetado. Estes dados não serão preenchidos. As instâncias de Azure que já estavam em execução permaneceram disponíveis e continuaram a atender cargas de trabalho normalmente. O que estamos a fazer agora Estamos tomando as seguintes medidas para ajudar a prevenir uma recorrência e melhorar a nossa resposta: * **Detecção e comunicação mais cedo:** Melhoraremos o monitoramento e o alerta, e avaliaremos os controles automáticos de credencial, para que os problemas sejam detectados e os clientes sejam informados mais cedo. * ** Recuperação da criação incompleta do banco de dados:** Vamos corrigir um defeito que pode deixar uma criação de banco de dados preso se uma chamada de infra-estrutura falhar parcialmente, para que o sistema recupera por conta própria. * ** Revisão da autenticação: ** Vamos rever como este componente autentica com provedores de nuvem, para remover pontos únicos de falha e reduzir o risco deste tipo de conflito recorrente.

Traduzido automaticamente da atualização oficial do incidente.

1. 16 Gwengolo 2026 da 08:50 UTCidentified

   Nosso provedor de serviços para o portal de suporte está passando por alguma falha - consulte https://status.salesforce.com/products/Salesforce Services Se você tiver problemas em enviar um novo caso de suporte, por favor envie e-mail para [email protected]

2. 16 Gwengolo 2026 da 09:16 UTCidentified

   O nosso fornecedor de portal de suporte ainda está a trabalhar no tratamento da questão. Ver pormenores aqui https://status.salesforce.com/incidentes/20004433

3. 16 Gwengolo 2026 da 10:11 UTCidentified

   O nosso fornecedor de portal de suporte continua a trabalhar no tratamento da questão. Ver pormenores aqui https://status.salesforce.com/incidentes/20004433

4. 16 Gwengolo 2026 da 11:30 UTCmonitoring

   Uma correção está sendo lançada e o portal deve ser menos impactado por erros ao longo do tempo. Ver detalhes https://status.salesforce.com/incidentes/20004433

5. 16 Gwengolo 2026 da 12:29 UTCmonitoring

   Nosso provedor de portal de suporte continua a lançar uma correção.

6. 16 Gwengolo 2026 da 14:31 UTCresolved

   Uma correção foi implantada e toda a funcionalidade deve agora ser recuperada.

Traduzido automaticamente da atualização oficial do incidente.

1. 9 Gwengolo 2026 da 12:31 UTCinvestigating

   Atualmente estamos investigando um problema que afeta o console Aura console.neo4j.io e o API api.neo4j.io

2. 9 Gwengolo 2026 da 12:54 UTCidentified

   Identificámos a origem da questão e estamos actualmente a trabalhar numa solução.

3. 9 Gwengolo 2026 da 13:10 UTCidentified

   Continuamos a trabalhar na abordagem da questão.

4. 9 Gwengolo 2026 da 13:26 UTCidentified

   Fizemos bons progressos e estamos a recuperar a componente problemática.

5. 9 Gwengolo 2026 da 13:36 UTCmonitoring

   Implementámos uma solução e os serviços afectados estão a recuperar.

6. 9 Gwengolo 2026 da 13:39 UTCresolved

   Todos os componentes afetados estão agora totalmente recuperados.

Traduzido automaticamente da atualização oficial do incidente.

1. 3 Gwengolo 2026 da 16:43 UTCinvestigating

   Estamos actualmente a investigar esta questão.

2. 4 Gwengolo 2026 da 10:23 UTCidentified

   A questão foi identificada, as instâncias permanecem disponíveis e as etapas a serem resolvidas para as instâncias impactadas sendo revistas atualmente.

3. 4 Gwengolo 2026 da 15:36 UTCresolved

   Todas as instâncias estão disponíveis, passos manuais para desbloquear o restante pequeno número de instâncias foi realizado para resolver.

Traduzido automaticamente da atualização oficial do incidente.

1. 20 Eost 2026 da 15:49 UTCinvestigating

   Nossa equipe identificou um problema com a coleta das métricas para instâncias Aura. Isso afetará a visibilidade métrica e o encaminhamento. Estamos neste momento a investigar a questão.

2. 20 Eost 2026 da 16:48 UTCinvestigating

   Continuamos investigando a questão das métricas de Aura.

3. 20 Eost 2026 da 19:10 UTCresolved

   Desde a última actualização, a investigação seguiu em frente. A questão foi identificada e monitoramos o serviço à medida que se recuperava da degradação. Confirmamos que a questão está agora resolvida.

4. 17 Gwengolo 2026 da 10:09 UTCpostmortem

   # O que aconteceu Na quinta-feira, 20 ago 2026 14:58:00 UTC, nosso pipeline de ingestão de métricas começou a experimentar elevadas falhas de exportação ao enviar dados para o Google Managed Prometeus \(GMP\). A causa subjacente foi um incidente de serviço do Google Cloud Platform na região `us-west1`, que interrompeu o caminho de exportação utilizado pela nossa infraestrutura de coleta de métricas. Como resultado, filas de exportação métricas começaram a crescer em um subconjunto de ambientes de produção. As falhas se manifestaram principalmente como timeouts de rede ao tentar entregar dados métricos para GMP, impedindo a ingestão normal para clusters afetados. Nossa equipe de engenharia identificou a concentração geográfica de sistemas afetados — abrangendo AWS `us-west-2`, Google Cloud `us-west1`, e Azure `westus2` — todas as rotas através de infraestrutura na área de Oregon. Uma vez que o incidente regional do GCP foi atenuado pelo Google, os erros de exportação diminuíram e as filas começaram a drenar. Como o serviço foi afectado O impacto foi limitado a ** visibilidade métrica** para um subconjunto de ambientes Aura. Aproximadamente 45 ambientes de clientes foram afetados, o que significa que os dados métricos das bases de dados não estavam sendo ingeridos em nossa plataforma de monitoramento durante a janela incidente. A região mais afetada foi a AWS `us-west-2`, com impacto adicional no Google Cloud `us-west1` e no Azure `westus2`. Clientes com bancos de dados nessas regiões podem ter experimentado lacunas em seus painéis de métricas e dados de monitoramento durante a duração do incidente. As operações do banco de dados principal — incluindo leituras, escrita e disponibilidade — não foram afetadas**; apenas a coleta e visibilidade das métricas de desempenho foram interrompidas. Uma vez que o Google mitigou o problema regional subjacente, a ingestão métrica foi retomada e o backlog de dados em fila foi processado. O que estamos a fazer agora Realizamos uma revisão completa deste incidente e estamos tomando as seguintes medidas para melhorar nossas capacidades de resiliência e resposta: * ** Painel de observação melhorado**: Estamos aprimorando nossos painéis de exportadores de métricas para proporcionar visibilidade mais clara e rápida na saúde da fila e taxas de erro de exportação, permitindo detecção e diagnóstico mais rápidos de problemas semelhantes. * **Melhorar a agregação de alerta**: Estamos implementando o agrupamento automático de alerta para que um incidente regional que afeta múltiplos clusters seja mais bem visto como um único evento correlacionado e tratado com gravidade e atenção adequadas. * ** Alerta proativo sobre as taxas de erro de ingestão: ** Estamos adicionando alertas dedicados que disparam sobre elevadas taxas de erro de ingestão de GMP, dando à nossa equipe um sinal anterior antes que as filas de exportadores atinjam a capacidade. Essas melhorias são projetadas para reduzir o tempo de detecção, simplificar a triagem de incidentes e fortalecer nosso pipeline de métricas contra futuras rupturas de fornecedores a montante.

Traduzido automaticamente da atualização oficial do incidente.

1. 5 Eost 2026 da 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 Eost 2026 da 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 Eost 2026 da 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 Eost 2026 da 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 Eost 2026 da 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 Eost 2026 da 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 Eost 2026 da 01:15 UTCidentified

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

8. 7 Eost 2026 da 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 Eost 2026 da 09:44 UTCidentified

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

10. 7 Eost 2026 da 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 Eost 2026 da 15:34 UTCresolved

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

1. 23 Gouere 2026 da 10:52 UTCinvestigating

   Neste momento, estamos a investigar uma questão.

2. 23 Gouere 2026 da 11:08 UTCinvestigating

   Estamos trabalhando com equipes de engenharia e progredindo com as investigações no momento atual.

3. 23 Gouere 2026 da 11:24 UTCinvestigating

   Estamos trabalhando com equipes de engenharia e continuamos fazendo progressos com as investigações no momento atual.

4. 23 Gouere 2026 da 11:38 UTCidentified

   Identificámos a causa da questão actual e estamos a trabalhar activamente na solução actualmente.

5. 23 Gouere 2026 da 11:53 UTCidentified

   Estamos implementando a primeira parte da correção e continuar trabalhando ativamente na implantação da solução completa. Esperamos uma chegada na ordem de 1 hora a partir de agora.

6. 23 Gouere 2026 da 12:11 UTCidentified

   Identificamos o subconjunto de instâncias impactadas e continuamos a implantar a correção neste momento.

7. 23 Gouere 2026 da 12:32 UTCidentified

   Implementamos uma correção de configuração e agora estamos trabalhando para resolver o subconjunto de instâncias impactadas.

8. 23 Gouere 2026 da 12:49 UTCidentified

   Com a correção de configuração implantada, continuamos a resolver o subconjunto de instâncias ainda impactadas.

9. 23 Gouere 2026 da 14:07 UTCidentified

   Continuamos a resolver o subconjunto de instâncias ainda impactadas.

10. 23 Gouere 2026 da 14:27 UTCidentified

    Continuamos a resolver o subconjunto de instâncias que ainda são impactadas.

11. 23 Gouere 2026 da 14:44 UTCmonitoring

    Continuamos a resolver o subconjunto de instâncias que ainda são impactadas.

12. 23 Gouere 2026 da 15:03 UTCmonitoring

    AuraDB Virtual Dedicated Cloud e AuraDB Business Critical devem agora ser corrigidos. Continuamos a resolver o subconjunto de instâncias que ainda são impactadas para o AuraDB Professional e Free.

13. 23 Gouere 2026 da 15:29 UTCmonitoring

    Continuamos a resolver o subconjunto de instâncias que ainda são impactadas para o AuraDB Professional e Free.

14. 23 Gouere 2026 da 15:57 UTCmonitoring

    Continuamos a resolver o subconjunto de instâncias que ainda são impactadas para o AuraDB Professional e Free.

15. 23 Gouere 2026 da 16:32 UTCmonitoring

    Continuamos a resolver o subconjunto de instâncias que ainda são impactadas para o AuraDB Professional e Free

16. 23 Gouere 2026 da 17:01 UTCmonitoring

    Continuamos a corrigir um subconjunto de instâncias que ainda são impactadas para o AuraDB Professional e Free

17. 23 Gouere 2026 da 17:31 UTCmonitoring

    Continuamos a corrigir um pequeno subconjunto de instâncias que ainda são impactadas sob os níveis AuraDB Professional e Free.

18. 23 Gouere 2026 da 18:07 UTCmonitoring

    Abordamos a questão em todas as instâncias profissionais do AuraDB. Aura Free ainda pode ser afetada. Continuaremos a monitorizar e a corrigir as restantes bases de dados.

19. 23 Gouere 2026 da 19:39 UTCmonitoring

    Continuamos a corrigir um pequeno subconjunto de instâncias Livres que ainda são impactadas.

20. 24 Gouere 2026 da 06:00 UTCmonitoring

    Continuamos a acompanhar de perto a situação relativamente a quaisquer outras questões.

21. 24 Gouere 2026 da 08:30 UTCmonitoring

    Continuamos monitorando quaisquer outros problemas.

22. 24 Gouere 2026 da 12:59 UTCmonitoring

    Todas as instâncias identificadas foram corrigidas, continuando a monitorar. Contacte o suporte ao cliente para quaisquer outros problemas.

23. 24 Gouere 2026 da 15:56 UTCresolved

    Todas as correções foram implantadas e o problema está agora marcado como resolvido.

24. 29 Gouere 2026 da 21:58 UTCpostmortem

    O que aconteceu? Na quinta-feira, 23 de julho de 2026 10:33 UTC foi implantada uma mudança de configuração para Aura que involuntariamente alterou como as alocações de memória foram calculadas para instâncias de banco de dados. Como resultado, um subconjunto de instâncias recebeu memória insuficiente, fazendo com que algumas instâncias de banco de dados fiquem indisponíveis ou incapazes de completar atualizações. A alocação ajustada de memória levou a condições fora da memória, fazendo com que as instâncias do banco de dados reiniciassem repetidamente devido a recursos de memória insuficientes ou se tornassem atualizadas. Este problema afetou instâncias em vários provedores de nuvem e vários níveis de produtos. Uma vez identificado o problema, revertemos imediatamente a alteração de configuração, impedindo que quaisquer instâncias adicionais recebessem a configuração incorreta. Uma configuração corrigida foi implantada na produção até quinta-feira, 23 de julho de 2026 11:56 UTC. No entanto, as instâncias de banco de dados que já haviam recebido a configuração incorreta exigiam ações de recuperação individual antes que pudessem retornar à operação normal. Por volta de 23 de julho de 2026 17:59 UTC, todas as instâncias conhecidas do banco de dados de impacto do cliente tinham sido recuperadas. O monitoramento continuou durante o dia seguinte, com o incidente totalmente resolvido na sexta-feira, 24 de julho de 2026 16:30 UTC. Como o serviço foi afectado O impacto primário do cliente foi que várias instâncias do banco de dados do AuraDB ficaram indisponíveis ou entraram em um estado degradado. As instâncias afetadas não foram capazes de completar atualizações de software de rotina e, em alguns casos, reiniciadas repetidamente porque memória insuficiente havia sido alocada. * ** Disponibilidade de serviço:** Impacto do cliente variado por nível de serviço. As instâncias profissionais do AuraDB, que não fornecem alta disponibilidade, experimentaram o maior nível de interrupção do serviço, com um subconjunto se tornando indisponível e incapaz de processar leituras ou gravações. Para as instâncias AuraDB Business Critical e Virtual Dedicated Cloud \(VDC\), o impacto foi geralmente limitado a uma perda temporária de tolerância a falhas enquanto a disponibilidade de serviço foi mantida. Em um número menor de casos, as instâncias Business Critical e VDC também se tornaram indisponíveis. * ** Atualizações do Stuck**: Outras instâncias permaneceram disponíveis, mas ficaram presas em um estado de atualização, que bloqueou operações iniciadas pelo cliente, como redimensionamentos ou alterações de configuração. * **Cross-platform escopo**: O impacto abrangeu todos os três provedores de nuvem suportados e várias regiões, afetando os clientes globalmente. Casos de suporte ao cliente foram levantados e nossa equipe triou e recuperou manualmente instâncias afetadas em ordem prioritária. A maioria das instâncias do AuraDB continuou a funcionar normalmente. O impacto do cliente foi totalmente atenuado através da recuperação manual da configuração revertida e direcionada de cada instância afetada. O que estamos a fazer agora Realizamos uma análise aprofundada deste incidente e identificamos as seguintes ações: * **Prevenção** * ** Validação de implantação melhorada:** Estamos fortalecendo nosso processo de validação de lançamento para identificar melhor as mudanças de configuração. * ** Desacoplamento de componentes**: Estamos avaliando melhorias no sequenciamento de implantações de componentes para reduzir o risco de alterações não intencionais serem incluídas em versões. * ** Estratégia de implantação progressiva**: Estamos a rever o processo de implantação dos componentes afectados, para os alinhar com os controlos de implantação utilizados para outros componentes críticos. * **Detecção** * ** Melhor alerta**: Estamos melhorando nosso monitoramento para detectar aumentos anormais nas taxas de falha \(como perda de tolerância à falha ou disponibilidade\) mais rápida e confiável. * **Mitigação** * ** Implementação de configuração segura:** Estamos melhorando a forma como as mudanças de configuração de produção são implantadas para que possam ser desativadas ou removidas mais rapidamente sem precisar de uma versão de software mais ampla. * ** Ferramenta de recuperação manual mais rápida**: Estamos melhorando nossa ferramenta de recuperação para reduzir o tempo necessário para identificar e recuperar manualmente instâncias afetadas. Reconhecemos a perturbação que este incidente causou e pedimos desculpas pelo impacto para os clientes afetados. Completámos as medidas correctivas imediatas, e as melhorias a mais longo prazo acima descritas já estão em curso para reduzir a probabilidade e o impacto de incidentes semelhantes no futuro.

Traduzido automaticamente da atualização oficial do incidente.

1. 10 Gouere 2026 da 17:18 UTCinvestigating

   Atualmente estamos investigando um problema que afeta o Console Aura onde alguns clientes podem não ser capazes de ver suas instâncias. Esta questão é causada por uma falha em um serviço de terceiros que depende da Aura. As instâncias afetadas continuam rodando normalmente, e a conectividade do banco de dados não é impactada. A nossa equipa está a investigar a questão.

2. 10 Gouere 2026 da 17:23 UTCinvestigating

   Continuamos a investigar esta questão.

3. 10 Gouere 2026 da 17:51 UTCmonitoring

   O serviço de terceiros de que a Aura depende restaurou operações normais e os sistemas Neo4j Aura recuperaram. Nossa equipe está monitorando o problema ativamente para confirmar que a Aura Console está atuando como esperado.

4. 10 Gouere 2026 da 19:23 UTCresolved

   Os serviços são confirmados como operacionais e não se esperam mais interrupções.

5. 27 Gouere 2026 da 04:28 UTCpostmortem

   # # O Que Aconteceu A Aura Console e outros componentes da Aura sofreram interrupções em 2026-07-10 às 16:14 UTC, resultando em falhas e falhas. Consequentemente, um segmento de clientes enfrentou problemas de visibilidade em relação às suas instâncias. Foi causado por uma interrupção em um serviço externo de terceiros integrado com Aura. Crucialmente, a conectividade do banco de dados permaneceu descomprometida, e as instâncias impactadas continuaram suas operações normais. O serviço LaunchDarkly foi restaurado para resolver o problema # # Como o serviço foi afetado Vários componentes da Aura, incluindo o Console Aura, sofreram perturbações. Os usuários encontraram erros HTTP 500 em páginas e operações relacionadas ao banco de dados, embora organizações e projetos ainda pudessem ser acessados. As ligações directas a instâncias específicas da base de dados não foram completamente afectadas O plano de controle tornou-se indisponível, o que significava que os usuários não poderiam criar, excluir, redimensionar ou ajustar configurações para instâncias através da API ou do console Aura. No entanto, as instâncias existentes mantiveram-se operacionais. O problema foi causado por uma falha no LaunchDarkly e nossos serviços não lidaram com essa falha de dependência graciosamente durante a inicialização. Todos os sistemas afetados retornaram à operação normal até 2026-07-10 às 17:07 UTC # # O que estamos fazendo agora A equipe de engenharia Neo4j rapidamente diagnosticou a causa raiz e o serviço restaurado. Ao avaliar este incidente, identificamos áreas-chave para acelerar futuras resoluções e mitigar os riscos de recorrência: * Analisadas as principais métricas de incidentes, com foco na duração alerta-resposta para identificar oportunidades para acelerar a eficiência de resposta * Conduziu uma retrospectiva abrangente destacando resultados bem sucedidos, incluindo análise rápida da causa raiz através de registro transparente, alinhamento sem costura através da ferramenta de gerenciamento de incidentes, e a degradação resistente e graciosa de múltiplos componentes que manteve a conectividade do plano de dados intacta * Desenvolvimento ativo de padrões mais graciosos para flags de recursos para proteger operações principais durante o tempo de inatividade do fornecedor * Fortalecer a resiliência arquitetônica integrando planejamento avançado, práticas de engenharia do caos e testes de injeção de falhas em nível de produção para descobrir e mitigar caminhos de falha potenciais * Limitações lógicas endereçadas no cache de flag do operador, enfatizando a necessidade de operadores armazenarem bandeiras avaliadas localmente para preservar a continuidade operacional se as dependências externas falharem.

Traduzido automaticamente da atualização oficial do incidente.

1. 30 Mezheven 2026 da 14:45 UTCidentified

   A execução do ÌNDICE DE CRIAÇÃO DE VERSÍCULOS falha com o erro 51N31 erro: configuração do sistema ou exceção de operação - não suportado. Criar um índice vetorial com configurações fornecidas não é suportado em V2026 02. A versão necessária para operação é V2026 06. Por favor, atualize o DBMS.. Isto só afeta o novo índice, o ÌNDICE VECTOR existente não é afetado. Qualquer índice vetorial criado antes de 2026-06-30 às 09:00 continuar a operar normalmente.

2. 30 Mezheven 2026 da 15:41 UTCidentified

   Estamos começando agora a implantar uma correção para resolver este problema e irá fornecer uma atualização em breve sobre o progresso.

3. 30 Mezheven 2026 da 16:05 UTCmonitoring

   Uma solução está a sair e a progredir bem. Atualizaremos com o progresso.

4. 30 Mezheven 2026 da 17:45 UTCresolved

   A correção foi totalmente implantada em todas as instâncias impactadas. Este incidente está agora resolvido.

5. 20 Gouere 2026 da 08:40 UTCpostmortem

   # # O Que Aconteceu Um problema foi identificado após a implantação da versão 2026.06 em 2026-06-30 às 08:00 UTC, onde executar `CREATE VECTOR ÌNDICE` em instâncias atualizadas Aura desencadeou uma exceção do sistema. Esta falha na geração do índice ocorreu porque o armazenamento subjacente e o kernel necessitaram de atualizações adicionais para suportar a operação Este problema apenas afetou a criação de novos índices; os índices vetoriais existentes não são afetados. Qualquer índice vetorial criado antes das 09:00 em 2026-06-30 não foi afetado e continuou a funcionar normalmente. # # Como o serviço foi afetado Após o lançamento da versão 2026.06, a execução da instrução CREATE VECTOR INDICE falhou, impactando aplicações que dependiam da adição de novos índices vetoriais. Clientes afetados receberam o erro: Criar um índice vetorial com configurações fornecidas não é suportado em V2026\ 02. A versão necessária para operação é V2026\ 06. Por favor, atualize o DBMS . Os índices existentes \(criados antes deste incidente\) e outras consultas permaneceram inteiramente inalterados e totalmente funcionais. # # O que estamos fazendo agora As equipes Neo4j identificaram a causa raiz como um bug no planejador Cypher e resolveram o problema com uma correção de código. Esta correção foi implantada em todas as instâncias Aura afetadas, resolvendo completamente o erro Para evitar futuras ocorrências, estamos aprimorando nossos sistemas de monitoramento e alerta para detectar problemas semelhantes mais cedo, especialmente dentro de ambientes de estadiamento, antes que ocorram desdobramentos. Simultaneamente, estamos refinando nossos processos de implantação para minimizar o impacto do cliente e os tempos de recuperação Além disso, estamos investigando opções para implementar testes automatizados de validação pós-atualização especificamente para operações críticas, como criação de índice vetorial

Traduzido automaticamente da atualização oficial do incidente.

1. 23 Mezheven 2026 da 11:25 UTCidentified

   O console Aura está passando por alguns erros intermitentes: "Nosso sistema está tendo problemas agora mesmo. Tente novamente mais tarde ou contacte o suporte se o problema persistir." Isso pode exigir que você recarregue ou espere mais tempo para navegar no console As operações e a API do Aura permanecem inalteradas Estamos trabalhando ativamente em uma correção

2. 23 Mezheven 2026 da 13:03 UTCidentified

   Continuamos a investigar uma solução para o problema

3. 23 Mezheven 2026 da 13:39 UTCidentified

   Continuamos trabalhando em uma solução para esse problema.

4. 23 Mezheven 2026 da 15:43 UTCmonitoring

   Estamos a lançar uma mudança. Vamos monitorizar e actualizar.

5. 23 Mezheven 2026 da 19:27 UTCmonitoring

   Continuando a monitorar as alterações implantadas. Próxima atualização prevista 6/24/2026 10am UTC.

6. 24 Mezheven 2026 da 09:14 UTCmonitoring

   Verificamos e confirmámos que a questão está agora totalmente resolvida.

7. 24 Mezheven 2026 da 09:14 UTCresolved

   Este incidente foi resolvido.

8. 10 Gouere 2026 da 14:50 UTCpostmortem

   # # O Que Aconteceu Por volta das 12:00 UTC em 22 de janeiro de 2026, os usuários encontraram banners de erro intermitentes no console Aura exibindo, "Estamos tendo um problema. Tente novamente.", que ocorreu ao lado de 500 erros dos terminais de API do console. Essas interrupções foram transitórias e causadas pelo timing interno da API durante o processo de aperto de mão do TLS, normalmente resolvendo em cerca de 10 segundos ou seguindo uma atualização da página # # Como o serviço foi afetado A API Aura Console e Aura experimentou desempenho degradado, que se manifestou como banners de erro intermitentes dentro da interface do console Aura. Uma investigação identificou a causa raiz como alto uso de CPU e estrangulamento dentro da API do console. Esta questão foi principalmente impulsionada por constantes listas de entidades de grande dimensão e pedidos de conciliação dispendiosos Para resolver o problema, correções direcionadas foram implantadas com sucesso no console Aura e API Aura. Seguiu-se a adaptação da configuração dos recursos para aumentar a sede operacional e garantir a estabilidade. # # O que estamos fazendo agora Foram implementadas as seguintes medidas reativas e proativas para reduzir a probabilidade de incidentes semelhantes: * Desenvolveu um painel de monitoramento para observar as quedas de solicitação com base em dados internos do log da API para implementar monitoramento automatizado e alerta para problemas de captura antes que ocorram * Implementou um atraso escalonado entre pedidos de reconciliação paginada para mitigar o alto consumo de recursos e melhorar a estabilidade da API * Melhoria dos cálculos de recursos conscientes da infraestrutura para melhorar o desempenho * Introduziu um novo filtro para consultas baseadas em níveis de serviço para otimizar a sobrecarga da CPU para cada chamada realizada pelo reconciliador * Desativado processo de middleware de solicitação redundante para otimizar chamadas API

Traduzido automaticamente da atualização oficial do incidente.

1. 26 Mae 2026 da 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 Mae 2026 da 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 Mae 2026 da 23:06 UTCresolved

   This incident has been resolved.

4. 9 Mezheven 2026 da 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 Meurzh 2026 da 10:18 UTCidentified

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

2. 6 Meurzh 2026 da 10:24 UTCmonitoring

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

3. 6 Meurzh 2026 da 10:25 UTCresolved

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

4. 30 Meurzh 2026 da 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 Meurzh 2026 da 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 Meurzh 2026 da 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 Meurzh 2026 da 04:52 UTCidentified

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

4. 4 Meurzh 2026 da 14:07 UTCmonitoring

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

5. 4 Meurzh 2026 da 15:19 UTCresolved

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

6. 8 Ebrel 2026 da 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 Meurzh 2026 da 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 Meurzh 2026 da 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 Meurzh 2026 da 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 Meurzh 2026 da 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 Meurzh 2026 da 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)