Neo4j Aura 장애 기록

1. 2026년 10월 26일 오후 2:50 UTCinvestigating

   우리는 현재 Azure에서 Aura를 사용하여 고객에게 영향을 미치는 문제의 인식입니다. 데이터베이스 인스턴스 스냅 샷을 다운로드하려고 할 때.

2. 2026년 10월 26일 오후 3:09 UTCidentified

   우리는 문제점을 확인하고 현재 수정의 배포에 종사하고 있습니다.

3. 2026년 10월 26일 오후 4:22 UTCidentified

   수정은 현재 배포되기 전에 더 낮은 환경에서 테스트되고 있습니다.

4. 2026년 10월 26일 오후 5:43 UTCidentified

   수정 테스트가 진행되고 배포가 완료되면 테스트가 완료되었습니다.

5. 2026년 10월 26일 오후 7:14 UTCresolved

   우리의 엔지니어들은 성공적으로 수정을 배포했으며, 문제는 이제 해결되었습니다. Azure의 Aura 고객은 이제 문제없이 데이터베이스 스냅 샷을 다운로드 할 수 있습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 10월 20일 오전 7:35 UTCinvestigating

   우리는 현재 지역 데이터베이스 인스턴스 생성을 포함한 일부 작업에 영향을 미치는 유럽 서부 2 지역에 영향을 미치는 문제점을 조사하고 있습니다.

2. 2026년 10월 20일 오전 8:36 UTCinvestigating

   우리는 현재 문제를 조사하고 있으며, GCP와 협력하여 해결책을 찾을 수 있습니다. 이 시점에서 데이터베이스 인스턴스 생성을 포함한 일부 작업은 계속 영향을받습니다.

3. 2026년 10월 20일 오전 9:15 UTCidentified

   우리는 현재 GCP에 유럽-서부2에 영향을 미치는 문제점의 근원을 확인했습니다. https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj에 GCP statuspage에서 유효한 세부사항 더. 이 시점에서 데이터베이스 인스턴스 생성을 포함한 일부 작업은 계속 영향을받습니다.

4. 2026년 10월 20일 오전 10:42 UTCidentified

   우리는 현재 중개 행동을 실행하고 있습니다. https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj에서 GCP의 최신 상태를 따르십시오.

5. 2026년 10월 20일 오후 12:38 UTCmonitoring

   Functionality는 이제 영향을받은 Aura 서비스를 통해 복원해야합니다. 우리는이 해결하기 전에 상황을 밀접하게 모니터링 할 것입니다.

6. 2026년 10월 20일 오후 2:06 UTCmonitoring

   우리는 현재 시간에 GCP와 상황을 모니터링하고이 시점에서 우리는 새로운 문제를 볼 수 없습니다.

7. 2026년 10월 20일 오후 2:50 UTCresolved

   이 사건은 해결되었습니다

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 10월 13일 오전 9:15 UTCinvestigating

   Aura 콘솔의 메트릭에 영향을 미치는 문제와 메트릭 엔드포인트를 통해 투자하고 있습니다.

2. 2026년 10월 13일 오전 10:13 UTCidentified

   Cloud Service Provider 관련 이슈가 현재 상황에 영향을 미치는 것으로 확인했습니다. Cloud Service Provider와 지원 사례를 개설하고 한 번 더 자세히 업데이트합니다.

3. 2026년 10월 13일 오전 11:01 UTCmonitoring

   Cloud Service Provider가 해결되었는지 믿고 있습니다. 내부 시스템에서 더 이상 문제가 보이지 않습니다. 클라우드 서비스 제공 업체로부터 확인을 기다리는 동안 상황을 계속 모니터링 할 것입니다.

4. 2026년 10월 13일 오후 12:08 UTCresolved

   클라우드 서비스 제공 업체로부터 확인을 받았는데 문제가 해결되었습니다.

5. 2026년 10월 16일 오후 5:06 UTCpostmortem

   **GCP europe-west1** 에서 메트릭을 보낼 때 **What 일어난 일** 화요일, 10월 13, 2026일 at 08:54 UTC, GCP europe-west1의 인스턴스의 메트릭은 전달되지 않고 읽을 수 없습니다. 원인은 Google Cloud Side의 문제였습니다. 모니터링 서비스에 대한 용량 감소가 잘못된 거부되는 유효한 요청으로 이끌었습니다. Google Cloud가 수정을 적용한 후 10:49 UTC에서 정상으로 돌아와서 Google Cloud가 풀 해상도를 확인한 후 12:08 UTC에서 사건을 해결했습니다. Instance는 이 사건을 통하여 유효하, 성과 또는 자료 무결성에 충격 없이. metrics 가시성만 영향을 미쳤습니다. **서비스가 영향을 미치는 방법** Customers는 인스턴스 메트릭스에 있는 몇몇 짧은 간격을 보았습니다: * **Console 미터:** GCP europe-west1의 인스턴스는 사건 창에서 불완전하거나 누락된 메트릭 데이터를 표시할 수 있습니다. * **Cloud 모니터링 통합 \(CMI\):** 이 지역에서 자신의 모니터링 시스템에 전달 된 미터는 격차가있을 수도 있습니다. 지역의 모든 인스턴스가 영향을 미쳤으며, 다른 클라우드 공급자와 지역은 비공식적이었습니다. 사건 중에 생성 된 미터는 기록되지 않았으므로 영향을받는 인스턴스에 대한 역사적인 차트에 남아 있습니다. **우리가 지금하고 있는 것** 이 경우 Google Cloud에서 수정되었지만 단일 대역 경로에 의존하는 미터 파이프라인은 그 노출을 줄이기 위해 단계를 수행하고 있습니다. * **지역 탄력:** 우리는 횡단 방향 routing을 evaluating 그래서 미터 트래픽은 건강한 지역에 실패 할 수 있습니다. * **Traffic 여정:** 클라우드 네트워킹 레이어의 옵션을 살펴보고, 두 번 읽는 \(Console and CMI\)를 다시 읽으려면 \(ingestion\)를 작성합니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 10월 8일 오후 2:58 UTCinvestigating

   Aura 콘솔의 메트릭과 메트릭 엔드포인트를 통해 문제를 조사하고 있습니다.

2. 2026년 10월 8일 오후 3:36 UTCidentified

   우리는 뿌리 원인을 조사 계속합니다. 문제는 GCP에서 us-central1에 고객에게 제한됩니다. Aura 인스턴스가 실행되고 가동이 영향을 미치지 않습니다.

3. 2026년 10월 8일 오후 4:30 UTCidentified

   우리는 클라우드 서비스 제공 업체와 협력하여 문제를 조사합니다. 우리의 체크는 us-central1 지구에서 달리는 고객의 subset만 영향을 받습니다.

4. 2026년 10월 8일 오후 6:41 UTCidentified

   우리는 클라우드 서비스 제공 업체와 협력하여 솔루션을 계속합니다.

5. 2026년 10월 8일 오후 7:11 UTCresolved

   이 사건은 지금 해결되었습니다, 미터는 지금 정상으로 작동되어야 합니다.

6. 2026년 10월 16일 오후 5:04 UTCpostmortem

   **GCP us-central1** 에서 메트릭을 보낼 때 **What 일어난 일** 목요일, 10월 8일, 2026일 at 14:05 UTC, GCP us-central1의 일부 인스턴스에서 메트릭이 전달되었습니다. 원인은 잘못된 유효 메트릭 요청을 거부 한 Google Cloud 측에 문제가되었습니다. Google Cloud가 수정을 적용한 후 18:00 UTC에서 미터 배송을 재개했으며 18:48 UTC. Instance는 이 사건을 통하여 유효하, 성과 또는 자료 무결성에 충격 없이. metrics 가시성만 일시적으로 영향을 미쳤습니다. **서비스가 영향을 미치는 방법** 고객은 인스턴스 메트릭에서 갭을 보았습니다. * **Console 미터:** GCP us-central1의 Instances는 사건 창 도중 불완전하거나 누락된 미터 자료가 있을지도 모릅니다. * **Cloud 모니터링 통합 \(CMI\):** 이 지역에서 자신의 모니터링 시스템에 전달 된 미터는 격차가있을 수도 있습니다. 지역의 모든 인스턴스가 영향을 받지 않았으며, 다른 클라우드 공급자와 지역은 unaffected. **우리가 지금하고 있는 것** 이 수정은 Google Cloud에서 왔지만, 우리는 더 빨리 비슷한 이벤트에 참여하고 대응하는 단계가 있습니다. * **미터 배송 오류에 대한 해결:** metric forwarding error rate에 대한 경고를 추가하고 있으므로 공급자 측 실패가 먼저 감지하고 routine 간격과 구별됩니다. * **Continued 모니터링:** 우리는 어떤 재발견을 위해 Google Cloud와 지역을 모니터링합니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 10월 6일 오전 9:22 UTCinvestigating

   우리는 성공적으로 완료하는 백업에도 불구하고 문제가 투자하고, 스냅 샷 다운로드는 빈 덤프를 반환합니다. Aura 콘솔 또는 API를 통해 스냅 샷을 복원하는 것은 영향을받지 않고, 우리는이 지금 확인하고 있습니다. 우리는 더 많은 정보가 있기 때문에 업데이트를 공유 할 것입니다.

2. 2026년 10월 6일 오전 10:43 UTCinvestigating

   우리는 문제를 조사하고 있습니다. 복구 작업은이 문제의 일부로 영향을 미치지 않습니다.

3. 2026년 10월 6일 오후 1:41 UTCinvestigating

   이 문제를 조사하고 있습니다.

4. 2026년 10월 6일 오후 1:41 UTCinvestigating

   이 문제를 계속 조사하고 있습니다.

5. 2026년 10월 6일 오후 3:19 UTCresolved

   수정이 배포되었습니다. 스냅 샷 다운로드는 이제 적절한 데이터를 포함합니다.

6. 2026년 10월 26일 오전 8:58 UTCpostmortem

   # 무슨 일이 있었는지 Fri, 18 Sep 2026 14:33 UTC, 우리는 Azure에서 호스팅되는 Aura 인스턴스에 대한 스냅 샷 다운로드가 예상 멀티 기가 바이트 크기 대신 약 24KB의 파일을 반환했다고 확인. Azure에 저장된 언더리 백업은 올바른 크기였지만 콘솔의 다운로드 경로는 주변 파일들을 제공합니다. 루트 원인은 배포 중에 발생했던 Azure credential 문제이며 다운로드를 위해 제공된 백업 데이터를 방지했습니다. 초기 수정은 Mon, 21 Sep 2026 10:31 UTC에 배포되었으며, 올바른 다운로드 크기를 복원합니다. 그러나 같은 자격 증명 문제는 화요일, 06 Oct 2026 08:20 UTC, 다시 모든 Azure 계층에 걸쳐 빈 스냅 샷 다운로드를 생산. 우리의 엔지니어링 팀은 recurrence를 확인, 같은 루트 원인에 연결, 생산에 대상 자격 수정을 배치, 그리고 그들의 예상 크기에 반환 다운로드 확인. 우리는 9 월 18 일 상태 페이지에 게시하지 않았기 때문에 고객의 작은 숫자가 영향을 받았기 때문에, 우리는 직접 그들과 함께 일했습니다. 우리는 10 월에 게시 6 에 09:22 UTC, recurrence 시작 후 약 시간, 한 번 명확하게 더 넓은. # 서비스 영향을받는 방법 Snapshot 다운로드는 AuraDS Professional 및 Enterprise, AuraDB Professional, Business Critical 및 Virtual Dedicated Cloud 인스턴스에 영향을 미쳤습니다. * Snapshot 다운로드는 사용 가능한 파일을 반환합니다. 고객이 콘솔에서 스냅 샷을 다운로드하면 실제 백업 데이터 대신 약 24KB의 파일을 수신하여 크기에 여러 기가 바이트가 될 수 있습니다. 다운로드 된 스냅 샷은 오프라인 복원 또는 마이그레이션 목적으로 사용할 수 없습니다. * 백업은 잃지 않았습니다. Azure에 저장된 언더리 백업 artifacts는 intact 및 올바르게 크기로 유지됩니다. 문제는 다운로드 경로에 엄격히, 백업 캡처 또는 저장 과정에서. * 콘솔을 통해 복원은 비범했다. In-platform 복원 작업 \(자치 파일 다운로드 반대)는 영향을받은 다운로드 경로를 통해 직접 백업 데이터를 액세스하기 때문에 기능을 계속합니다. # 우리는 무엇을하고 있습니다. 우리는 문제를 해결하기 위해 여러 단계를 수행하고 재발력을 방지하기 위해 안전한 가드를 구현했습니다. * Credential 수정 배포. 우리는 즉각 모든 영향을받는 인스턴스에 대한 스냅 샷 다운로드를 복원 생산에 Azure 자격 증명 문제를 수정했습니다. * unintended credential 교체 방지. 코드 변경은 모든 배포에 Azure credential 교체를 트리거 한 논리를 뒤집기 위해 제출되었습니다. 이것은 미래의 배포가 기존의 자격 증명을 무효하지 않을 것이라는 것을 보증합니다. 이는 초기 사건과 재발견을 모두 일으키는 메커니즘이었습니다. * Ongoing 감시. Azure Snapshot 다운로드를 모니터링하고 모든 계층을 통해 안정적인 상태를 확인합니다. 우리는 그들의 다운로드가 예상된 파일 크기를 반환한다는 것을 확인하기 위하여 영향을 미쳤습니다. 이 변경 주소는 즉시 symptom 및 중단 배포 행위를 허용하는 문제 재발

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 10월 6일 오전 8:07 UTCidentified

   AuraDS의 스냅샷에서 복원하려고 시도할 때 문제가 발견되었습니다. 우리는 해결 준비가되어 있으며 곧 배포합니다. 대신 백업에서 복원 할 수 있습니다.

2. 2026년 10월 6일 오전 9:07 UTCidentified

   우리는 명확하게 루트 원인을 확인하고이 문제에 대한 수정에 계속.

3. 2026년 10월 6일 오전 10:03 UTCidentified

   우리는이 문제에 대한 수정을 계속합니다.

4. 2026년 10월 6일 오후 12:14 UTCidentified

   수정이 배포되고 영향을받는 고객에게 곧 롤됩니다.

5. 2026년 10월 6일 오후 1:35 UTCmonitoring

   수정은 밖으로 구르고 영향을받는 고객은 점차적으로 복원 된 기능을 볼 수 있습니다.

6. 2026년 10월 6일 오후 2:04 UTCresolved

   우리는 모든 고객에게 수정을 배포했습니다.

7. 2026년 10월 26일 오전 8:51 UTCpostmortem

   # 무슨 일이 있었는지 Neo4j Aura 스냅 샷의 중앙 관리 구성 요소에 대한 소프트웨어 결함은 AWS에서 호스팅되는 AuraDS Professional 및 AuraDS Enterprise 인스턴스에 실패합니다. 복원이 요청되었을 때, 시스템은 잘못된 리소스 유형과 오류를 반환하는 인스턴스를 찾습니다. 사건은 월요일, 05 Oct 2026 21:52 UTC에 선언되었습니다. 우리의 엔지니어링 팀은 루트 원인을 확인, 개발 및 검증 된 수정, 화요일에 생산에 배포, 06 Oct 2026 13:37 UTC. # 서비스 영향을받는 방법 영향은 AuraDS Professional 및 AuraDS Enterprise 인스턴스에 대한 복구 작업을 스냅 샷 할 수 있습니다. Aura Console 또는 Aura API를 통해 스냅샷을 복원할 수 없습니다. * 복원 시도는 오류를 반환하고, 스냅 샷 복원에 따라 작업 흐름을 혼란. * Instances는 이 사건을 통하여 유효합니다. 데이터 무결성은 영향을 미쳤습니다. 가득 차있고 수출한 백업에서 복원은 workaround로 유효합니다. # 우리는 무엇을하고 있습니다. * 우리는 AuraDS Professional 및 AuraDS Enterprise 스냅 샷 복원 및 생산에 대한 수정을 배치 한 Aura의 관리 층의 결함을 수정했습니다. * Deployment 파이프라인 최적화: 이 사건 도중, 배포 파이프라인은 순차적인 시험 인스턴스 생성 때문에 이상적이었습니다. 우리는 긴 수명 동안 대기 시간을 줄이기 위해 병렬화 테스트 인스턴스 생성을 평가했습니다. 이 개선은 시간을 단축하는 것을 목표로하고 향후 사건에 대한 수정을 검증하고 배송하는 데 걸리며, 고객의 영향 감소

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 9월 17일 오후 4:46 UTCinvestigating

   우리는 현재 Azure에서 Aura를 사용하여 고객을위한 생성, 삭제, 클론과 같은 특정 데이터베이스 운영에 영향을 미치는 문제의 인식입니다.

2. 2026년 9월 17일 오후 5:11 UTCidentified

   우리는 문제점을 확인하고 해결책으로 일하고 있습니다. 이번에는 Azure에서 Neo4j Aura를 사용하는 고객을위한 생성, 삭제 및 복제와 같은 특정 데이터베이스 작업이 계속되었습니다.

3. 2026년 9월 17일 오후 7:06 UTCmonitoring

   수정은 모든 영향을받는 환경에 배포되었습니다. 우리는 문제를 해결하기 위해 상황을 모니터링 할 것입니다.

4. 2026년 9월 17일 오후 7:55 UTCresolved

   수정을 배포한 후, 충격된 인스턴스, 조작용 메트릭 및 오류를 모니터링했습니다. 이 사건은 이제 해결되었습니다. post-mortem가 완료된 후 곧 사용할 수 있습니다.

5. 2026년 10월 16일 오후 4:23 UTCpostmortem

   # 무슨 일이 있었는지 목요일, 17 9월 2026일 at 13:52 UTC, concurrent 운영 간의 배포 시간 충돌은 핵심 Aura 구성 요소가 Azure 호스팅 인프라를 사용하여 제거하기 위해 인증 한 것으로 나타났습니다. 기존의 인증 토큰이 만료되면서, 구성 요소는 Azure에서 호스팅되는 일부 Aura 인스턴스에 대한 오류를 반환하고 특정 데이터베이스 작업에 영향을 미칩니다. 우리는 누락된 자격 증명에 오류를 추적, 새로운 것을 생성, 안전하게 저장, 그리고 18:39 UTC에 완료된 영향을받는 구성 요소의 롤링 배포를 수행. 부족 중 진행중인 데이터베이스 작성 요청의 작은 수는 불완전 상태에 남아 있고 수동 구제가 필요합니다. 이 완료되었습니다 19:48 UTC, 그리고 사건은 19:55 UTC에 해결되었습니다. # 서비스 영향을받는 방법 영향은 Azure에서 호스팅 한 Aura 인스턴스에 제한되었습니다. 다른 클라우드 공급자는 영향을 미치지 않았습니다. * **Database 운영:** 고객은 사고 창 중 일부 Azure 인스턴스에서 생성, 삭제 및 복제와 같은 특정 데이터베이스 작업을 수행 할 수 없습니다. 진전이 갇혀 있었고 수동으로 회복되었습니다. * ** 관리 가시: ** 일부 Azure 호스팅 인스턴스는 Aura 콘솔에서 일시적으로 보이지 않거나 관리되지 않았습니다. * **미터 간격:** 일부 Azure 인스턴스에 대한 미터 엔드 포인트는 영향을받는 기간 동안 미터 데이터에서 짧은 간격을 남겨 간헐적인 오류를 반환합니다. 이 데이터는 backfilled되지 않습니다. 이미 실행 된 Azure 인스턴스는 일반적으로 작업 부하를 봉사하기 위해 계속됩니다. # 우리는 무엇을하고 있습니다. 우리는 반복을 방지하고 우리의 응답을 개량하는 것을 돕는 뒤에 오는 단계를 가지고 있습니다: * ** 보증 및 통신 : ** 우리는 모니터링 및 경고를 개선하고 자동화 된 자격 검사를 평가하므로 문제가 감지되고 고객이 곧 알려집니다. * **완성 데이터베이스 생성에서 복구:** 우리는 인프라 통화가 partway를 통해 실패하면 데이터베이스 생성을 떠날 수있는 결함을 수정합니다. 그래서 시스템은 자체에 복구합니다. * ** 인증 리뷰:** 우리는이 구성 요소가 클라우드 제공 업체로 인증하는 방법을 검토 할 것이며, 실패의 단일 지점을 제거하고 충돌 재발의이 유형의 위험을 줄일 수 있습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 9월 16일 오전 8:50 UTCidentified

   지원 포털에 대한 우리의 서비스 제공 업체는 일부 정전을 경험하고있다. https://status.salesforce.com/products/Salesforce Services 새로운 지원 사례를 제출하는 데 문제가 있다면 [email protected]으로 이메일을 보내주십시오

2. 2026년 9월 16일 오전 9:16 UTCidentified

   우리의 지원 포털 공급자는 여전히 문제점을 해결하기 위해 일하고 있습니다. 세부 정보보기 https://status.salesforce.com/incidents/20004433

3. 2026년 9월 16일 오전 10:11 UTCidentified

   우리의 지원 포털 공급자는 문제를 해결하기 위해 계속. 세부 정보보기 https://status.salesforce.com/incidents/20004433

4. 2026년 9월 16일 오전 11:30 UTCmonitoring

   수정은 밖으로 구르고 포털은 시간이 지남에 오류에 의해 덜 영향을 받아야한다. 세부 정보보기 https://status.salesforce.com/incidents/20004433

5. 2026년 9월 16일 오후 12:29 UTCmonitoring

   우리의 지원 포털 공급자는 해결을 계속합니다.

6. 2026년 9월 16일 오후 2:31 UTCresolved

   수정이 배포되고 모든 기능이 복구되어야합니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 9월 9일 오후 12:31 UTCinvestigating

   우리는 현재 Aura 콘솔 console.neo4j.io 및 API api.neo4j.io에 영향을 미치는 문제점을 조사하고 있습니다

2. 2026년 9월 9일 오후 12:54 UTCidentified

   우리는 문제점의 근원을 확인하고 해결책에 현재 일하고 있습니다.

3. 2026년 9월 9일 오후 1:10 UTCidentified

   우리는 문제를 해결하기 위해 계속.

4. 2026년 9월 9일 오후 1:26 UTCidentified

   우리는 좋은 진전을 만들고 문제가있는 분대를 회복하고 있습니다.

5. 2026년 9월 9일 오후 1:36 UTCmonitoring

   우리는 수정을 배포하고 영향을받는 서비스는 복구됩니다.

6. 2026년 9월 9일 오후 1:39 UTCresolved

   모든 영향을받는 구성 요소는 이제 완전히 복구됩니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 9월 3일 오후 4:43 UTCinvestigating

   우리는 현재이 문제를 조사하고 있습니다.

2. 2026년 9월 4일 오전 10:23 UTCidentified

   문제는 식별되어, 인스턴스는 현재 검토 된 인스턴스에 영향을 미칩니다.

3. 2026년 9월 4일 오후 3:36 UTCresolved

   모든 인스턴스를 사용할 수 있습니다, 수동 단계는 나머지 작은 수의 인스턴스를 막지 못했습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 8월 20일 오후 3:49 UTCinvestigating

   우리 팀은 Aura 인스턴스의 메트릭을 수집하는 문제를 발견했습니다. 이것은 미터 가시성 및 운송에 영향을 미칠 것입니다. 우리는 현재 문제를 조사하고 있습니다.

2. 2026년 8월 20일 오후 4:48 UTCinvestigating

   우리는 Aura 미터 문제를 조사 계속합니다.

3. 2026년 8월 20일 오후 7:10 UTCresolved

   마지막 업데이트 이후, 조사가 이동했다. 문제가 확인되었으며, 분해에서 복구 된 서비스로 모니터링했습니다. 우리는 문제가 해결되었습니다.

4. 2026년 9월 17일 오전 10:09 UTCpostmortem

   # 무슨 일이 있었는지 목요일, 20 8월 2026 14:58:00 UTC, 우리의 메트릭스 ingestion 파이프라인은 Google Managed Prometheus \ (GMP \)에 데이터를 보낼 때 높은 수출 실패를 경험하기 시작했다. 밑면 원인은 Google Cloud Platform 서비스 사건이었습니다. 'us-west1' 지역은 메트릭 컬렉션 인프라에 의해 사용되는 수출 경로를 방해했습니다. 결과적으로, 미터 수출 큐는 생산 환경의 하위 세트를 통해 구축 시작. 실패는 주로 네트워크 타임 아웃으로 나타나는 것은 GMP에 미터 데이터를 전달하려고 할 때, 영향을받는 클러스터에 대한 정상적인 섭취를 방지. 우리의 엔지니어링 팀은 영향을받는 시스템의 지리적 농도를 확인했습니다. AWS `us-west-2`, Google Cloud `us-west1`, Azure `westus2` - Oregon 영역의 인프라를 통해 모든 경로. GCP 지역 사건이 Google에 의해 mitigated되면, 수출 과실은 배수하기 시작되었습니다. # 서비스 영향을받는 방법 영향은 ** 미터 가시성 ** Aura 환경의 하위 세트에 대한. 약 45명의 고객 환경이 영향을 미쳤습니다. 데이터베이스의 메트릭 데이터가 사건 창에서 모니터링 플랫폼에 영향을 미쳤습니다. 가장 영향을받는 지역은 AWS `us-west-2`이며, Google Cloud `us-west1`와 Azure `westus2`에 대한 추가적인 영향을 받았습니다. 이 지역의 데이터베이스가있는 고객은 사고의 지속 시간 동안 미터 대시 보드 및 모니터링 데이터에서 갭을 경험할 수 있습니다. Core Database Operation — reads, writes, 가용성을 포함한 — ** 영향을받지 못했습니다**; 성능 메트릭스의 컬렉션과 가시성만 혼란했습니다. Google은 지역 문제, 메트릭 ingestion 이력서 및 누락 된 데이터의 백 로그를 처리했습니다. # 우리는 무엇을하고 있습니다. 우리는이 사건의 철저한 검토를 실시하고 우리의 탄력과 응답 기능을 개량하기 위하여 뒤에 오는 단계를 가지고 있습니다: * **Improved Observability 대시보드 **: 우리는 우리의 미터 수출상 대쉬보드를 강화하고, 더 빠른 시정을 queue 건강과 수출 과실 비율로 제공해서, 유사한 문제점의 더 빠른 탐지 그리고 진단을 가능하게 합니다. * ** 경고 집계 **: 우리는 다중 클러스터에 영향을 미치는 지역 사건이 단일 상관 관계 사건으로 표면 처리하고 적절한 심각성 및주의로 대우되는 자동 경고 그룹을 구현하고 있습니다. * ** 소화 오류율에 대한 신속한 경고 : ** 우리는 높은 GMP ingestion 오류율에 화재가 발생하기 위해 헌신적 인 경고를 추가하고 수출 업체의 큐에 도달 용량 전에 먼저 신호를 제공합니다. 이러한 개선은 감지 시간을 줄이고 사고를 단순화하고 향후 업스트림 공급 업체의 붕괴에 대한 지표 파이프라인을 강화하도록 설계되었습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 8월 5일 오후 5: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. 2026년 8월 5일 오후 7: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. 2026년 8월 6일 오전 12: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. 2026년 8월 6일 오전 7: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. 2026년 8월 6일 오전 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. 2026년 8월 6일 오후 2: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. 2026년 8월 7일 오전 1:15 UTCidentified

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

8. 2026년 8월 7일 오전 1: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. 2026년 8월 7일 오전 9:44 UTCidentified

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

10. 2026년 8월 7일 오후 1:49 UTCmonitoring

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

11. 2026년 8월 7일 오후 3:34 UTCresolved

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

1. 2026년 7월 23일 오전 10:52 UTCinvestigating

   우리는 현재이 시간에 문제점을 조사하고 있습니다.

2. 2026년 7월 23일 오전 11:08 UTCinvestigating

   우리는 엔지니어링 팀과 일하고 현재 시간에 조사와 진행 상황을 만들기.

3. 2026년 7월 23일 오전 11:24 UTCinvestigating

   우리는 엔지니어링 팀과 협력하여 현재 시간에 조사와 진행 상황을 계속합니다.

4. 2026년 7월 23일 오전 11:38 UTCidentified

   우리는 현재의 문제점의 원인을 확인하고 현재 해결에 적극적으로 노력하고 있습니다.

5. 2026년 7월 23일 오전 11:53 UTCidentified

   우리는 해결의 첫 번째 부분을 배포하고 전체 솔루션을 압연에 적극적으로 작업하고 있습니다. 우리는 지금부터 1 시간의 순서에 ETA를 기대합니다.

6. 2026년 7월 23일 오후 12:11 UTCidentified

   우리는 영향을받은 인스턴스의 하위 세트를 확인하고이 시간에 수정을 계속 배포합니다.

7. 2026년 7월 23일 오후 12:32 UTCidentified

   우리는 구성 수정을 배포하고 현재 인스턴스의 하위 집합을 해결하기 위해 노력하고 있습니다.

8. 2026년 7월 23일 오후 12:49 UTCidentified

   설정 수정을 통해, 우리는 여전히 영향을받은 인스턴스의 하위 집합을 해결하기 위해 계속됩니다.

9. 2026년 7월 23일 오후 2:07 UTCidentified

   우리는 여전히 영향을 미칩니다.

10. 2026년 7월 23일 오후 2:27 UTCidentified

    우리는 여전히 영향을받는 인스턴스의 하위 집합을 해결합니다.

11. 2026년 7월 23일 오후 2:44 UTCmonitoring

    우리는 여전히 영향을받는 인스턴스의 하위 집합을 해결합니다.

12. 2026년 7월 23일 오후 3:03 UTCmonitoring

    AuraDB 가상 전용 클라우드 및 AuraDB Business Critical는 이제 모두 고정되어야합니다. 우리는 여전히 AuraDB Professional 및 Free에 영향을 미치는 인스턴스의 하위 세트를 해결합니다.

13. 2026년 7월 23일 오후 3:29 UTCmonitoring

    우리는 여전히 AuraDB Professional 및 Free에 영향을 미치는 인스턴스의 하위 세트를 해결합니다.

14. 2026년 7월 23일 오후 3:57 UTCmonitoring

    우리는 여전히 AuraDB Professional 및 Free에 영향을 미치는 인스턴스의 하위 세트를 해결합니다.

15. 2026년 7월 23일 오후 4:32 UTCmonitoring

    우리는 여전히 AuraDB Professional 및 Free에 영향을 미치는 인스턴스의 하위 집합을 해결하기 위해 계속

16. 2026년 7월 23일 오후 5:01 UTCmonitoring

    우리는 여전히 AuraDB Professional 및 Free에 영향을 미치는 인스턴스의 하위 세트를 수정합니다

17. 2026년 7월 23일 오후 5:31 UTCmonitoring

    우리는 여전히 AuraDB Professional 및 Free tiers의 영향을받은 인스턴스의 작은 하위 세트를 수정합니다.

18. 2026년 7월 23일 오후 6:07 UTCmonitoring

    모든 AuraDB Professional 인스턴스에 문제가 해결되었습니다. Aura 무료 여전히 영향을받을 수 있습니다. 우리는 계속 모니터링하고 나머지 데이터베이스를 수정합니다.

19. 2026년 7월 23일 오후 7:39 UTCmonitoring

    우리는 여전히 영향을받는 무료 인스턴스의 작은 하위 세트를 수정합니다.

20. 2026년 7월 24일 오전 6:00 UTCmonitoring

    우리는 더 많은 문제에 대해 긴밀하게 상황을 모니터링하고 있습니다.

21. 2026년 7월 24일 오전 8:30 UTCmonitoring

    우리는 더 많은 문제를 모니터링하고 있습니다.

22. 2026년 7월 24일 오후 12:59 UTCmonitoring

    모든 식별 된 인스턴스는 고정되어 계속 모니터링합니다. 더 많은 문제에 대한 고객 지원 문의.

23. 2026년 7월 24일 오후 3:56 UTCresolved

    모든 수정이 배포되고 문제가 해결되었습니다.

24. 2026년 7월 29일 오후 9:58 UTCpostmortem

    ###**What 일어난 일에 태어난** 목요일, 7 월 23, 2026 10:33 UTC 구성 변경은 데이터베이스 인스턴스에 대한 메모리 할당이 계산 된 방법을 변경 Aura에 배포되었습니다. 결과적으로, 인스턴스의 하위 설정은 충분한 메모리를 받고, 일부 데이터베이스 인스턴스를 사용하지 않거나 업데이트를 완료 할 수 없습니다. 조정 된 메모리 할당은 메모리 리소스로 인해 반복적으로 재시작 할 데이터베이스 인스턴스를 발생하거나 updating을 갇혀있다. 이 문제는 여러 클라우드 공급자와 여러 제품 계층을 통해 인스턴스를 영향을 미쳤습니다. 문제가 확인되면 즉시 구성 변경을 리디렉션하고 잘못된 구성을 수신하여 추가 인스턴스를 방지합니다. 수정된 구성은 7월 23, 2026 11:56 UTC의 목요일에 의해 생산에 배치되었습니다. 그러나, 데이터베이스 인스턴스는 이미 잘못된 구성이 필요한 개별 복구 작업을 정상적인 작동으로 돌아갈 수 있었다. 7월 23일 (목) 2026 17:59 UTC에 의해 모든 알려진 고객에 대한 데이터베이스 인스턴스가 복구되었습니다. 모니터링은 다음 날을 통해 계속, 금요일에 완전히 해결과 함께, 7월 24, 2026 16:30 UTC. # # # ** 서비스가 영향을받는 방법 ** 1 차적인 고객 영향은 몇몇 AuraDB 데이타베이스 인스턴스가 사용되지 않았거나 degraded 국가를 입력했습니다. Affected 인스턴스는 일상 소프트웨어 업데이트를 완료 할 수 없었다, 일부 경우에, 반복적으로 다시 시작되어 충분한 메모리가 할당되었다. * ** 서비스 가용성: ** 서비스 계층에 의해 변화되는 고객 충격. AuraDB Professional 인스턴스, 높은 가용성을 제공하지 않는, 가장 큰 수준의 서비스 중단 경험, 하위 세트가 사용되지 않고 읽기 또는 쓰기를 처리 할 수 없습니다. AuraDB Business Critical 및 Virtual Dedicated Cloud \ (VDC \) 인스턴스에 영향을 미치는 영향은 일반적으로 서비스 가용성이 유지되는 동안 오류 허용 오차의 임시 손실에 제한되었습니다. 더 작은 경우에, Business Critical 및 VDC 인스턴스도 사용할 수 없습니다. * **Stuck 업데이트**: 추가 인스턴스는 사용할 수 있지만 "Updating"상태에 갇혀있어 크기 또는 구성 변경과 같은 고객 개시 작업을 차단했습니다. * **Cross-platform 범위 **: 3개의 지원된 클라우드 공급자 및 다수 지구를 경간하는 충격은, 고객에게 세계적으로 영향을 미치. 고객 지원 사례가 제기되었고 우리 팀은 우선순위에 영향을 미쳤습니다. AuraDB 인스턴스의 대다수는 일반적으로 작동하도록 계속됩니다. 고객 영향은 각 영향 받은 인스턴스의 구성 반전 및 대상 수동 복구를 통해 완전히 mitigated. ###**지금 무엇을 하고 있는가?** 우리는이 사건의 철저한 분석을 수행하고 다음 작업을 확인했습니다. * **이전 ** * **부설 유효성 검사:** 우리는 더 나은 구성 변경을 식별하기 위해 우리의 릴리스 검증 과정을 강화하고 있습니다. * ** 부품 디코딩 **: 우리는 배포에 포함되지 않은 변경의 위험을 줄이기 위해 구성 요소 배포의 sequencing 개선을 평가하고 있습니다. ***Progressive 롤아웃 전략**: 우리는 영향을받는 구성 요소에 대한 롤아웃 프로세스를 검토하고 다른 중요한 구성 요소에 사용되는 롤아웃 컨트롤과 함께 라인에 가져 왔습니다. * **멸종** * ** 경고 **: 우리는 실패율에서 비정상적인 증가를 검출하기 위하여 우리의 감시를 강화하고 있습니다 \ ( 결함 포용력 또는 가용성의 손실과 같은) 빨리 그리고 믿을 수 있습니다. ***심사** * **안전 설정 배포:** 우리는 생산 구성 변경이 배포되는 방법을 개선하기 때문에 그들은 더 넓은 소프트웨어 릴리스를 필요로하지 않고 더 빨리 재생할 수 있습니다. ***Faster 수동 복구 도구**: 우리는 우리의 복구 도구를 개선하여 시간을 식별하고 수동으로 영향을받는 인스턴스를 복구해야합니다. 우리는 이 사건이 발생하고 영향을받는 고객에 대한 영향을 미칩니다. 우리는 즉각적인 정확한 행동을 완료하고 위의 더 긴 기간 개선은 이미 미래에 유사한 사고의 영향을 줄이기 위해 노력합니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 10일 오후 5:18 UTCinvestigating

   우리는 현재 Aura 콘솔에 영향을 미치는 문제를 조사하고 있습니다. 일부 고객은 인스턴스를 볼 수 없습니다. 이 문제는 Aura가 달려있는 제 3 자 서비스의 실패에 의해 발생합니다. Affected 인스턴스는 일반적으로 실행하고 데이터베이스 연결은 영향을 미치지 않습니다. 우리의 팀은 적극적으로 문제를 조사하고 있습니다.

2. 2026년 7월 10일 오후 5:23 UTCinvestigating

   이 문제를 조사하고 있습니다.

3. 2026년 7월 10일 오후 5:51 UTCmonitoring

   Aura가 정상 작동을 복원하고 Neo4j Aura 시스템이 복구 된 제 3 자 서비스. 우리의 팀은 Aura 콘솔을 확인하기 위해 문제를 적극적으로 모니터링하고 예상대로 수행됩니다.

4. 2026년 7월 10일 오후 7:23 UTCresolved

   서비스는 운영되고 더 이상 중단이 예상되지 않습니다.

5. 2026년 7월 27일 오전 4:28 UTCpostmortem

   ## 어떤 Happened Aura 콘솔 및 기타 Aura 구성 요소는 16 : 14 UTC에서 2026-07-10에 대한 중단을 경험했으며 실패 및 충돌 루프로 발생했습니다. 고객 세그먼트는 인스턴스에 대한 가시성 문제를 직면했습니다. Aura와 통합된 외부 제3자 서비스에서 정전이 발생했습니다. Crucially, 데이터베이스 연결은 uncompromised 남아 있고, 영향 받은 인스턴스는 정상 작동을 계속했습니다. LaunchDarkly 서비스는 문제를 해결하기 위해 복원되었습니다. ## 서비스 영향을받는 방법 Aura 콘솔, 경험있는 붕괴를 포함한 여러 Aura 구성 요소. 사용자는 데이터베이스 관련 페이지 및 작업에 HTTP 500 오류를 발생했지만 조직 및 프로젝트는 여전히 액세스 할 수 있습니다. 특정 데이터베이스 인스턴스에 직접 연결이 완전히 unaffected 제어 비행기는 사용자가 API 또는 Aura 콘솔을 통해 인스턴스에 대해 설정, 삭제, 크기를 만들 수 없다는 것을 의미하지 못했습니다. Existing 인스턴스, 그러나, 운영 유지. 이 문제는 LaunchDarkly에 정전에 기인하고 우리의 서비스는 시작 도중 확실한 실패를 취급하지 않았습니다. 모든 영향을받는 시스템은 17:07 UTC에서 2026-07-10에 의해 정상 작동에 반환 ## 우리가 지금 하는 것은 Neo4j Engineering 팀은 뿌리 원인과 복원 된 서비스를 신속하게 진단했습니다. 이 사건을 평가하기 위해, 우리는 미래 해결책과 mitigate recurrence 위험을 가속하는 중요한 지역을 확인했습니다: * Analyzed 키 사고 메트릭, 경고에 초점을 맞추고 응답 효율을 가속화하기위한 기회를 식별 할 수 있습니다. * 투명 로깅을 통해 빠른 루트 분석, 사건 관리 도구를 통해 원활한 정렬, 및 데이터 비행기 연결 intact 유지 여러 구성 요소의 탄력성, 우아한 분해를 통해 성공적인 결과를 강조하는 종합적인 복도 강조 * Actively development more graceful fallback default for feature flags to safeguard core operations during 공급 업체 다운타임 * 진보된 계획, chaos 기술설계 연습을 통합해서 건축 탄력을 강화하고, 생산 수준 결함 주입 시험은 preemptively uncover 및 mitigate 잠재적인 실패 경로에 * 연산자 기능 플래그 캐싱의 논리 제한, 연산자에 대 한 필요성을 황화 하 고 국소를 저장 하 고 외부 종점이 실패 하는 경우 작업 오염을 보존 하 게 로컬로 플래그를 저장.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 6월 30일 오후 2:45 UTCidentified

   CREATE VECTOR INDEX가 오류 51N31로 실패 오류: 시스템 구성 또는 작업 예외 - 지원되지 않음. 제공된 설정으로 벡터 인덱스를 작성하는 것은 V2026 02에서 지원되지 않습니다. 작업에 필요한 버전은 V2026 06입니다. DBMS를 업그레이드하십시오. VECTOR INDEX는 새로운 지수에만 영향을 미칩니다. 모든 벡터 인덱스는 일반적으로 작동하려면 2026-06-30 이전에 작성했습니다.

2. 2026년 6월 30일 오후 3:41 UTCidentified

   이 문제를 해결하기 위해 수정을 배포하고 진행 상황을 곧 업데이트 할 예정입니다.

3. 2026년 6월 30일 오후 4:05 UTCmonitoring

   수정은 압연하고 잘 진행합니다. 우리는 진행 상황을 업데이트합니다.

4. 2026년 6월 30일 오후 5:45 UTCresolved

   수정은 모든 영향 받은 인스턴스에 완전히 배포되었습니다. 이 사건은 이제 해결되었습니다.

5. 2026년 7월 20일 오전 8:40 UTCpostmortem

   ## 어떤 Happened 문제는 08:00 UTC에서 2026-06-30에 버전 2026.06의 배포에 따라 확인되었습니다. 업그레이드 된 Aura 인스턴스에서 `CREATE VECTOR INDEX`를 실행하는 경우 시스템 예외를 유발했습니다. 이 인덱스 생성의 실패는 저장과 커널이 가동을 지원하기 위해 추가 업데이트를 요구했기 때문에 발생했습니다. 이 문제는 새로운 인덱스의 생성에만 영향을 미쳤습니다. 기존 벡터 인덱스는 영향을 미치지 않습니다. 2026-06-30에 09:00 전에 생성 된 모든 벡터 인덱스는 일반적으로 일하고 계속되었습니다. ## 서비스 영향을받는 방법 버전의 롤아웃에 따라 2026.06, CREATE VECTOR INDEX 문의 실행이 실패, 새로운 벡터 인덱스를 추가하는 의존 응용 프로그램에 영향을 미치는 영향. Affected client는 오류를 받았습니다. 제공된 설정으로 벡터 인덱스를 변환하는 것은 V2026\ 02에서 지원되지 않습니다. 작업에 필요한 버전은 V2026\ 06입니다. DBMS 를 업그레이드하십시오. Existing indexes \(이 사건 이전에 생성) 및 기타 쿼리는 완전히 비난하고 완전히 기능합니다. ## 우리가 지금 하는 것은 Neo4j 팀은 Cypher planner의 버그로 루트 원인을 확인하고 코드 수정으로 문제를 해결했습니다. 이 수정은 모든 영향을받은 Aura 인스턴스에 배포되었으며 오류를 완전히 해결했습니다. 미래 발생을 방지하기 위해, 우리는 우리의 모니터링 및 경고 시스템을 강화하고 롤아웃이 발생하기 전에, 특히 노화 환경에서 유사한 문제를 감지하기 위해. 동시에, 우리는 고객 영향과 회복 시간을 최소화하기 위해 배포 프로세스를 정제하고 있습니다. 또한, 벡터 인덱스 생성과 같은 중요한 작업을 위해 특별히 자동화된 포스트 업그레이드 검증 테스트를 구현하는 옵션입니다

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 6월 23일 오전 11:25 UTCidentified

   Aura 콘솔은 일부 간헐적인 오류를 경험하고있다 : "우리 시스템은 지금 문제를 경험하고있다. 문제가 발생할 경우 다시 또는 연락처 지원 시도." 이것은 콘솔에서 항해에 더 이상 다시로드하거나 기다릴 수 있습니다. Operations와 Aura API는 비범한 유지 우리는 해결에 적극적으로 노력하고 있습니다

2. 2026년 6월 23일 오후 1:03 UTCidentified

   문제 해결을 계속하고 있습니다

3. 2026년 6월 23일 오후 1:39 UTCidentified

   이 문제를 해결하기 위해 계속 노력하고 있습니다.

4. 2026년 6월 23일 오후 3:43 UTCmonitoring

   우리는 변화를 배포하고 있습니다. 우리는 감시하고 새롭게 할 것입니다.

5. 2026년 6월 23일 오후 7:27 UTCmonitoring

   배포 된 변경을 모니터링 할 수 있습니다. 다음 업데이트 예상 6/24/2026 10am UTC.

6. 2026년 6월 24일 오전 9:14 UTCmonitoring

   우리는 검사하고 문제가 이제 완전히 해결된다는 것을 확인합니다.

7. 2026년 6월 24일 오전 9:14 UTCresolved

   이 사건은 해결되었습니다.

8. 2026년 7월 10일 오후 2:50 UTCpostmortem

   ## 어떤 Happened 1월 22일 오후 12:00 UTC에, 사용자는 Aura 콘솔 디스플레이의 중간 오류 배너를 발생, "우리는 문제가있다. 다시 시도하십시오. 콘솔 API 엔드포인트에서 500 오류와 함께 발생했습니다. 이 붕괴는 TLS Handhake 과정에서 내부 API 타이밍에 의해 일시적으로 발생, 일반적으로 약 10 초 이내에 해결하거나 페이지를 새로 고침 ## 서비스 영향을받는 방법 Aura 콘솔 및 Aura API는 Aura 콘솔 UI 내의 간헐적 오류 배너로 나타낸 성능이 경험했습니다. 조사는 콘솔 API 내에서 높은 CPU 사용 및 throttling으로 루트 원인을 확인했습니다. 이 문제는 주로 큰 단체 목록과 비싼 재건축가 요청을 반복하여 구동되었습니다. 문제를 해결하기 위해, 대상 수정은 Aura 콘솔과 Aura API 모두 성공적으로 배포되었습니다. 이것은 작업 헤드룸을 늘리고 안정성을 보장합니다. ## 우리가 지금 하는 것은 다음과 같은 민감하고 유능한 측정은 유사한 사건의 likelihood를 줄이기 위해 구현되었습니다. * 내부 API 로그 데이터에 기반한 요청 드롭을 관찰하기 위해 모니터링 대시보드 개발하여 자동화된 모니터링 및 경고를 구현하기 위해 * 높은 자원 소비를 완화하고 API 안정성을 개량하기 위하여 paginated reconciler 요구 사이에서 staggered 지연을 실행하는 * 성능 향상을 위한 향상된 인프라 인식 리소스 계산 * 서비스 계층을 기반으로 한 쿼리에 대한 새로운 필터를 도입하여 reconciler에 의해 수행 된 각 통화의 CPU 오버 헤드를 최적화 * API 호출을 최적화하기 위해 중복 요청 미들웨어 처리를 비활성화

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 5월 26일 오후 6: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. 2026년 5월 26일 오후 7: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. 2026년 5월 26일 오후 11:06 UTCresolved

   This incident has been resolved.

4. 2026년 6월 9일 오후 4: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. 2026년 3월 6일 오전 10:18 UTCidentified

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

2. 2026년 3월 6일 오전 10:24 UTCmonitoring

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

3. 2026년 3월 6일 오전 10:25 UTCresolved

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

4. 2026년 3월 30일 오전 7: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. 2026년 3월 3일 오후 9: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. 2026년 3월 4일 오전 1:39 UTCidentified

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

3. 2026년 3월 4일 오전 4:52 UTCidentified

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

4. 2026년 3월 4일 오후 2:07 UTCmonitoring

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

5. 2026년 3월 4일 오후 3:19 UTCresolved

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

6. 2026년 4월 8일 오전 6: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. 2026년 3월 2일 오후 7: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. 2026년 3월 3일 오후 3: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. 2026년 3월 6일 오후 2: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. 2026년 3월 6일 오후 4: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. 2026년 3월 29일 오후 3: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)