Anaplan 장애 기록

1. 2026년 9월 7일 PM 1:26 UTCinvestigating

   우리는 현재 Anaplan 플랫폼에 액세스 할 수있는 고객의 능력에 영향을 미치는 문제를 조사하고 있습니다. 우리는 가능한 한 빨리이 문제를 해결하기 위해 노력하고 30 분 또는 해결시 업데이트를 제공합니다.

2. 2026년 9월 7일 PM 1:33 UTCinvestigating

   우리는 문제점의 가능성이 원인을 확인하고, 우리는 가능한 한 빨리 회복 서비스에서 지금 집중됩니다. 현재, 우리는 아직 해결 시간이 없습니다. 우리는 30 분 또는 해결책에 더 갱신을 제공할 것입니다.

3. 2026년 9월 7일 PM 1:35 UTCmonitoring

   서비스는 이제 복원되었습니다; 당신은 지금 정상 활동을 이력서 할 수 있어야합니다. 우리는 플랫폼을 계속 모니터링하여 추가 문제가 발생하지 않도록합니다. 질문, 우려 사항이 있거나 문제가 계속되는 경우, Anaplan Support에 연락하는 것을 망설이지 마십시오. 우리는이 상황을 완전히 해결하기 위해 최종 업데이트를 제공 할 것입니다.

4. 2026년 9월 7일 PM 1:46 UTCresolved

   우리는 문제가 해결되었는지 확인했습니다. 우리는이 문제에 영향을 미칠 수 있습니다. 우리는 이 문제를 통해 일하면서 인내와 파트너십을 평가합니다. 우리는 우리의 상태 페이지에 공유될 상세한 뿌리 원인 분석 (RCA)를 가진 7 영업일 안에 위로 따를 것입니다. 질문이나 우려 사항이 있으시면 Anaplan Support에서 연락 주시기 바랍니다.

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

1. 2026년 9월 3일 PM 2:56 UTCinvestigating

   우리는 현재 Anaplan 플랫폼에 액세스 할 수있는 고객의 능력에 영향을 미치는 문제를 조사하고 있습니다. 우리는 가능한 한 빨리이 문제를 해결하기 위해 노력하고 30 분 또는 해결시 업데이트를 제공합니다.

2. 2026년 9월 3일 PM 3:12 UTCidentified

   우리는 문제점의 가능성이 원인을 확인하고, 우리는 가능한 한 빨리 회복 서비스에서 지금 집중됩니다. 현재, 우리는 아직 해결 시간이 없습니다. 우리는 30 분 또는 해결책에 더 갱신을 제공할 것입니다.

3. 2026년 9월 3일 PM 3:16 UTCmonitoring

   서비스는 이제 복원되었습니다; 당신은 지금 정상 활동을 이력서 할 수 있어야합니다. 우리는 플랫폼을 계속 모니터링하여 추가 문제가 발생하지 않도록합니다. 질문, 우려 사항이 있거나 문제가 계속되는 경우, Anaplan Support에 연락하는 것을 망설이지 마십시오. 우리는이 상황을 완전히 해결하기 위해 최종 업데이트를 제공 할 것입니다.

4. 2026년 9월 3일 PM 6:04 UTCresolved

   우리는 문제가 해결되었는지 확인했습니다. 우리는이 문제에 영향을 미칠 수 있습니다. 우리는 이 문제를 통해 일하면서 인내와 파트너십을 평가합니다. 우리는 우리의 상태 페이지에 공유될 상세한 뿌리 원인 분석 (RCA)를 가진 7 영업일 안에 위로 따를 것입니다. 질문이나 우려 사항이 있으시면 Anaplan Support에서 연락 주시기 바랍니다.

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

1. 2026년 9월 1일 AM 9:49 UTCinvestigating

   Cloudworks 통합을 실행하는 고객의 능력에 영향을 미치는 문제를 조사하고 있습니다. 우리는 가능한 한 빨리이 문제를 해결하기 위해 노력하고 30 분 또는 해결시 업데이트를 제공합니다.

2. 2026년 9월 1일 AM 10:25 UTCinvestigating

   우리는이 문제를 조사 계속하기 때문에 당신의 인내심을 주셔서 감사합니다. 현재, 우리는 아직 해결 시간이 없습니다. 우리는 우리가 가능한 한 빨리이 문제를 해결하기 위해 노력으로 30 분마다 업데이트를 계속할 것입니다.

3. 2026년 9월 1일 AM 11:06 UTCinvestigating

   우리는이 문제를 조사하면서 지속적인 인내심을 주셔서 감사합니다. CloudWorks 통합에 영향을 미치는 문제를 확인했습니다. 이것은 최고 우선 순위를 유지하고, 우리는 아직 해결책에 예상한 시간이 없습니다. 우리는 우리가 가능한 한 빨리 해결하기 위해 노력으로 30 분마다 업데이트를 계속 공유 할 것입니다.

4. 2026년 9월 1일 AM 11:45 UTCidentified

   우리는이 문제를 조사하면서 지속적인 인내심을 주셔서 감사합니다. CloudWorks는 모든 지역에서 성공적으로 시작 및 완료를 관찰했습니다. 그러나 우리는 상황을 밀접하게 모니터링합니다. 우리는 우리가 가능한 한 빨리 해결하기 위해 노력으로 30 분마다 추가 업데이트를 공유 할 것입니다.

5. 2026년 9월 1일 PM 12:19 UTCmonitoring

   서비스는 이제 복원되었습니다; 당신은 지금 정상 활동을 이력서 할 수 있어야합니다. 우리는 플랫폼을 계속 모니터링하여 추가 문제가 발생하지 않도록합니다. 질문, 우려 사항이 있거나 문제가 계속되는 경우, Anaplan Support에 연락하는 것을 망설이지 마십시오. 우리는이 상황을 완전히 해결하기 위해 최종 업데이트를 제공 할 것입니다.

6. 2026년 9월 1일 PM 12:42 UTCresolved

   우리는 문제가 해결되었는지 확인했습니다. 우리는이 문제에 영향을 미칠 수 있습니다. 우리는 이 문제를 통해 일하면서 인내와 파트너십을 평가합니다. 우리는 우리의 상태 페이지에 공유될 상세한 뿌리 원인 분석 (RCA)를 가진 7 영업일 안에 위로 따를 것입니다. 질문이나 우려 사항이 있으시면 Anaplan Support에서 연락 주시기 바랍니다.

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

1. 2026년 9월 1일 AM 9:10 UTCinvestigating

   Cloudworks 통합을 실행하는 고객의 능력에 영향을 미치는 문제를 조사하고 있습니다. 우리는 가능한 한 빨리이 문제를 해결하기 위해 노력하고 30 분 또는 해결시 업데이트를 제공합니다.

2. 2026년 9월 1일 AM 9:28 UTCmonitoring

   서비스는 이제 복원되었습니다; 당신은 지금 정상 활동을 이력서 할 수 있어야합니다. 우리는 플랫폼을 계속 모니터링하여 추가 문제가 발생하지 않도록합니다. 질문, 우려 사항이 있거나 문제가 계속되는 경우, Anaplan Support에 연락하는 것을 망설이지 마십시오. 우리는이 상황을 완전히 해결하기 위해 최종 업데이트를 제공 할 것입니다.

3. 2026년 9월 1일 AM 9:47 UTCresolved

   우리는 문제가 해결되었는지 확인했습니다. 우리는이 문제에 영향을 미칠 수 있습니다. 우리는 이 문제를 통해 일하면서 인내와 파트너십을 평가합니다. 우리는 우리의 상태 페이지에 공유될 상세한 뿌리 원인 분석 (RCA)를 가진 7 영업일 안에 위로 따를 것입니다. 질문이나 우려 사항이 있으시면 Anaplan Support에서 연락 주시기 바랍니다.

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

1. 2026년 8월 27일 AM 10:22 UTCinvestigating

   우리는 현재 캐나다의 Anaplan 플랫폼에 액세스 할 수있는 고객의 능력에 영향을 미치는 문제를 조사하고 있습니다. 우리는 가능한 한 빨리이 문제를 해결하기 위해 노력하고 30 분 또는 해결시 업데이트를 제공합니다.

2. 2026년 8월 27일 AM 10:52 UTCinvestigating

   우리는이 문제를 조사 계속하기 때문에 당신의 인내심을 주셔서 감사합니다. 현재, 우리는 아직 해결 시간이 없습니다. 우리는 우리가 가능한 한 빨리이 문제를 해결하기 위해 노력으로 30 분마다 업데이트를 계속할 것입니다.

3. 2026년 8월 27일 AM 10:57 UTCidentified

   우리는 문제점의 가능성이 원인을 확인하고, 우리는 가능한 한 빨리 회복 서비스에서 지금 집중됩니다. 현재, 우리는 30 분 또는 해결책에 더 갱신을 제공할 것입니다.

4. 2026년 8월 27일 AM 10:58 UTCmonitoring

   서비스는 이제 복원되었습니다; 당신은 지금 정상 활동을 이력서 할 수 있어야합니다. 우리는 플랫폼을 계속 모니터링하여 추가 문제가 발생하지 않도록합니다. 질문, 우려 사항이 있거나 문제가 계속되는 경우, Anaplan Support에 연락하는 것을 망설이지 마십시오. 우리는이 상황을 완전히 해결하기 위해 최종 업데이트를 제공 할 것입니다.

5. 2026년 8월 27일 AM 11:08 UTCresolved

   우리는 문제가 해결되었는지 확인했습니다. 우리는이 문제에 영향을 미칠 수 있습니다. 우리는 이 문제를 통해 일하면서 인내와 파트너십을 평가합니다. 우리는 우리의 상태 페이지에 공유될 상세한 뿌리 원인 분석 (RCA)를 가진 7 영업일 안에 위로 따를 것입니다. 질문이나 우려 사항이 있으시면 Anaplan Support에서 연락 주시기 바랍니다.

6. 2026년 9월 3일 PM 3:52 UTCpostmortem

   에 8월 27, 2026, 에 10:22 UTC, 우리의 ca1의 일부 고객: 클라우드 - 캐나다 지역은 플랫폼에 액세스하는 간헐적인 문제 경험. 이 시간 동안 사용자는 로그인하려고 할 때 오류가 발생했습니다. 각 요청을 처리 한 구성 요소에 따라 영향을 미칩니다. 다른 사람들이 실패한 동안 몇 가지 요청이 성공했습니다. ** 루트 원인 ** 표준 시스템 업데이트 후, 캐나다 지역의 단일 트래픽 라우팅 구성 요소는 구성 다시로드 후 일관성 상태에 입력하고 제대로 라우팅 지침을 다시 구축하지 못했습니다. 구성 요소는 intermittently rejecting 또는 misdirecting 고객 요청을 시작했습니다. 구성 요소의 건강 검사는 가용성을 확인했지만 routing 구성의 정확성을 캡처하지 않았습니다. 그 결과, 그것은 적극적이고 지속적인 서빙 트래픽을 유지. 이 결과 몇 가지 요청에서 성공하는 동안 다른 사람이 unsuccessful, 그 구성 요소에 따라 연결. ** 복구 ** 우리의 엔지니어링 팀은 문제를 확인하고 즉각적인 조치를 취했습니다. 팀은 단일 트래픽 라우팅 구성 요소에 문제가 고립되어 재시작했습니다. 이 redistributed all incoming traffic throughout the 남은 건강한 구성 요소. 으로 11:08 UTC, 문제는 완전히 해결되었습니다. **차단 및 예방 조치 ** 우리는 반복을 방지하기 위해 다음 작업을 구현합니다. * 우리는 즉시 격리하는 우리의 교통 여정 성분에 건강 검사를 강하게 하고 구성 갱신 후에 제대로 유효하게 실패한 어떤 성분든지 재시작합니다. 트래픽을 계속하고 고객에 대한 간헐적 접근 실패를 일으킬 수 있는 고급 구성 요소를 방지합니다. * 우리는 개인적인 서비스 성분으로 더 과립상 시정을 제공하기 위하여 우리의 감시를 냉각하고 있습니다. 그들은 더 많은 고객에 영향을하기 전에 현지화 된 문제의 빠른 탐지를 가능하게합니다. 우리는이 문제에 영향을 미치는 영향에 대해 설명합니다. 우리는 비슷한 붕괴를 방지하기 위해 위의 개선에 최선을 다하고 있습니다. 질문이 있거나 우려 사항이 있으시면 [지원] (https://support.anaplan.com/) 팀에 문의하십시오.

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

1. 2026년 8월 15일 AM 3:27 UTCinvestigating

   Cloudworks 통합을 실행하는 고객의 능력에 영향을 미치는 문제를 조사하고 있습니다. 우리는 가능한 한 빨리이 문제를 해결하기 위해 노력하고 30 분 또는 해결시 업데이트를 제공합니다.

2. 2026년 8월 15일 AM 4:02 UTCinvestigating

   CloudWorks 통합에 영향을 미치는 Anaplan 플랫폼에 액세스 할 수있는 문제의 영향을 조사하고 있습니다. 우리는 가능한 한 빨리이 문제를 해결하기 위해 노력하고 30 분 또는 해결시 업데이트를 제공합니다.

3. 2026년 8월 15일 AM 4:31 UTCinvestigating

   우리는이 문제를 조사 계속하기 때문에 당신의 인내심을 주셔서 감사합니다. 현재, 우리는 아직 해결 시간이 없습니다. 우리는 우리가 가능한 한 빨리이 문제를 해결하기 위해 노력으로 30 분마다 업데이트를 계속할 것입니다.

4. 2026년 8월 15일 AM 5:03 UTCidentified

   우리는 문제점의 가능성이 원인을 확인하고, 우리는 가능한 한 빨리 회복 서비스에서 지금 집중됩니다. 현재, 우리는 아직 해결 시간이 없습니다. 우리는 30 분 또는 해결책에 더 갱신을 제공할 것입니다.

5. 2026년 8월 15일 AM 5:33 UTCidentified

   우리는 제 3 자 제공 업체와이 문제를 해결했습니다. 현재, 우리는 아직 해결 시간이 없습니다. 우리는 30 분 또는 해결책에 더 갱신을 제공할 것입니다.

6. 2026년 8월 15일 AM 6:13 UTCidentified

   우리는 EU2 지역에 영향을 미치는 접근 문제를 해결하기 위해 공급업체와 긴밀히 협력하고 있습니다. 우리의 조사를 통해, 우리는 EU-CENTRAL-1 지역에 대한 연결을 확인했습니다. 시작 7:33 오후 PDT 8 월 14, 우리의 공급 업체는 EU-CENTRAL-1 지역의 고객을위한 패킷 손실에 영향을 미치는 증가 된 패킷 손실. 영향을받는 위치는 프랑크푸르트 Equinix로 확인되었습니다. 진행중인 동안이 위치에 연결이 실패합니다. 우리는 우리의 납품업자를 가진 우선염 해결책 단계 계속합니다. 그러나, 가득 차있는 회복은 멀리 다수 시간일 것으로 예상됩니다. 우리는 우리가 가능한 한 빨리 서비스를 복원하기 위해 작동으로 60 분마다 업데이트를 제공 할 것입니다, 또는 추가 정보가 유효하면 빨리.

7. 2026년 8월 15일 AM 7:12 UTCidentified

   우리는 eu2 지역에 영향을 미치는 접근 문제를 해결하기 위해 공급 업체와 함께 일하고 있습니다. 우리는 또한 가능한 한 빨리 서비스를 복원하는 여러 경로를 탐구하고 있습니다. 우리의 납품업자와 협력은 계속됩니다; 그러나, 가득 차있는 회복은 멀리 다수 시간일 것으로 예상됩니다. 우리는 우리가 가능한 한 빨리 서비스를 복원하기 위해 작동으로 60 분마다 업데이트를 제공 할 것입니다, 또는 더 빨리 추가 정보가 사용되면

8. 2026년 8월 15일 AM 8:11 UTCidentified

   우리는 충격 영역에서 트래픽의 재 루트를 완료하고 모니터링 단계에 있습니다. 추가 업데이트는 30 분 안에 제공되며, 추가 정보가 유효하면 더 빨리 업데이트됩니다.

9. 2026년 8월 15일 AM 8:37 UTCresolved

   우리는 문제가 해결되었는지 확인했습니다. 우리는이 문제에 영향을 미칠 수 있습니다. 우리는 이 문제를 통해 일하면서 인내와 파트너십을 평가합니다. 우리는 우리의 상태 페이지에 공유될 상세한 뿌리 원인 분석 (RCA)를 가진 7 영업일 안에 위로 따를 것입니다. 질문이나 우려 사항이 있으시면 Anaplan Support에서 연락 주시기 바랍니다.

10. 2026년 8월 25일 PM 4:00 UTCpostmortem

    8 월 15, 2026, 03 : 16 UTC에서 08 : 23 UTC, 우리의 eu2의 고객 : 데이터 센터 - 독일 지역은 Anaplan 플랫폼에 대한 액세스를 방지하는 서비스 중단을 경험했습니다. 이 시간 동안, 지역 인프라 실패는 외부 서비스에 연결하기 위해 지역의 능력에 영향을 미치는, 플랫폼 가용성의 손실. ** 루트 원인 ** 붕괴는 독일 프랑크푸르트의 공급 업체의 제3자 시설에서 환경 고장에 의해 발생했습니다. 시설의 냉각 시스템의 누출은 중요한 네트워크 장비의 자동 안전 차단을 유발하는 현지화 과열로 이끌었습니다. 이스케이프는 또한 시설 내의 현지 전력 분배 시스템을 손상, 네트워크 장치를 비활성화. 이 결합된 힘 및 냉각 실패는 외부 주소를 해결하고 이 지역에 있는 outbound 요구를 완료해서 체계를 막습니다. ** 복구 ** 시설의 환경 조건이 입력되지 않는 영역 때문에, 우리의 공급 업체는 영향을받는 장비를 평가하고 수리하는 데 지연되었습니다. 그 결과, 우리의 엔지니어링 팀은 대체 지역 네트워크 경로를 통해 트래픽을 다시 시작, 임베디드 시설과 지역을 우회. 성공적으로 전체 외부 연결 및 이름 해상도를 복원하고 플랫폼 액세스는 완전히 08 : 23 UTC에 의해 복원되었습니다. 시설의 운영자 및 공급 업체는 8 월 18에 의해 확인 된 전체 복원과 함께 다음 일 동안 복구 작업을 계속했습니다. 우리는 공급 업체가 수리를 완료하면서 안정적인 서비스를 유지하기 위해 그 기간 동안 긴급 여정을 유지했습니다. **차단 및 예방 조치 ** 우리는 탄력을 강화하고 비슷한 붕괴의 위험을 줄일 수있는 다음 조치를 시행하고 있습니다. * 우리는 자동적으로 지역화 된 정전 중 지리적 위치를 변경하는 트래픽을 리디렉션하는 층을 추가하고, 수동 개입이 필요하지 않습니다. * 외부 해결사 경로가 사용할 수 없을 때, 외부 서비스에 대한 연결 손실은 더 이상 지역 이벤트가 발생했을 때 플랫폼 액세스를 방지하지 않습니다. * 우리는 우리의 제 3 자 시설 및 네트워크 제공 업체와 협력하여 중요한 전력 및 냉각 시스템의 표준을 검토하고 더 강한 예방적 보호가 장소에 있습니다. 우리는이 문제에 영향을 미치는 영향에 대해 설명합니다. 우리는 비슷한 붕괴를 방지하기 위해 위의 개선에 최선을 다하고 있습니다. 질문이나 우려가 있으시면 지원 팀에 문의하십시오.

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

1. 2026년 7월 29일 AM 11:06 UTCinvestigating

   우리는 현재 Anaplan 플랫폼에 액세스 할 수있는 고객의 능력에 영향을 미치는 문제를 조사하고 있습니다. 우리는 가능한 한 빨리이 문제를 해결하기 위해 노력하고 30 분 또는 해결시 업데이트를 제공합니다.

2. 2026년 7월 29일 AM 11:36 UTCinvestigating

   우리는 현재 Anaplan 플랫폼에 액세스 할 수있는 고객의 능력에 영향을 미치는 문제를 조사하고 있습니다. 우리는이 문제를 조사 계속하기 때문에 당신의 인내심을 주셔서 감사합니다. 현재, 우리는 아직 해결 시간이 없습니다. 우리는 우리가 가능한 한 빨리이 문제를 해결하기 위해 노력으로 30 분마다 업데이트를 계속할 것입니다.

3. 2026년 7월 29일 AM 11:41 UTCmonitoring

   서비스는 이제 복원되었습니다; 당신은 지금 정상 활동을 이력서 할 수 있어야합니다. 우리는 플랫폼을 계속 모니터링하여 추가 문제가 발생하지 않도록합니다. 질문, 우려 사항이 있거나 문제가 계속되는 경우, Anaplan Support에 연락하는 것을 망설이지 마십시오. 우리는이 상황을 완전히 해결하기 위해 최종 업데이트를 제공 할 것입니다.

4. 2026년 7월 29일 PM 12:51 UTCresolved

   우리는 문제가 해결되었는지 확인했습니다. 우리는이 문제에 영향을 미칠 수 있습니다. 우리는 이 문제를 통해 일하면서 인내와 파트너십을 평가합니다. 우리는 우리의 상태 페이지에 공유될 상세한 뿌리 원인 분석 (RCA)를 가진 7 영업일 안에 위로 따를 것입니다. 질문이나 우려 사항이 있으시면 Anaplan Support에서 연락 주시기 바랍니다.

5. 2026년 8월 7일 PM 6:56 UTCpostmortem

   On July 29, 2026, between 10:57 UTC and 11:53 UTC, customers in our us1: Data Center - US East, us2: Data Center - US West, eu1: Data Center - Netherlands, eu2: Data Center - Germany, eu4: Cloud - Europe, us5: Cloud - US East, us7: Cloud - US, and ap1: Cloud - Japan regions experienced degraded performance. This resulted in delayed model and workspace access, slow page load times, and slower logins across the platform, as well as delayed execution of CloudWorks™ integrations. All other regions were unaffected during this time.  **Root Cause**  The incident was triggered by an automated security software update deployed across our platform servers. This simultaneous update caused an unexpected, short-lived spike in storage activity that temporarily exceeded the storage systems' processing capacity. The resulting latency disrupted communication between internal metadata services and core system servers, causing the service connection pools to become unresponsive and preventing them from automatically recovering.  **Recovery**  Our engineering team identified the issue and took immediate action. We performed rolling restarts of the affected metadata services to clear the unresponsive connection pools and stabilize the systems. By 11:30 UTC, affected systems had recovered. Following this, the CloudWorks™ scheduler was restarted to process and clear the backlog of integration tasks. The issue was fully resolved by 11:53 UTC.  **Corrective & Preventative Actions**  We are implementing the following actions to prevent recurrence:  * We are implementing enhanced storage performance tiers and traffic-prioritization controls to isolate key platform workloads from other background system activities.  * We are updating our internal service connection frameworks to automatically detect and gracefully recover from unexpected system connection interruptions.  * We are refining our security software deployment processes to stagger rollouts and limit simultaneous resource utilization.  * We are enhancing our synthetic monitoring dashboards to improve visibility of regional service performance deviations.  * We are conducting rigorous connection-recovery and system testing in our lower environments to validate application resilience under loaded states.  We apologize for any impact this issue may have had on your business operations. We are continuously strengthening our systems and procedures to ensure we avoid future disruptions to your business and users.  If you have further questions or concerns, please visit our [Support website](https://www.google.com/url?q=https%3A%2F%2Fsupport.anaplan.com%2F). We appreciate your patience during this incident and value the trust you place in Anaplan.

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

1. 2026년 7월 24일 PM 8:35 UTCinvestigating

   우리는 현재 모델을로드 할 수없는 일부 고객이 발생 한 문제를 조사하고 있습니다. 우리는 가능한 한 빨리이 문제를 해결하기 위해 노력하고 30 분 또는 해결시 업데이트를 제공합니다.

2. 2026년 7월 24일 PM 11:01 UTCinvestigating

   우리는이 문제를 조사 계속하기 때문에 당신의 인내심을 주셔서 감사합니다. 현재, 우리는 아직 해결 시간이 없습니다. 우리는 우리가 가능한 한 빨리이 문제를 해결하기 위해 노력으로 30 분마다 업데이트를 계속할 것입니다.

3. 2026년 7월 24일 PM 11:33 UTCinvestigating

   우리는이 문제를 조사 계속하기 때문에 당신의 인내심을 주셔서 감사합니다. 우리의 지원 팀은 이 문제를 조사하기 위해 계속, 그러나 우리는 아직 해결책에 시간이 없습니다. 우리는 우리가 가능한 한 빨리이 문제를 해결하기 위해 노력으로 30 분마다 업데이트를 계속할 것입니다.

4. 2026년 7월 25일 AM 12:07 UTCinvestigating

   우리는이 문제를 조사 계속하기 때문에 당신의 인내심을 주셔서 감사합니다. 이 문제는 우리의 수석 엔지니어링 및 리더십 팀에 에스컬레이션되었습니다, 누가 적극적으로 상황을 조사하고 전체 작업을 복원하기 위해 필요한 다음 단계를 평가하는. 우리는이 순간에 공유 할 수있는 특정 기술 정보가없는 동안이 사건을 해결하는 것이 가장 높은 우선 순위입니다. 우리는 진심으로 혼란을 위해 사과하고 당신의 인내를 평가합니다. 우리는 30 분마다 업데이트를 계속 제공 할 것입니다, 또는 새로운 세부 정보가 등장하는 경우, 우리는 가능한 한 빨리이 문제를 해결하기 위해 노력하고.

5. 2026년 7월 25일 AM 12:39 UTCinvestigating

   우리는 잠재적 구제 경로를 식별하고 현재 서비스 안정성을 복원하기 위해 적극적인 완화 활동을 진행하고 있습니다. 우리는이 단계에서 공유하기 위해 Recovery (ETA)에 대한 확고한 예상 시간을 가지고 있지 않지만, 우리의 주요 초점은 안전하고 신속하게이 문제를 해결하는 것을 확신합니다. 우리는 우리의 현재 완화 단계의 충격을 밀접하게 감시하고 있습니다. 우리는 지속적인 불편을 위해 사과합니다. 다음 업데이트는 30 분 내에 게시되거나 중요한 이정표가 달성됩니다.

6. 2026년 7월 25일 AM 1:08 UTCinvestigating

   우리는이 혼란을 이해하고 가능한 한 빨리 해결하는 것을 확신 할 수 있기를 바랍니다 우리의 최고 우선 순위. 우리의 팀은 구제에 적극적으로 참여하고, 장소에 넣어 측정은 전체 서비스 복원에 대한 의미있는 진행을 보여줍니다. 우리는이 과정을 통해 당신의 인내를 인식하고 부여하지 않습니다. 우리는 우리의 체계를 밀접하게 감시하고 30 분 안에 더 갱신을 제공할 것입니다, 또는 더 빨리 공유하는 중대한 발달이 있어야 합니다.

7. 2026년 7월 25일 AM 1:42 UTCinvestigating

   우리는 우리의 구제 계획을 실행하고 검증합니다. 우리는 복구 노력이 체계적으로 이동으로 지속적인 발전을 본다. 안전하고 완벽한 복구를 위해, 우리는 신중하게 진행하고 아직 특정 기술적인 이정표를 공유하는 위치에 없습니다. 우리의 전체 응답 팀은이 사건을 해결하기 위해 최선을 다하고 있습니다. 당신의 지속적인 인내에 감사드립니다. 우리의 다음 업데이트는 30 분 내에 게시 될 것입니다, 또는 곧 우리가 더 많은 진행을보고.

8. 2026년 7월 25일 AM 2:18 UTCinvestigating

   우리는 현재 캐나다 지역에 비상 정비를 실시하고 있습니다. 플랫폼에 대한 접근은 일시적으로 제한되어 있으며, 우리 팀은 전체 서비스 복원을 완료하고 검증합니다. 우리는 적극적으로 환경을 모니터링하고 진행 상황을 만들기. 우리는 당신의 인내력을 평가하고이 문제에 미치는 영향을 이해합니다. 추가 업데이트는 30 분마다 제공 될 것입니다, 또는 빨리 공유하는 중요한 개발이 있다면. 불편을 끼쳐 드려 죄송합니다.

9. 2026년 7월 25일 AM 3:09 UTCinvestigating

   우리의 팀은 remediation 노력에 적극적으로 참여합니다. 일은 다수 일류의 맞은편에 진행되고 우리는 가득 차있는 서비스 회복을 향한 앞으로 운동을 계속합니다. 우리는 30 분 이내에 더 많은 업데이트를 제공 할 것입니다, 또는 더 빨리 공유하는 의미있는 개발이 있다면. 우리는 당신의 지속적인 인내를 평가합니다.

10. 2026년 7월 25일 AM 3:47 UTCinvestigating

    우리는 현재 캐나다 지역에 비상 정비를 실시하고 있습니다. 우리의 팀은 우리의 납품업자와 조화에 있는 구약 노력에서 적극적으로 관여되고, 문제점은 포함되었습니다. 캐나다 환경에 대한 고객 접근은 일시적으로 제한되어 있으며, 유효성 및 복원 노력이 완료되었습니다. 우리는 당신의 인내를 평가하고 1 시간 이내에 더 업데이트를 제공 할 것입니다, 또는 더 빨리 공유하는 중요한 개발이 있다면.

11. 2026년 7월 25일 AM 4:47 UTCinvestigating

    우리의 팀은 우리의 납품업자를 가진 가까운 조정에 캐나다 지역에 비상사태 정비를 통해서 계속합니다. 이 문제는 참여하고 복원 노력이 적극적으로 진행되고 있습니다. 캐나다 환경에 대한 액세스는 일시적으로 제한되어 있으므로 서비스 복원 이전에 필요한 검증 단계를 완료하십시오. 우리는이 일에 미치는 영향을 인식하고 지속적인 인내를 평가합니다. 다음 업데이트는 1 시간 이내에 제공되며, 더 빨리 중요한 개발이 발생합니다.

12. 2026년 7월 25일 AM 6:05 UTCidentified

    우리의 팀은 우리의 납품업자를 가진 가까운 조정에 캐나다 지역에 비상사태 정비를 통해서 계속합니다. 이 문제는 포함되었지만, 복구 프로세스의 복잡성 및 범위로 인해, 우리는 몇 시간을 완료 할 수있는 장시간 노력이 될 것으로 기대합니다. 캐나다 환경에 대한 접근은 복구 기간 동안 제한됩니다. 우리는 당신의 일에 중요한 충격을 인식하고 진심으로 당신의 인내력을 평가합니다. 다음 업데이트는 1 시간 이내에 제공되며, 더 빨리 중요한 개발이 발생합니다.

13. 2026년 7월 25일 AM 7:06 UTCidentified

    우리의 팀과 납품업자 파트너는 이 비상사태 정비 도중 캐나다 지역을 위한 복잡한 회복 과정을 통해 진전을 계속합니다. 우리는 체계적으로 우리의 회복 의정서를 실행하고 각 단계에 체계 무결성을 검증합니다. 이 노력의 범위로 인해 이전에 언급 한 바와 같이 확장 된 복구 프로세스를 유지하고 캐나다 환경에 대한 액세스는 우리가 안전하고 완벽한 서비스 복원을 위해 노력으로 계속됩니다. 우리는이 서비스 중단에 대한 영향의 완전히 인식을 유지하고이 단계를 만료 할 수있는 모든 것을하고 있습니다. 다음 업데이트는 1 시간 이내에 제공되며, 더 빨리 중요한 개발이 발생합니다.

14. 2026년 7월 25일 AM 8:07 UTCidentified

    우리의 엔지니어링 및 공급 업체 팀은 긴급 유지 보수에 따라 캐나다 지역에 대한 복구 단계를 적극적으로 수행합니다. 우리의 초점은 체계적이고 안전한 회복에 완전히 남아 있기 때문에, 우리의 초점이 시간에 공유하는 새로운 기술적인 세부사항 또는 변화가 없습니다. 캐나다 환경에 대한 액세스는 이러한 복구 활동이 진행되는 동안 제한됩니다. 우리는이 확장 된 노력으로 지속적인 인내 및 파트너십을 평가합니다. 다음 업데이트는 1 시간 이내에 제공되며, 더 빨리 중요한 개발이 발생합니다.

15. 2026년 7월 25일 AM 9:06 UTCidentified

    우리의 엔지니어링 팀 및 공급 업체 파트너는 비상 정비에서 캐나다 지역에 대한 복구 단계를 통해 계속 진행합니다. 우리는 긍정적 인 헤드 웨이를 만들고 대부분의 작업 공간에 대한 지역을 다시 활성화하는 것이 더 가까이 있습니다. 캐나다 환경에 대한 액세스는 일시적으로 제한되어 있으며, 이러한 중요한 최종 검증 단계를 수행하여 서비스 안정성을 보장합니다. 우리는 진심으로 당신의 인내와 파트너십을 평가하기 때문에 우리는 복구 프로세스의 이러한 최종 단계를 입력합니다. 다음 업데이트는 1 시간 이내에 제공되며, 더 빨리 중요한 개발이 발생합니다.

16. 2026년 7월 25일 AM 10:07 UTCinvestigating

    우리는 체계적으로 긴급 정비의 밑에 캐나다 지역을 위한 우리의 회복 단계를 실행합니다. 우리의 엔지니어링 팀 및 공급 업체 파트너는 최종 검증 단계에 초점을 맞추고, 우리는 고객의 대다수를 위해 지역을 더 가까이 얻을 수 있도록 계속. 캐나다 환경에 대한 액세스는 이러한 중요한 최종 단계 동안 시스템 안정성을 유지하기 위해 시간이 제한됩니다. 우리는 당신의 지속적인 인내와 공동체를 위해 대단히 감사하고 있습니다. 다음 업데이트는 1 시간 이내에 제공되며, 더 빨리 중요한 개발이 발생합니다.

17. 2026년 7월 25일 AM 11:14 UTCidentified

    우리의 엔지니어링 팀 및 공급 업체 파트너는 비상 유지 보수 아래 캐나다 지역에 대한 검증의 최종 단계를 통해 체계적으로 진행합니다. 우리는 시스템 안정성을 확인하는 데 초점을 맞추고 있으며, 대다수의 고객을 위해 지역을 활성화하기 위해 꾸준한 길을 유지합니다. 캐나다 환경에 대한 액세스는 이러한 중요한 안전과 안정성 검사를 완전히 완료하는 시간을 제한합니다. 우리는 우리가이 확장 된 노력을 완료하기 때문에 지속적인 인내와 파트너십을 위해 매우 감사하고 있습니다. 다음 업데이트는 1 시간 이내에 제공되며, 더 빨리 중요한 개발이 발생합니다.

18. 2026년 7월 25일 PM 12:37 UTCidentified

    우리의 엔지니어링 및 공급 업체 팀은 비상 유지 보수의 밑에 캐나다 지역에 대한 우리의 복구 계획의 최종 준비 단계를 입력합니다. 우리는 액세스 복원을 준비하면서, 우리의 계획은 당신의 자신의 키 (BYOK) 구성을 가져 오는 예외로 지역에 모든 서비스를 가능하게하는 것입니다. 또한, 작업 공간의 작은 수는 일반 서비스 복원에 처음 사용되지 않습니다. 이 특정한 나머지 작업대를 위해, 우리는 완전한 안정성 및 자료 무결성을 보장하기 위하여 각 환경을 개별적으로 회복하기 위하여 높게 통제되는 체계적인 회복 계획을 실행할 것입니다. 캐나다 환경에 대한 액세스는이 시간에 제한되어 있으며, 이러한 최종 사전 유효성 검증 단계를 완료합니다. 우리는 지속적인 영향을 인식하고이 작업을 지속적으로 평가합니다. 다음 업데이트는 1 시간 이내에 제공되며, 더 빨리 중요한 개발이 발생합니다.

19. 2026년 7월 25일 PM 1:51 UTCidentified

    우리는 현재 플랫폼을 복원하고 있습니다. 엔지니어링 및 공급 업체 팀은 신속하게 서비스를 복원하는 데 적극적으로 노력하고 있습니다. 우리의 복구 계획의 일환으로, 우리는 당신의 자신의 키 (BYOK) 구성을 가져 예외로 지역의 모든 서비스를 복원 할 것입니다. 또한, 작업 공간의 작은 수는 초기 서비스 복원에 일시적으로 비활성화됩니다. 이러한 특정 작업 영역의 경우, 우리는 각 환경을 개별적으로 회복하고 완벽한 안정성과 데이터 무결성을 보장하기 위해 고도로 제어, 체계적인 복원 프로세스를 실행할 것입니다. 캐나다 환경에 대한 액세스는이 시간에 제한됩니다. 우리는이 작업에 중요한 영향을 인식하고 지속적으로 당신의 지속적인 인내력을 평가합니다. 다음 업데이트는 1 시간 이내에 제공되며, 더 빨리 중요한 개발이 발생합니다.

20. 2026년 7월 25일 PM 4:22 UTCidentified

    우리의 엔지니어링 팀은 캐나다 (CA1) 지역을 통해 플랫폼 안정성을 복원하기 위해 적극적으로 노력하고 있습니다. 우리는 처음에 자신의 키 (BYOK) 구성을 가져와 일반 서비스를 복원합니다. 안정적이고 안전한 환경을 보장하기 위해, 작업 공간의 작은 수는 일시적으로 중단될 수 있습니다. 캐나다 환경에 대한 전반적인 접근은 이러한 중요한 복원 조치를 완료하기 때문에이 시간에 제한됩니다. 우리는 깊이 이러한 안전 대책을 통해 작업으로 지속적인 인내력을 평가하기 위해이 상황을 중요한 영향을 인식합니다. 다음 업데이트는 1 시간 이내에 제공되며, 더 빨리 중요한 개발이 발생합니다.

21. 2026년 7월 25일 PM 5:24 UTCidentified

    우리는 캐나다 지역에 일반 고객 액세스를 활성화했습니다. 지역 내 모든 서비스는 이제 온라인으로 가져 왔습니다. 자신의 키 (BYOK) 구성을 가져 오는 예외가 있습니다. 또한, 작은, 특정 번호의 고객 작업 공간은 일시적으로 중단됩니다. 이러한 나머지 작업 공간의 경우, 우리의 엔지니어링 팀은 완전 데이터 무결성을 보장하기 위해 각 환경을 안전하게 회복하기 위해 고도로 제어, 체계적인 복원 계획을 실행하고 있습니다. 우리는 진심으로 우리의 지속적인 Patience 및 파트너십을 통해 우리는이 최종, 정확한 복구 단계를 실행합니다. 다음 업데이트는 1 시간 이내에 제공되며, 더 빨리 중요한 개발이 발생합니다.

22. 2026년 7월 25일 PM 11:28 UTCidentified

    우리는 진심으로 혼란에 대한 사과가 발생하고 깊이 당신의 인내력을 평가하고있다. 캐나다 지역에 대한 일반 고객 액세스는 복원되었으며, 서비스는 온라인으로 돌아 왔습니다. 자신의 키 구성을 가져와 작업 공간의 작은 수는 일시적으로 오프라인으로 유지하면서, 우리는 전체 데이터 무결성을 보장하기 위해 조심스럽게 개인화 된 복원을 완료합니다. 우리는 1 시간 이내에 더 많은 업데이트를 제공 할 것입니다, 또는 더 빨리 공유하는 중요한 개발이 있다면.

23. 2026년 7월 25일 PM 11:52 UTCidentified

    캐나다 지역의 일반 고객 접근은 복원되었습니다. 자신의 키 (BYOK) 암호화를 가져 오는 작업 공간은 일시적으로 오프라인 상태로 유지되며 각 영향을받는 작업 공간에 대한 개별적인 복원을 완료합니다. 우리는 7 월 26, 2026의 09 : 00 UTC에서 BYOK 복원 상태에 대한 추가 업데이트를 제공합니다. 우리는 혼란에 대해 사과하고 당신의 인내에 감사드립니다.

24. 2026년 7월 26일 AM 8:59 UTCinvestigating

    우리는 캐나다 (CA1)에 영향을 미치는 서비스 중단에 대한 높은 수준의 업데이트를 제공하기 위해 작성됩니다. 금요일, 24 7 월 20 : 35 UTC. 우리의 엔지니어링 팀과 공급 업체 파트너의 헌신을 통해 캐나다 지역의 일반 액세스는 17시 24분 UTC의 토요일, 25 7 월 25 일에 성공적으로 재 활성화되었습니다. 우리의 고객의 광대한 대다수는 지금 그들의 업무 공간 및 모형을 일반적으로 접근할 수 있습니다. 현재 상태 및 다음 단계 일반 지역 액세스가 완전히 복원 된 동안, 자신의 키 (BYOK) 암호화를 사용하여 작업 공간은 일시적으로 오프라인 상태로 유지됩니다. 우리의 주요 초점은 현재 통제되는 환경 내의 기술적인 붕괴를 reproducing. 이 재생 단계에서 얻은 통찰력은 직접 영향을 미치고 나머지 BYOK 작업 공간에 가장 효과적인 복구 경로를 결정하기 때문에 중요합니다. 이 체계적인 조사로 Proceeding 우리는 체계 안정성과 자료 완전성의 가장 높은 기준을 유지합니다. BYOK Workspace restoration에 대한 다음의 대상 업데이트를 제공 할 것으로 기대합니다. 11:00 UTC. 우리는 진심으로 혼란에 대한 사과와이 영향은 작업에있었습니다. 우리의 지원 팀은 모든 질문 또는 즉각적인 필요에 도움을 완전히 사용할 수 있습니다.

25. 2026년 7월 26일 AM 11:16 UTCinvestigating

    우리는 캐나다 (CA1)에 영향을 미치는 서비스 중단에 대한 높은 수준의 업데이트를 제공하기 위해 작성됩니다. 금요일, 24 7 월 20 : 35 UTC. 우리의 엔지니어링 팀과 공급 업체 파트너의 헌신을 통해 캐나다 지역의 일반 액세스는 17시 24분 UTC의 토요일, 25 7 월 25 일에 성공적으로 재 활성화되었습니다. 우리의 고객의 광대한 대다수는 지금 그들의 업무 공간 및 모형을 일반적으로 접근할 수 있습니다. 현재 상태 및 다음 단계 일반 지역 액세스가 완전히 복원 된 동안, 자신의 키 (BYOK) 암호화를 사용하여 작업 공간은 일시적으로 오프라인 상태로 유지됩니다. 우리의 주요 초점은 현재 통제되는 환경 내의 기술적인 붕괴를 reproducing. 이 재생 단계에서 얻은 통찰력은 직접 영향을 미치고 나머지 BYOK 작업 공간에 가장 효과적인 복구 경로를 결정하기 때문에 중요합니다. 이 체계적인 조사로 Proceeding 우리는 체계 안정성과 자료 완전성의 가장 높은 기준을 유지합니다. 우리는 BYOK workspace restoration에 대한 다음 대상 업데이트를 제공 할 것으로 기대합니다. 13:00 UTC. 우리는 진심으로 혼란에 대한 사과와이 영향은 작업에있었습니다. 우리의 지원 팀은 모든 질문 또는 즉각적인 필요에 도움을 완전히 사용할 수 있습니다.

26. 2026년 7월 26일 PM 1:06 UTCinvestigating

    캐나다 (CA1) 지역에 대한 일반적인 액세스는 7 월 25 일 (토) 17시 24분 UTC에서 7 월 25 일 (토)로 완전히 복원되어 자체 키 (BYOK) 암호화를 사용하여 작업 공간은 일시적으로 오프라인 상태로 유지됩니다. 통제된 환경 내의 붕괴를 재현하는 우리의 주된 초점은 우리의 납품업자로 아직도 진행됩니다. 이것은 매우 중요한 단계이며, 시스템 안정성과 데이터 무결성을 보장하면서 나머지 BYOK 작업 공간에 가장 효과적인 복구 경로를 결정합니다. BYOK workspace restoration에 대한 다음의 대상 업데이트를 제공 할 것으로 기대됩니다. 15:00 UTC. 우리는 진심으로 혼란에 대한 사과와이 영향은 작업에있었습니다. 우리의 지원 팀은 모든 질문 또는 즉각적인 필요에 도움을 완전히 사용할 수 있습니다.

27. 2026년 7월 26일 PM 3:20 UTCinvestigating

    CA1 지역에 대한 일반 액세스는 대부분의 고객을 위해 완전히 복원됩니다. 자신의 키 (BYOK) 암호화를 가져 오는 작업 공간은 일시적으로 오프라인으로 유지되며 안전한 복구, 유효성 검사 및 루트 분석. 우리는 우리의 타사 암호화 파트너와 협력하여 원인과 잠재적 인 수정을 이해합니다.

28. 2026년 7월 26일 PM 5:53 UTCidentified

    CA1 지역에 대한 일반 액세스는 대부분의 고객에게 완전히 복원됩니다. 자신의 키 (BYOK) 암호화를 가져 오는 작업 공간은 일시적으로 오프라인으로 유지되며 안전한 복구, 유효성 검사 및 루트 분석이 종료됩니다. 우리는 우리의 타사 암호화 파트너와 협력하여 원인과 잠재적 인 수정을 이해합니다.

29. 2026년 7월 26일 PM 6:49 UTCidentified

    캐나다의 일반 액세스 (CA1) 지역은 완전히 복원됩니다. 그러나, 자신의 키를 가져 오는 작업 공간 (BYOK) 암호화는 일시적으로 오프라인 상태로 유지됩니다. 우리는 7 월 27, 2026의 10 : 00 UTC에서 BYOK 복원 상태에 대한 추가 업데이트를 제공합니다. 우리는이 혼란에 대해 사과하고 지속적인 인내에 감사드립니다.

30. 2026년 7월 27일 AM 10:03 UTCinvestigating

    우리는 캐나다 (CA1) 지역의 자신의 키 (BYOK) 작업 공간을 가져위한 지속적인 복구 노력에 대한 상태 업데이트를 제공하기 위해 작성됩니다. 지구의 일반 서비스는 완전히 복원되고 일반적으로 작동합니다. 현재 Investigation 상태 우리의 엔지니어링 및 공급 업체 팀은 최근 서비스 중단의 뿌리 원인으로 깊은 조사를 계속하고 있습니다. 우리는 현재 헌신적이고 비생산적인 환경에서 문제점을 복제하는 노력에 집중하고 있습니다. 이 제어 복제는 기술적 인 발견으로 중요한 단계로, 직접 식별하고 나머지 BYOK 작업 공간에 가장 효과적인 복구 경로를 검증 할 수 있습니다. 우리는 완전히 비생산에 있는 이 특정한 조건의 밑에 체계의 행동을 첫째로 이해해서, 우리는 최종 회복 단계 도중 당신의 자료의 절대적인 안전, 안정성 및 완전성을 보장해서 좋습니다. 우리는 진심으로 당신의 인내와 파트너십을 감사합니다. 우리는 이러한 인내적 검증 단계를 수행합니다. 다음 업데이트는 2 시간 이내에 제공됩니다. 또는 더 빨리 중요한 이정표를 도달해야합니다.

31. 2026년 7월 27일 PM 12:30 UTCinvestigating

    우리는 캐나다 (CA1) 지역의 자신의 키 (BYOK) 작업 공간을 가져위한 적극적인 조사 및 복구 계획을 계속하고 있습니다. 지구의 일반 서비스는 완전히 복원되고 정상적으로 작동하기 위해 계속. 우리의 엔지니어링 팀 및 공급 업체 파트너는 제어, 비 생산 환경에서의 붕괴를 복제하는 노력에 초점을 맞추고 있습니다. 이러한 안전 조건 하에서 시나리오를 수정 하 여 우리의 가장 높은 우선권, 그것은 우리가 식별 하 고 나머지 BYOK 작업 공간에 대 한 가장 효과적인 복구 경로를 확인 하는 중요 한 단계. 우리는 체계 안정성과 자료 무결성을 한 번 시작된 회복 과정, 유지한다는 것을 보증하기 위하여 방법을 진행하고 있습니다. 우리는 이 깊은 기술적 인 검증이 계속되는 동안 지속적인 인내와 파트너십을 평가합니다. 다음 업데이트는 2 시간 이내에 제공 될 것입니다. 또는 더 빨리 공유하기 위해 새로운 진행 상황을해야합니다.

32. 2026년 7월 27일 PM 2:04 UTCinvestigating

    우리는 캐나다 (CA1) 지역의 자신의 키 (BYOK) 작업 공간을 복원하기 위해 적극적인 노력을 계속하고 있습니다. 지역 전역의 일반 서비스는 완전히 복원되고 일반적으로 운영됩니다. 해결을 위해, 우리의 기술설계 팀 및 납품업자 파트너는 조사의 다수 선을 concurrently 추구하고 있습니다. 이 다 얼굴 접근법은 우리의 회복 계획이 완전히 검증되고 당신의 환경의 무결성을 보존한다는 것을 보증하는 것이 중요합니다. 우리는 진심으로 당신의 인내와 파트너십을 감사 합니다. 다음 업데이트는 2 시간 이내에 제공 될 것입니다, 또는 더 빨리 우리가 중요한 돌파구를 달성해야한다.

33. 2026년 7월 27일 PM 3:54 UTCidentified

    우리는 캐나다 (CA1) 지역의 자신의 키 (BYOK) 작업 공간을 복원하기 위해 적극적인 노력을 계속하고 있습니다. 지역 전역의 일반 서비스는 완전히 복원되고 일반적으로 운영됩니다. 우리의 엔지니어링 팀 및 공급 업체 파트너는 조사의 여러 줄을 지속적으로 추구하고 있습니다. 이 병렬 접근법은 BYOK workspaces의 가장 효과적인 복구 경로를 검증하고 최종적으로 검증하기 위해 deliberately 실행되고, 우리가 안전하게 서비스를 회복하고 안정성의 최고 수준으로 보장합니다. 우리는이 필요한 단계를 통해 우리의 팀으로 지속적인 인내력을 평가합니다. 다음 업데이트는 2 시간 이내에 제공 될 것입니다, 또는 더 빨리 우리가 중요한 돌파구를 달성해야한다.

34. 2026년 7월 27일 PM 5:37 UTCinvestigating

    캐나다 전역의 일반 서비스 (CA1) 지역은 완전히 복원되고 정상적으로 작동하지만, 우리는 자신의 키 (BYOK) 작업 공간을 가져 오는 복구에 최선을 다하고 있습니다. 우리의 팀은 체계적으로 다수 평행한 workstreams로 앞으로 이동하고 있습니다. 이 노력의 실행은 완전히 모든 결과를 분석 할 수있게 해주며, 우리가 검증하고 나머지 BYOK 작업 공간에 가장 효과적인 복구 경로를 구현하고, 우리가 안전하게 서비스를 복원하고 최고 수준의 안정성을 보장합니다. 우리는 우리가이 중요한 회복 단계를 실행하기 때문에 지속적인 파트너쉽과 인내심을 평가합니다. 우리는 7 월 28, 2026의 09 : 00 UTC (10:00 BST)에서 BYOK 복원 상태에 대한 추가 업데이트를 제공합니다.

35. 2026년 7월 28일 AM 9:02 UTCidentified

    캐나다의 일반 서비스 (CA1) 지역은 완전히 복원되고 정상적으로 작동합니다. 나머지는 자신의 키 (BYOK) 작업 공간을 가져, 우리의 팀은 여러 병렬 작업 흐름을 수행하기 위해 계속. 이 동시 접근법은 절대 시스템 안정성을 보장하면서 나머지 BYOK 작업공간에 가장 효과적인 복구 경로를 검증하기 위해 deliberately 수행됩니다. 우리는 당신의 지속적인 인내를 평가합니다. 다음 업데이트는 2 시간 이내에 제공됩니다. 또는 더 빨리 우리가 중요한 이정표를 도달해야합니다.

36. 2026년 7월 28일 AM 11:01 UTCidentified

    캐나다 내 일반 서비스 (CA1) 지역은 일반적으로 작동하고 완전히 안정적으로 유지됩니다. 우리의 엔지니어링 및 공급 업체 팀은 나머지 자신의 키 (BYOK) 작업 공간을 차지하기 위해 여러 동시 작업 흐름을 통해 진행되고 있습니다. 이 평행한 접근은 우리의 활동적인 초점, 체계적으로 유효한 것을 허용하고 안전의 가장 높은 수준을 가진 남은 BYOK workspaces를 위한 가장 효과적인 회복 경로를 실행합니다. 우리는 당신의 지속적인 인내 및 지원을 평가합니다. 다음 업데이트는 2 시간 이내에 제공됩니다. 또는 더 빨리 우리가 중요한 이정표를 도달해야합니다.

37. 2026년 7월 28일 PM 1:11 UTCidentified

    캐나다 내 일반 서비스 (CA1) 지역은 완전히 복원, 안정 유지, 일반적으로 작동 계속. 우리의 엔지니어링 팀 및 공급 업체 파트너는 나머지 자신의 키 (BYOK) 작업 공간을 가져다주는 여러 동시 작업 흐름으로 앞으로 이동하도록 계속됩니다. 이 병렬 전략은 우리의 적극적인 초점을 유지, 체계적으로 검증 하 고 나머지 BYOK workspaces에 대 한 가장 효과적인 복구 경로 구현. 우리는 진심으로이 deliberate 단계를 통해 일하면서 지속적인 patience에 감사드립니다. 다음 업데이트는 2 시간 이내에 제공됩니다. 또는 더 빨리 우리가 중요한 이정표를 도달해야합니다.

38. 2026년 7월 28일 PM 4:02 UTCidentified

    캐나다 내 일반 서비스 (CA1) 지역은 완전히 복원, 안정 유지, 일반적으로 작동 계속. 우리의 엔지니어링 팀 및 공급 업체 파트너는 여러 병렬 워크스트림을 통해 나머지 자신의 키 (BYOK) 작업 공간에 초점을 적극적으로 유지하고 있습니다. 우리는 이러한 중요한 검증 단계를 완료하여 지속적인 인내 및 파트너십을 평가합니다. 다음 업데이트는 2 시간 이내에 제공됩니다. 또는 더 빨리 우리가 중요한 이정표를 도달해야합니다.

39. 2026년 7월 28일 PM 7:51 UTCidentified

    캐나다 전역의 일반 서비스 (CA1) 지역은 완전히 복원되고 정상적으로 작동하지만, 우리는 자신의 키 (BYOK) 작업 공간을 가져 오는 복구에 최선을 다하고 있습니다. 우리의 팀은 체계적으로 다수 평행한 workstreams로 앞으로 이동하고 있습니다. 이 노력의 실행은 완전히 모든 결과를 분석 할 수있게 해주며, 우리가 검증하고 나머지 BYOK 작업 공간에 가장 효과적인 복구 경로를 구현하고, 우리가 안전하게 서비스를 복원하고 최고 수준의 안정성을 보장합니다. 우리는 우리가이 중요한 회복 단계를 실행하기 때문에 지속적인 파트너쉽과 인내심을 평가합니다. 우리는 7 월 29, 2026의 09 : 00 UTC (10:00 BST)에서 BYOK 복원 상태에 대한 추가 업데이트를 제공합니다.

40. 2026년 7월 29일 AM 9:04 UTCidentified

    캐나다 전역의 일반 서비스 (CA1) 지역은 완전히 복원되고 정상적으로 작동하지만, 우리는 자신의 키 (BYOK) 작업 공간을 가져 오는 복구에 최선을 다하고 있습니다. 우리의 팀은 여러 병렬 작업 흐름을 통해 체계적으로 진행되고 있습니다. 이러한 노력의 실행은 완전히 기술적인 결과를 분석하고, 우리가 검증하고 나머지 BYOK 작업 공간에 대한 가장 안전하고 안정적인 복구 경로를 구현하는 것을 보장합니다. 우리는 우리가이 중요한 회복 단계를 실행하기 때문에 지속적인 파트너쉽과 인내심을 평가합니다. 다음 업데이트는 2 시간 이내에 제공됩니다. 또는 더 빨리 우리가 중요한 이정표를 도달해야합니다.

41. 2026년 7월 29일 PM 1:23 UTCinvestigating

    캐나다 전역의 일반 서비스 (CA1) 지역은 완전히 복원되고 정상적으로 작동하지만, 우리는 자신의 키 (BYOK) 작업 공간을 가져 오는 복구에 최선을 다하고 있습니다. 우리의 팀은 아직도 체계적으로 진행되고, 다수 평행한 workstreams를 통해서. 이러한 노력의 실행은 완전히 기술적인 결과를 분석하고, 우리가 검증하고 나머지 BYOK 작업 공간에 대한 가장 안전하고 안정적인 복구 경로를 구현하는 것을 보장합니다. 우리는 우리가이 중요한 회복 단계를 실행하기 때문에 지속적인 파트너쉽과 인내심을 평가합니다. 다음 업데이트는 2 시간 이내에 제공됩니다. 또는 더 빨리 우리가 중요한 이정표를 도달해야합니다.

42. 2026년 7월 29일 PM 3:21 UTCinvestigating

    캐나다 전역의 일반 서비스 (CA1) 지역은 완전히 복원되고 정상적으로 작동하도록 계속 유지. 우리의 엔지니어링 및 운영 팀은 자신의 주요 (BYOK) 작업 공간을 복구하는 데 전념하고 집중된 초점을 유지하고 있습니다. 가장 안전한 복원을 보장하기 위해, 우리는 여러 병렬 복구 워크스트림을 적극적으로 추진하고 있습니다. 이 노력이 지속적으로 실행하면 실시간 기술 결과를 엄격하게 분석 할 수 있으며, 우리가 검증하고 나머지 BYOK 작업 공간에서 가장 안정적이고 안전한 경로 전달을 구현합니다. 우리는 진심으로 우리가 체계적으로이 중요한 회복 단계를 실행으로 지속적인 인내 및 파트너십을 평가합니다. 다음 업데이트는 2 시간 이내에 제공됩니다. 또는 더 빨리 우리가 중요한 이정표를 도달해야합니다.

43. 2026년 7월 29일 PM 5:17 UTCinvestigating

    캐나다 전역의 일반 서비스 (CA1) 지역은 완전히 복원되고 정상적으로 작동하지만, 우리는 자신의 키 (BYOK) 작업 공간을 가져 오는 복구에 최선을 다하고 있습니다. 우리의 팀은 체계적으로 다수 평행한 workstreams로 앞으로 이동하고 있습니다. 이 노력의 실행은 완전히 모든 결과를 분석 할 수있게 해주며, 우리가 검증하고 나머지 BYOK 작업 공간에 가장 효과적인 복구 경로를 구현하고, 우리가 안전하게 서비스를 복원하고 최고 수준의 안정성을 보장합니다. 우리는 우리가이 중요한 회복 단계를 실행하기 때문에 지속적인 파트너쉽과 인내심을 평가합니다. 우리는 7 월 30, 2026의 09 : 00 UTC (10:00 BST)에서 BYOK 복원 상태에 대한 추가 업데이트를 제공합니다.

44. 2026년 7월 30일 AM 8:59 UTCinvestigating

    캐나다 전역의 일반 서비스 (CA1) 지역은 일반적으로 전체 안정성으로 작동하기 위해 계속, 우리의 기술 팀은 나머지 자신의 키 (BYOK) 작업 공간의 회복에 전념 초점을 유지. 우리는 검증하고 가장 안전한 복원 경로를 실행하기 위해 여러 병렬 작업스트림을 계속합니다. 이러한 노력이 지속적으로 우리의 모든 기술적인 결과를 철저히 분석 할 수 있도록, 우리는 모든 뛰어난 BYOK 작업 공간에 대한 보안과 안정성의 최고 수준의 서비스를 복원. 우리는 이 중요한 회복 단계를 통해 체계적으로 일하기 때문에 지속적인 인내 및 공동체정신을 평가합니다. BYOK 복원 진행에 대한 추가 업데이트를 제공합니다.

45. 2026년 7월 30일 AM 11:07 UTCinvestigating

    캐나다 전역의 일반 서비스 (CA1) 지역은 일반적으로 전체 안정성으로 작동하기 위해 계속, 우리의 기술 팀은 나머지 자신의 키 (BYOK) 작업 공간의 회복에 전념 초점을 유지. 우리는 검증하고 가장 안전한 복원 경로를 실행하기 위해 여러 병렬 작업스트림을 계속합니다. 이러한 노력이 지속적으로 우리의 모든 기술적인 결과를 철저히 분석 할 수 있도록, 우리는 모든 뛰어난 BYOK 작업 공간에 대한 보안과 안정성의 최고 수준의 서비스를 복원. 우리는 이 중요한 회복 단계를 통해 체계적으로 일하기 때문에 지속적인 인내 및 공동체정신을 평가합니다. 우리는 7 월 31, 2026의 09 : 00 UTC (10:00 BST)의 BYOK 복원 상태에 대한 추가 업데이트를 제공 할 것입니다, 또는 더 빨리 우리가 중요한 이정표를 도달해야합니다.

46. 2026년 7월 31일 AM 9:04 UTCinvestigating

    캐나다 전역의 일반 서비스 (CA1) 지역은 일반적으로 전체 안정성으로 작동하기 위해 계속, 우리의 기술 팀은 나머지 자신의 키 (BYOK) 작업 공간의 회복에 전념 초점을 유지. 우리는 검증하고 가장 안전한 복원 경로를 실행하기 위해 여러 병렬 작업스트림을 계속합니다. 이러한 노력이 지속적으로 우리의 모든 기술적인 결과를 철저히 분석 할 수 있도록, 우리는 모든 뛰어난 BYOK 작업 공간에 대한 보안과 안정성의 최고 수준의 서비스를 복원. 우리는 이 중요한 회복 단계를 통해 체계적으로 일하기 때문에 지속적인 인내 및 공동체정신을 평가합니다. 우리는 8 월 3 일, 2026 일 UTC (10:00 BST)에서 BYOK 복원 상태에 대한 추가 업데이트를 제공 할 것입니다, 또는 더 빨리 우리가 중요한 이정표를 도달해야합니다.

47. 2026년 7월 31일 PM 1:47 UTCresolved

    우리는 문제가 해결되었는지 확인했습니다. 우리는이 문제에 영향을 미칠 수 있습니다. 우리는 이 문제를 통해 일하면서 인내와 파트너십을 평가합니다. 우리는 우리의 상태 페이지에 공유될 상세한 뿌리 원인 분석 (RCA)를 가진 7 영업일 안에 위로 따를 것입니다. 질문이나 우려 사항이 있으시면 Anaplan Support에서 연락 주시기 바랍니다.

48. 2026년 8월 11일 PM 4:03 UTCpostmortem

    **Summary**  On July 24, 2026, at 20:22 UTC, our engineering team began investigating an issue affecting customers in our ca1: Cloud — Canada region. Customers with affected workspaces were unable to open their models. As a precaution, while we validated the scope of the issue, we restricted access to the region behind a maintenance page at 02:18 UTC on July 25. General access to CA1 was restored at 17:24 UTC on July 25. Bring Your Own Key \(BYOK\) workspaces remained offline for additional safeguards, and were re-enabled progressively as those safeguards were validated. The incident was fully resolved on July 31, 2026, at 13:47 UTC.  **Root cause**  The disruption was caused by a defect in a third-party component used within our BYOK service. The defect only surfaced under a very specific combination of events occurring in a particular order on the same host. When a BYOK workspace was unloaded, the component failed tofully clear one of its local resources, leaving behind a stale reference. When a BYOK workspace was subsequently loaded onto the same host, the component attempted to clean up that stale reference before proceeding. During this step, it incorrectly executed a removal that extended beyond the stale reference and deleted files that were still in active use.   The affected files were captured in our regular backups. Once our engineering team identified the source of the activity, isolated it, and applied protective controls to stop any further impact, restoration became a controlled process of returning each affected file to its most recent backup.  **Recovery**  Our engineering team identified the issue and isolated it at its source, then worked systematically to restore the affected files. This allowed us to bring non-BYOK workspaces back online in a controlled sequence, and general access to CA1 was restored at 17:24 UTC on July 25.  We deliberately kept BYOK workspaces offline while our team worked with the third-party vendor to reproduce the trigger in a controlled, non-production environment. This reproduction gave us the diagnostic evidence the vendor needed to build a fix and to confirm the exact cause. It also allowed us to develop and validate our own temporary safeguards — targeted changes to how BYOK workspaces are scheduled — that eliminated the specific combination of conditions required to trigger the defect. These safeguards act as compensating controls to bring BYOK workspaces back online while the third party completes the permanent fix to the underlying component. We re-enabled BYOK workspaces once those safeguards were validated, ensuring the trigger conditions couldn't recur. The incident was fully resolved on July 31, 2026, at 13:47 UTC.  **Corrective and preventative actions**  Our corrective actions follow two complementary tracks. The first removes the specific combination of conditions required to trigger the defect, using controls we have developed and deployed ourselves as compensating safeguards. The second is the permanent fix to the underlying component itself, which the third party is delivering. Together, these tracks address both the trigger and the defect, so that neither can produce another incident of this kind. We are implementing the following actions to prevent recurrence:  * We have deployed changes that prevent the specific combination of conditions required to trigger the defect. This is a temporary but effective control that removes the trigger today, ahead of the permanent fix.  * We are working with the third party to deploy their validated fix. This removes the defect at its source and closes the underlying cause of this incident.  * We are strengthening how we validate BYOK third-party components in non-production before they reach production, including reproducing a wider range of workspace lifecycle scenarios and event sequences. This gives us stronger assurance to surface these types of issues in non-production and are addressed before they can affect customers.  * We have deployed dedicated alerting on the specific event pattern that triggered this incident and are actively reviewing additional file-level alerting. These alerts provide an additional safety net and earlier warning, enabling faster preventative action before customers are affected.  **Closing**  We apologize for any impact this issue may have had on your business operations. We are continuously strengthening our systems and procedures to ensure we avoid future disruptions to your business and users.   If you have further questions or concerns, please visit our [Support](https://www.google.com/url?q=https%3A%2F%2Fsupport.anaplan.com%2F) website. We appreciate your patience during this incident and value the trust you place in Anaplan.

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

1. 2026년 7월 21일 PM 2:30 UTCinvestigating

   Cloudworks 통합을 실행하는 고객의 능력에 영향을 미치는 문제를 조사하고 있습니다. 우리는 가능한 한 빨리이 문제를 해결하기 위해 노력하고 30 분 또는 해결시 업데이트를 제공합니다.

2. 2026년 7월 21일 PM 2:44 UTCmonitoring

   서비스는 이제 복원되었습니다; 당신은 지금 정상 활동을 이력서 할 수 있어야합니다. 우리는 플랫폼을 계속 모니터링하여 추가 문제가 발생하지 않도록합니다. 질문, 우려 사항이 있거나 문제가 계속되는 경우, Anaplan Support에 연락하는 것을 망설이지 마십시오. 우리는이 상황을 완전히 해결하기 위해 최종 업데이트를 제공 할 것입니다.

3. 2026년 7월 21일 PM 2:54 UTCresolved

   우리는 문제가 해결되었는지 확인했습니다. 우리는이 문제에 영향을 미칠 수 있습니다. 우리는 이 문제를 통해 일하면서 인내와 파트너십을 평가합니다. 우리는 우리의 상태 페이지에 공유될 상세한 뿌리 원인 분석 (RCA)를 가진 7 영업일 안에 위로 따를 것입니다. 질문이나 우려 사항이 있으시면 Anaplan Support에서 연락 주시기 바랍니다.

4. 2026년 7월 30일 PM 10:22 UTCpostmortem

   7월 21, 2026일, 14:15 UTC와 14:50 UTC 사이, us5: Cloud - 미국 동부 지역은 예정된 CloudWorksTM 통합에 대한 혼란을 경험했습니다. 이 창에서 자동화된 워크플로는 트리거되지 않고 사용자들은 통합 서비스를 경험할 수 있습니다. ** 루트 원인 ** 이 문제는 시스템 릴리스 롤백을 따르는 저장 시스템의 중단에 의해 트리거되었습니다. 이 통합 스케줄러 시스템 내에서 연결의 손실로 주도, 성공적으로 누락되거나 트리거 된에서 예정된 작업을 방지. ** 복구 ** 우리의 엔지니어링 팀은 문제를 확인하고 즉각적인 조치를 취했습니다. 자동적으로 복구된 서비스로 시스템 연결이 검증되고, 일정한 워크플로를 검증하기 위해 테스트 통합을 실행합니다. 이 검증 검사는 모든 스케줄링 메커니즘이 시스템 재시작을 필요로하지 않고 안전하게 정상 작업을 재개했다고 확인했습니다. 14:50 UTC에 의해, 문제는 완전히 해결되었습니다. **차단 및 예방 조치 ** * 우리는 높은 부하 조건 하에서 안정성을 보장하기 위해 롤백 작업 중에 시스템 성능으로 깊은 조사를 실시하고 있습니다. * 우리는 통합 스케줄러에 대한 향상된 건강 검사를 구현하여 트래픽이 rollbacks 중 경로를 따라 "ready"상태에 도달합니다. * 우리는 모든 지역 업데이트 또는 롤백에 따라 작업 큐 깊이의 자동화 검증을 포함하는 배포 프로세스를 업데이트하고 있습니다. * 우리는 배포 및 롤백 작업을 위해 충분한 용량을 보장하기 위해 권장된 요청/제한 값으로이 서비스에 대한 우리의 리소스 정리 문서를 업데이트하고 있습니다. 우리는이 문제에 영향을 미칠 수 있습니다 귀하의 비즈니스 운영에. 우리는 우리의 시스템 및 절차를 강화하여 비즈니스 및 사용자에 대한 혼란을 방지합니다. 질문이 있거나 우려 사항이 있으시면 [지원] (https://www.google.com/url?q=https%3A%2F%2Fsupport.anaplan.com%2F) 웹 사이트를 방문하십시오. 우리는이 사건에서 당신의 인내를 평가하고 Anaplan에서 당신을 신뢰합니다.

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

1. 2026년 7월 14일 PM 8:04 UTCinvestigating

   Cloudworks 통합을 실행하는 고객의 능력에 영향을 미치는 문제를 조사하고 있습니다. 우리는 가능한 한 빨리이 문제를 해결하기 위해 노력하고 30 분 또는 해결시 업데이트를 제공합니다.

2. 2026년 7월 14일 PM 9:00 UTCmonitoring

   뭔가 잘못되었는지 궁금해했습니다. 우리는 현재 문제가 투자하고 있으며 곧 업데이트를 제공합니다.

3. 2026년 7월 14일 PM 9:04 UTCmonitoring

   서비스는 이제 복원되었습니다; 당신은 지금 정상 활동을 이력서 할 수 있어야합니다. 우리는 플랫폼을 계속 모니터링하여 추가 문제가 발생하지 않도록합니다. 질문, 우려 사항이 있거나 문제가 계속되는 경우, Anaplan Support에 연락하는 것을 망설이지 마십시오. 우리는이 상황을 완전히 해결하기 위해 최종 업데이트를 제공 할 것입니다.

4. 2026년 7월 14일 PM 9:12 UTCresolved

   우리는 문제가 해결되었는지 확인했습니다. 우리는이 문제에 영향을 미칠 수 있습니다. 우리는 이 문제를 통해 일하면서 인내와 파트너십을 평가합니다. 우리는 우리의 상태 페이지에 공유될 상세한 뿌리 원인 분석 (RCA)를 가진 7 영업일 안에 위로 따를 것입니다. 질문이나 우려 사항이 있으시면 Anaplan Support에서 연락 주시기 바랍니다.

5. 2026년 7월 22일 PM 6:15 UTCpostmortem

   7월 14, 2026, 19:55 UTC에서, 우리의 us7에 있는 고객: 구름 - 미국 서쪽 지역은 CloudWorksTM 통합 일 처리에 있는 지연 그리고 실패를 경험했습니다. 이 지역에서 실행할 예정된 통합 작업은 예상대로 완료되지 않았으며, 한 번의 서비스가 완전히 복원되었습니다. 뿌리 원인 CloudWorksTM 서비스를 지원하는 백엔드 구성 요소는 사용 가능한 메모리를 일시적으로 배출하여 간단한 연결 중단으로 이어졌습니다. 데이터베이스가 즉시 복구되었지만 CloudWorksTM 처리 구성 요소가 비활성 연결을 유지하고 자동으로 재연결 할 수 없습니다. 이 예방된 통합 작업에서 완료 및 예정된 작업의 수를 축적. 관련 기사 우리의 엔지니어링 팀은 문제를 확인하고 즉각적인 조치를 취했습니다. CloudWorksTM 처리 구성품을 다시 시작으로 모든 stale과 inactive 연결을 삭제했습니다. 통합 작업의 backlog를 신속하게 삭제하려면, 우리는 일시적으로 구성 요소의 처리 용량을 증가. 통합 작업이 정상적으로 완료되었는지 확인한 후, backlog는 완전히 처리되었습니다, 우리는 그것의 본래 수용량에 체계를 돌려주었습니다. 으로 21:14 UTC, 문제는 완전히 해결되었습니다. 부정 및 예방 조치 우리는 반복을 방지하기 위해 다음 조치를 시행하고 있습니다. * ** 메모리 할당 증가: ** 우리는 us7에 있는 백엔드 성분을 위한 기억 할당을 증가하고 있습니다. 이것은 미래의 유사한 메모리 압력 사건의 likelihood를 감소시킵니다. * ** 배경 공정 최적화:** 백엔드 컴포넌트에 불필요한 부하를 기여한 특정 배경 메트릭 컬렉션 프로세스를 비활성화했습니다. 이 더 낮은 시간 이상 메모리 압력 건물의 위험. * ** 탄력 테스트 :** 우리의 엔지니어링 팀은 비 생산 환경에서 제어 테스트를 실행하여 CloudWorksTM 서비스는 간단한 연결 중단 중에 행동하는 방법을 잘 이해합니다. 이 작업은 수동 개입을 필요로하지 않고 자동으로 복구 할 수있는 서비스 능력을 향상 시키는 데 도움이 될 것입니다. - 비슷한 이벤트가 미래에 발생합니다. 우리는이 문제에 영향을 미치는 영향에 대해 설명합니다. 우리는 비슷한 붕괴를 방지하기 위해 위의 개선에 최선을 다하고 있습니다. 질문이나 우려 사항이 있으시면 [지원](https://support.anaplan.com/)로 문의하십시오.

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

1. 2026년 7월 2일 AM 12:00 UTCinvestigating

   우리는 현재 Anaplan 플랫폼에 액세스 할 수있는 고객의 능력에 영향을 미치는 문제를 조사하고 있습니다. 우리는 가능한 한 빨리이 문제를 해결하기 위해 노력하고 30 분 또는 해결시 업데이트를 제공합니다.

2. 2026년 7월 2일 AM 12:30 UTCinvestigating

   우리는이 문제를 조사 계속하기 때문에 당신의 인내심을 주셔서 감사합니다. 우리는 현재 영향을받는 지역 내에서 전체 불균형을 유발하는 중요한 서비스 중단을 경험하고 있습니다. 이 지역에서 액세스 서비스를 시도하는 사용자는 연결 timeout 및 실패를 로드 리소스에 만날 것입니다. 현재, 우리는 아직 해결 시간이 없습니다. 우리는 우리가 가능한 한 빨리이 문제를 해결하기 위해 노력으로 30 분마다 업데이트를 계속할 것입니다.

3. 2026년 7월 2일 AM 12:59 UTCinvestigating

   ME1 및 EU5 지역의 고객에 대한 로그인 및 플랫폼 액세스에 영향을 미치는 이슈를 조사하고 있습니다. 초기 조사는 해당 지역의 인증 경로에 대한 혼란에. 이 해결은 우리의 가장 높은 우선 순위이며, 우리의 엔지니어링 팀은 정상적인 작업을 복원하기 위해 적극적으로 노력하고 있습니다. ETA는 아직 없습니다. 우리는 30 분 안에 또 다른 업데이트를 제공 할 것입니다, 또는 우리가 중요한 새로운 정보를 가지고 있다면 더 빨리.

4. 2026년 7월 2일 AM 1:29 UTCinvestigating

   ME1 및 EU5 지역에 영향을 미치는 로그인 및 플랫폼 액세스 문제에 대한 우리의 조사가 진행 중입니다. 우리는 우리가 확인하고 뿌리 원인을 해결하기 위해 일하기 위하여 추가 지원을 위한 우리의 납품업자를 관여시켰습니다. 이 문제를 해결하는 것은 우리의 최우선 과제입니다. 아직 ETA가 없습니다. 우리는 30 분 안에 우리의 다음 갱신을, 또는 우리가 뜻깊은 새로운 정보가 있는 경우에 빨리 제공할 것입니다.

5. 2026년 7월 2일 AM 1:58 UTCinvestigating

   ME1 및 EU5 지역에 영향을 미치는 로그인 및 플랫폼 액세스 문제에 대한 우리의 조사가 진행 중입니다. 우리의 엔지니어링 팀은 조사를 축소하고 우리의 인프라 파트너와 공동으로 여러 개의 문의 라인을 적극적으로 추구하고 있습니다. 복원 서비스는 가장 높은 우선 순위를 유지. 아직 ETA가 없습니다. 우리는 30 분 안에 우리의 다음 갱신을, 또는 우리가 뜻깊은 새로운 정보가 있는 경우에 빨리 제공할 것입니다.

6. 2026년 7월 2일 AM 2:27 UTCinvestigating

   ME1 및 EU5 지역의 고객에게 로그인 및 플랫폼 액세스에 영향을 미치는 이슈를 조사하고 있습니다. 문제는 7 월 2026에서 약 23:52 UTC로 시작되었습니다. 우리의 Infrastucture 파트너와 공동으로, 우리는 성공적으로 잠재적 인 원인을 축소하고 현재 목표를 달성하는 데 문제가 발생하기 위해 엔지니어링 노력을 집중하고 있습니다. 우리 팀은 가능한 한 빨리이 문제를 해결하기 위해 최선을 다하고 있습니다. 우리는 30 분 안에 우리의 다음 갱신을, 또는 우리가 뜻깊은 새로운 정보가 있는 경우에 빨리 제공할 것입니다.

7. 2026년 7월 2일 AM 2:55 UTCinvestigating

   ME1 및 EU5 지역의 고객에 대한 로그인 및 플랫폼 액세스에 영향을 미치는 문제를 조사하고 있습니다. 우리는 잠재적 인 원인을 확인하고 문제를 해결하고 전체 서비스를 복원하기 위해 완화 단계를 적극적으로 진행하고있다. 업데이트가 계속됩니다. 우리는 30 분 안에 우리의 다음 갱신을, 또는 우리가 뜻깊은 새로운 정보가 있는 경우에 빨리 제공할 것입니다.

8. 2026년 7월 2일 AM 3:21 UTCmonitoring

   서비스는 이제 복원되었습니다; 당신은 지금 정상 활동을 이력서 할 수 있어야합니다. 우리는 플랫폼을 계속 모니터링하여 추가 문제가 발생하지 않도록합니다. 질문, 우려 사항이 있거나 문제가 계속되는 경우, Anaplan Support에 연락하는 것을 망설이지 마십시오. 우리는이 상황을 완전히 해결하기 위해 최종 업데이트를 제공 할 것입니다.

9. 2026년 7월 2일 AM 4:00 UTCresolved

   우리는 문제가 해결되었는지 확인했습니다. 우리는이 문제에 영향을 미칠 수 있습니다. 우리는 이 문제를 통해 일하면서 인내와 파트너십을 평가합니다. 우리는 우리의 상태 페이지에 공유될 상세한 뿌리 원인 분석 (RCA)를 가진 7 영업일 안에 위로 따를 것입니다. 질문이나 우려 사항이 있으시면 Anaplan Support에서 연락 주시기 바랍니다.

10. 2026년 7월 10일 PM 6:35 UTCpostmortem

    7 월 1, 2026, 약 23 : 52 UTC에서, 우리의 모니터링 시스템은 me1 : Cloud - Middle East 및 eu5 : Cloud - Europe 지역의 서비스 중단 영향을 감지했습니다. 이 시간 동안 영향을받는 고객은 플랫폼에 로그인 할 수 없습니다. 서비스는 03:21 UTC에 복원되었습니다. ** 루트 원인 ** 중단은 계획된 네트워크 구성에서 우리의 내부 이름 해결책 인프라로 변화합니다. 잘못된 구성이 도입 된 변경의 일부로 인해 routing 충돌을 남겨두고 있습니다. 이로 인해 내부 이름의 반환 트래픽은 일상적인 네트워크 활동 중에 잘못된 경로로 이동합니다. 결과적으로 내부 이름 해상도는 두 가지 영향을받는 지역에 실패했습니다. 인증 흐름을 완료하고 로그인에서 고객을 중지. ** 복구 ** 23:52 UTC의 감지에, 우리의 엔지니어링 팀과 우리의 인프라 파트너는 병렬에 투자를 시작했다. 내부 이름 해상도 문제가 여러 가지 방법으로 자신을 제시 할 수 있기 때문에 팀은 특정 룰렛 충돌을 격리하기 전에 여러 줄의 문의 작업을 수행했습니다. 일단 확인되면, 우리는 이전 알려진 좋은 라우팅 구성을 복원하기 위해 최근 변경을 압연. 커넥티비티는 롤백 번식으로 진보적으로 회복되었으며, 03:21 UTC에 의해 인증은 영향을받는 지역에 완전히 복원되었습니다. **차단 및 예방 조치 ** 우리는 다음과 같은 작업을 수행하여 재발생을 방지합니다. * 우리는 이 사건에 책임있는 여정의 종류를 특별히 검출하는 전 변화 검증을 추가하고 있습니다. 이 모든 유사한 변화가 환경에 도달하기 전에 부분적으로 구성 문제를 닫습니다. * 이 클래스를 다시 도입하기 위해 영향을 미칩니다. 이것은 소스의 밑으로 문제점을 제거합니다. * 우리는 우리의 구름 환경 사이 내부 이름 해결책 경로에 대한 우리의 감시를 개량하고 있습니다. 이 짧은 시간을 감지하고 문제의이 종류를 해결합니다. ** 닫기 ** 우리는이 혼란에 영향을 미치는 영향에 대해 사과합니다. 위의 정확한 행동은 미래의 유사한 문제의 재발을 방지하는 데 중점을 둡니다. 질문이나 우려 사항이 있으시면 [지원](https://support.anaplan.com/)로 문의하십시오.

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

1. 2026년 6월 22일 AM 7:29 UTCinvestigating

   We are currently investigating an issue resulting in some customers not being able to load models. We are working to resolve this issue as quickly as possible and will provide updates every 30 minutes or upon resolution.

2. 2026년 6월 22일 AM 7:48 UTCinvestigating

   Thank you for your patience as we continue to investigate this issue. Currently, we do not yet have a time to resolution. We will continue to provide updates every 30 minutes as we work to resolve this issue as quickly as possible.

3. 2026년 6월 22일 AM 8:23 UTCinvestigating

   We are actively investigating a service disruption currently affecting customers' ability to open Models. This issue is also affecting CloudWorks Integrations. Our engineering teams are prioritizing this issue and evaluating immediate mitigation steps to restore full service as quickly and safely as possible. We do not yet have an estimated time to resolution, but will provide progress updates every 30 minutes or sooner.

4. 2026년 6월 22일 AM 8:52 UTCidentified

   We are progressing with active mitigation steps to resolve the disruption affecting Model opening and CloudWorks integrations. Initial reports indicate positive outcomes from these activities. Our engineering teams are closely monitoring system stability while we complete the remaining mitigation steps to ensure a full and durable recovery. We will continue to provide updates every 30 minutes as we work to bring all systems back to standard operations.

5. 2026년 6월 22일 AM 9:25 UTCidentified

   We are currently proceeding with the final remediation steps while continuing our investigation into the root cause. Customers should now be able to open models, though some may still encounter temporary delays; however, CloudWorks integrations are not yet completing. We are monitoring these recovery steps closely to ensure full system stability and will continue to provide updates every 30 minutes.

6. 2026년 6월 22일 AM 9:36 UTCidentified

   We are pleased to report that all issues affecting model loading have been fully resolved, and normal access has been restored. Additionally, CloudWorks integrations are running again, and our teams are currently processing the accumulated backlog of queued jobs. We are monitoring the queue progression closely to ensure all delayed integrations complete successfully. We will provide our next update in 30 minutes or once the backlog is fully cleared.

7. 2026년 6월 22일 AM 10:05 UTCidentified

   Our teams confirm that the CloudWorks integration backlog is actively processing and recovering. Access to opening models remains fully restored and stable. We are continuing to monitor the integration queues closely as jobs complete, and we will provide our next status update in 30 minutes.

8. 2026년 6월 22일 AM 10:22 UTCmonitoring

   Service has now been restored; you should now be able to resume normal activities. We will continue to monitor the platform to ensure no additional issues arise. If you have any questions, concerns, or continue to experience issues, please do not hesitate to contact Anaplan Support. We will provide a final update to you when we consider this situation fully resolved.

9. 2026년 6월 22일 AM 10:52 UTCresolved

   We have confirmed that the issue is now resolved. We deeply apologize for any impact this issue may have caused. We appreciate your patience and partnership as we worked through this issue. We will follow up within 7 business days with a detailed root cause analysis (RCA) that will be shared on our Status Page. If you have any question or concerns, please do not hesitate to contact us at Anaplan Support.

10. 2026년 7월 1일 PM 7:34 UTCpostmortem

    On June 22, 2026, at 07:20 UTC, we became aware of an issue affecting our us7: Cloud – US region. Customers experienced difficulties loading models, with impact beginning at approximately 05:12 UTC. CloudWorks™ integrations in the region were also unable to run during this period. Customers with active workspace sessions weren't affected. However, any workspace that was unloaded during this time couldn't be loaded until service was restored. Full service was restored at 10:21 UTC.  **Root cause**  A component that manages active workspace resources in the us7 region encountered an unexpected fault and restarted. On restart, the component entered a state where it appeared to be operating normally but couldn't process new workspace requests. Our systems normally recover automatically from this kind of state, but in this case the fault wasn't detected by our recovery processes. We intervened manually and performed a corrective restart of the component, which restored normal operation.  **Recovery**  We conducted a thorough investigation of the platform and identified the source of the issue. We performed a targeted reset of the resource scheduling services to clear the pending connections and restore normal communication. Once communication was re-established at 08:48 UTC, the platform began successfully assigning resources and loading models.  To handle the accumulated backlog of scheduled integrations, we scaled up the processing capacity for CloudWorks™. By 10:21 UTC, the backlog had finished processing, and the issue was fully resolved.  **Corrective and preventative actions**  We're implementing the following actions to prevent recurrence:  * We're deploying enhanced automated monitoring specifically designed to detect the condition seen in this incident, where a component appears operational but isn't processing requests. This closes the detection gap that extended the impact of this issue.  * We're developing automated self-healing for the resource scheduling component, so that a corrective restart can be performed automatically without engineering intervention. This directly addresses the failure mode that caused this incident.  * We're streamlining our scaling procedures for CloudWorks™, so that integration processing capacity can be expanded more rapidly during recovery. This shortens the time to clear integration backlogs following incidents like this one.  We apologize for any impact this issue may have had on your business operations. We are continuously strengthening our systems and procedures to ensure we avoid future disruptions to your business and users.  If you have further questions or concerns, please visit our [Support](https://support.anaplan.com/) website. We appreciate your patience during this incident and value the trust you place in Anaplan.

1. 2026년 6월 17일 AM 7:02 UTCinvestigating

   We are currently investigating an issue resulting in some customers not being able to load models. We are working to resolve this issue as quickly as possible and will provide updates every 30 minutes or upon resolution.

2. 2026년 6월 17일 AM 8:00 UTCinvestigating

   Thank you for your patience as we continue to investigate this issue. Currently, we do not yet have a time to resolution. We will continue to provide updates every 30 minutes as we work to resolve this issue as quickly as possible.

3. 2026년 6월 17일 AM 8:31 UTCinvestigating

   Thank you for your patience as we continue to investigate this issue. Our technical teams are fully engaged, and restoring normal service operations as quickly and safely as possible is our absolute priority. Currently, we do not yet have a time to resolution. We will continue to provide updates every 30 minutes as we work to resolve this issue as quickly as possible.

4. 2026년 6월 17일 AM 8:59 UTCinvestigating

   Thank you for your patience as we continue to investigate this issue. Our coordinated technical response has made progress in narrowing down the scope of our investigation. We have isolated the primary area of concern to our storage configuration layer and are evaluating mitigation steps to alleviate the issue. Currently, we do not yet have a time to resolution. We will continue to provide updates every 30 minutes as we work to resolve this issue as quickly as possible.

5. 2026년 6월 17일 AM 9:22 UTCidentified

   We have identified the likely cause of the issue, and we are focused right now on restoring service as quickly as possible. We have identified mitigation steps to alleviate the issue and initial reports indicate positive outcomes of these activities. Currently, we do not yet have a time to resolution. We will provide further updates in 30 minutes or upon resolution.

6. 2026년 6월 17일 AM 9:50 UTCidentified

   We are pleased to report a significant milestone in our resolution efforts. Our cross-functional engineering teams have successfully validated a targeted configuration adjustment to restore access to the affected workspaces. We have initiated a phased deployment of this mitigation across the region to safely and systematically restore full access to all affected workspaces. Currently, we do not yet have a time to resolution. We will provide further updates in 30 minutes or upon resolution.

7. 2026년 6월 17일 AM 10:06 UTCmonitoring

   Service has now been restored; you should now be able to resume normal activities. We will continue to monitor the platform to ensure no additional issues arise. If you have any questions, concerns, or continue to experience issues, please do not hesitate to contact Anaplan Support. We will provide a final update to you when we consider this situation fully resolved.

8. 2026년 6월 17일 AM 10:23 UTCresolved

   We have confirmed that the issue is now resolved. We deeply apologize for any impact this issue may have caused. We appreciate your patience and partnership as we worked through this issue. We will follow up within 7 business days with a detailed root cause analysis (RCA) that will be shared on our Status Page. If you have any question or concerns, please do not hesitate to contact us at Anaplan Support.

9. 2026년 6월 26일 PM 5:41 UTCpostmortem

   On June 17, 2026, at 06:50 UTC, we became aware of an issue affecting a subset of workspaces in our eu4: Cloud - Europe region. Customers with affected workspaces were unable to load models, seeing persistent loading screens or errors when opening their work. CloudWorks™ integrations in the region also experienced a period of degradation, from approximately 05:20 UTC to 06:26 UTC, because of the same underlying issue. The impact was limited to a specific subset of workspaces — all other regions, and many workspaces in eu4: Cloud - Europe, continued to operate normally. Full service for the affected workspaces was restored at 10:00 UTC.   Root cause  The affected workspaces ran on a previous storage configuration in the eu4 region. Over time, a storage directory used by these workspaces accumulated a large number of small temporary files. The directory reached its operational limit and could no longer accept new file operations. This prevented models from loading for customers whose workspaces were running on this configuration.  Recovery  Our engineering team cleared the accumulated temporary files, which provided immediate relief. We then moved all affected workspaces from the old configuration to the new configuration through an automated process. We checked that model loading was restored through testing. By 10:00 UTC, the issue was fully resolved. On the same day, we implemented a change across the eu4 region to make sure no workspace can be directed to the old configuration.  Corrective and preventative actions  We've taken the following actions to address this incident and prevent it from happening again:  1. We've deployed an update across all regions that prevents any workspace from being directed to the older storage configuration. This eliminates the specific configuration condition that caused this incident.  2. We're decommissioning the older storage configuration. This permanently removes the configuration that caused this incident.  3. We’re strengthening our automated validation checks to confirm that workspaces are running on the correct configuration. This catches any configuration mismatch before it can cause customer impact.  4. We're implementing automated cleanup rules for the temporary files involved in this incident. This prevents storage directories from reaching operational limits and supports faster automatic recovery.  Closing  We apologize for the impact this issue has had on your operations. We're committed to the improvements outlined above to prevent similar disruptions. If you have questions or concerns, please contact [Support](https://support.anaplan.com/).

1. 2026년 6월 11일 PM 5:20 UTCinvestigating

   We are currently investigating an issue impacting customers’ ability to access the Anaplan Platform. We are working to resolve this issue as quickly as possible and will provide updates every 30 minutes or upon resolution.

2. 2026년 6월 11일 PM 5:45 UTCidentified

   We want to sincerely apologize to our customers for the continued disruption to the Anaplan Platform today. We understand how critical access to Anaplan is for your business, and we deeply regret the impact this is having on your teams. Our engineers have identified the root cause of this issue and are actively working to restore service. We are currently executing remediation steps and will continue to provide updates here every 30 minutes until full service is restored.

3. 2026년 6월 11일 PM 6:15 UTCidentified

   We want to start by offering our sincere apologies to every customer affected by today's disruption to the Anaplan Platform. We know your teams rely on Anaplan to do critical work. Our engineering team has identified the root cause and is fully focused on resolution. Active remediation steps are underway, and we are committed to keeping you informed with updates every 30 minutes — or sooner if there is meaningful progress to share.

4. 2026년 6월 11일 PM 6:27 UTCmonitoring

   We are pleased to share that the core Anaplan Platform has successfully recovered and all primary services are fully operational. Our engineering teams are actively monitoring platform stability while corrective actions to address the underlying root cause continue to advance. We sincerely apologize for the disruption today and recognize that this has been a difficult week for many of our customers. Restoring your trust and ensuring platform stability remains our highest priority. Next update: In 30 minutes or sooner

5. 2026년 6월 11일 PM 6:47 UTCmonitoring

   Our engineering team has successfully implemented a targeted infrastructure patch and completed a controlled failover to the updated version. All primary services are fully restored and accessible to customers. Our teams remain in active monitoring as we continue to validate the patch and advance corrective work across the remaining infrastructure. We do not anticipate further disruption at this time, and we will continue to monitor platform performance closely over the next several hours. We sincerely apologize for the impact today's incidents have had on your teams. A full incident summary will be published once our corrective actions are complete.

6. 2026년 6월 12일 AM 12:30 UTCmonitoring

   The issue impacting access to the Anaplan Platform across all affected regions has been mitigated. The platform is stable and all services have returned to normal operation. Corrective measures to prevent recurrence are actively advancing and will continue to be applied to ensure this issue does not reoccur. We are continuing to monitor the platform to confirm stability. We do not anticipate any further customer impact from these activities. We appreciate your patience and partnership. If you have any questions or concerns, please do not hesitate to contact us at Anaplan Support.

7. 2026년 6월 12일 PM 3:09 UTCresolved

   We would like to provide you with the latest update regarding the recent service disruption affecting our platform. Working in close collaboration with our vendor, our engineering team were able to identify a software bug in our network infrastructure that was causing temporary connection instability. To resolve the instability, we applied the fix recommended by the Vendor for the software bug, then successfully moved platform traffic to updated infrastructure at 18:17 UTC on 11 June. All connections stabilised with no disruption observed post the transition. Since then, the platform has remained stable and our engineering teams have continued to monitor this closely. This is our final update on this incident. We will provide a thorough Root Cause Analysis (RCA) within 7 business days. Thank you for your patience and understanding throughout this incident.

8. 2026년 6월 19일 PM 2:38 UTCpostmortem

   **June 8–12, 2026 Platform Disruptions** On June 8, 2026, at 11:05 UTC, our monitoring detected a brief drop in incoming traffic across the Anaplan platform, with automated monitoring checks failing across all affected regions \(us1: Data Center - US East, us2: Data Center - US West, eu1: Data Center - Netherlands, eu2: Data Center - Germany, eu4: Cloud - Europe, us5: Cloud - US East, us7: Cloud - US, and ap1: Cloud - Japan\). Over the four days, a series of related disruptions affected the same regions. Customers experienced intermittent difficulties logging in, opening models, and running integrations. The platform was fully stabilized on June 11, 2026, at 18:12 UTC. These disruptions are linked to our previously communicated infrastructure modernization program. On the weekend of June 6, we migrated our control plane, the part of the platform that directs how traffic is routed between services. This was the most complex of the planned migration weekends, and it was completed successfully, as had the two previous migration weekends. The issues described in this report emerged in the days following that migration. This report covers the seven linked incidents that occurred between June 8 and June 11, 2026. **Root cause** As part of our infrastructure modernization program, on the weekend of June 6, we completed a successful migration of our control plane. In the days that followed, we observed two discrete network-hardware issues that interacted to drive these disruptions. _Issue 1: Media Access Control \(MAC\) flapping \(June 8–9\)_ Every device on a network has a MAC address, a unique hardware identifier that network switches use to route traffic to the correct destination. In our environment, the MAC addresses involved are virtual — assigned to logical network gateways rather than to fixed physical hardware — which allows them to legitimately move between hosts as part of normal operation. MAC flapping occurs when a switch sees the same MAC address appearing on two different physical ports in rapid succession, forcing it repeatedly to update its routing tables. This briefly slows or interrupts traffic. For customers, this surfaced as a brief, self-recovering instability. Short bursts of load and intermittent errors appeared and cleared on their own within minutes. The trigger for this behavior was the specific way live production traffic interacted with the new post-migration network. To resolve the issue, we scaled capacity, engaged our vendor, and deployed configuration changes to contain the impact. _Issue 2: network card driver defect \(June 10–11\)_ Once the first set of mitigations were in place, we identified a second issue: A defect in the network card driver, which is the software that controls how a network card sends and receives data. The defect affected fewer than 0.005% of the cards in our estate. Those cards failed randomly and unpredictably, dropping traffic while still appearing healthy to our monitoring systems. This is known as a "gray failure" condition, because the affected components don’t flag themselves as broken. The cards sat in the part of the network that routes traffic between the regions impacted. This resulted in failures that cascaded across the platform and drove disruptions on June 10 and June 11. The defect hadn't been observed in previous migrations or in any other environment, and there were no indicators in pre-deployment testing. The gray failure pattern was also what initially masked the defect as a load issue, until further investigation pointed us to the driver itself. We engaged our vendor, who confirmed the defect. Working closely with them, we rapidly prepared, tested, and deployed the patch to the affected hosts on the evening of June 11, UTC. After that, the platform stabilized. **Recovery** From the first occurrence on June 8 through to permanent resolution on June 11, our engineering team led a continuous, round-the-clock response, working closely with our vendor to identify, diagnose, and resolve the underlying defect. We deployed configuration mitigations, repeatedly rerouted traffic between hosts and across alternative network paths, and scaled out capacity to restore service to customers as quickly as possible while the underlying defect was being addressed. The seven linked incidents and their impact windows were: * **June 8, 2026, 11:00–11:20 UTC** — A short network disruption from the initial MAC flapping event caused intermittent login failures and slow page loads. For most customers, this appeared as a brief 6-minute blip and recovered automatically. Some basic authentication users experienced a longer impact and needed to start a new browser session, with full recovery by 11:20 UTC. * **June 9, 2026, 11:05–11:29 UTC** — A recurrence of the same MAC flapping condition caused a similar brief disruption. Again, most customers experienced only a short blip of around 6 minutes, with basic authentication users seeing a longer impact. We applied scaling changes to address the issue. * **June 10, 2026, 11:02–12:40 UTC** — Customers across all affected regions experienced a loss of access to the platform for approximately 98 minutes. We worked with the vendor and applied configuration changes to address the issue. * **June 10–11, 2026, 23:06–00:04 UTC** — A disruption of approximately 58 minutes, caused when the network card defect affected the backup host that traffic had been moved to. We restored connectivity by moving traffic onto an alternative network path. * **June 11, 2026, 03:43–05:20 UTC** — A disruption of approximately 97 minutes, as the next backup host was affected by the same defect. We restored connectivity by moving traffic onto an alternative network path. * **June 11, 2026, 11:10–13:02 UTC** — A further recurrence of the network traffic surge caused customers to experience slow or failed access to the platform. We restored service by applying an underlying configuration change. * **June 11, 2026, 17:04–17:48 UTC** — A final disruption of approximately 44 minutes during which we moved traffic to a host running the updated network card driver. The platform was fully stabilized at 18:12 UTC on June 11, 2026, once traffic was successfully moved to a host running the updated network card driver. We then applied the same update to a second host for resilience. Monitoring continued through to midday Friday before the incident was closed. CloudWorks™ experienced a backlog of queued jobs during and immediately after each disruption. Our engineering team scaled out CloudWorks capacity to accelerate processing, and the backlog was fully cleared shortly after each recovery. **Corrective and preventative actions** The control plane migration that preceded these disruptions was a one-time, foundational piece of work. The actions below reflect the learnings we are carrying forward from the event to further strengthen the platform. 1. The updated network card driver has been rolled out across all hosts matching the affected hardware profile, in every region. This removes the underlying defect from our infrastructure, even though it hasn't been observed in any other region. 2. The conditions that allowed MAC flapping to surface as customer-visible instability have been addressed at multiple layers. Configuration changes have been deployed in the affected regions. The underlying network configuration has been standardized across the wider production estate, and we have tuned the network behavior that triggered the initial event. 3. During the incident, our engineering team deployed dedicated alerting in real time for the specific network conditions causing the disruptions, enabling faster detection and intervention throughout the response. We are continuing to strengthen proactive monitoring and early-warning detection across post-release windows, so that emerging anomalies are surfaced and investigated before they escalate into customer-visible disruptions. 4. The remaining infrastructure update that supports the network card fix is being completed across our other environments. This brings the full benefit of the fix to every part of our infrastructure. **What's next** One final migration weekend is scheduled for June 20, 2026. After this, the migration phase of the infrastructure modernization program is complete. **Closing** We apologize for the impact this issue has had on your operations. We're committed to the improvements outlined above to prevent similar disruptions. If you have questions or concerns, please contact [Support](https://support.anaplan.com/).

1. 2026년 6월 11일 AM 4:32 UTCinvestigating

   We are currently investigating an issue impacting customers’ ability to access the Anaplan Platform. We are working to resolve this issue as quickly as possible and will provide updates every 30 minutes or upon resolution.

2. 2026년 6월 11일 AM 4:58 UTCinvestigating

   Thank you for your patience as we continue to investigate this issue. Currently, we do not yet have a time to resolution. We will continue to provide updates every 30 minutes as we work to resolve this issue as quickly as possible.

3. 2026년 6월 11일 AM 5:03 UTCidentified

   The symptoms currently being observed are similar to the platform issue experienced earlier today. Our engineering and operations teams have been immediately mobilized and are actively diagnosing the root cause. We treat any recurrence with the utmost urgency and priority. We sincerely apologize for this disruption, we treat any recurrence with the utmost urgency and priority. We will provide another update in 30 minutes, or sooner as we obtain more actionable technical details.

4. 2026년 6월 11일 AM 5:25 UTCidentified

   We are beginning to see signs of platform recovery, and primary services are starting to stabilize. As systems come back online, a backlog of queued CloudWorks jobs has accumulated and is currently processing. Our engineering teams are closely monitoring the stability of the platform and tracking the queue clearance velocity. We will provide our next update in 30 minutes, or sooner as we confirm continued stability.

5. 2026년 6월 11일 AM 5:44 UTCmonitoring

   The platform has successfully recovered and is exhibiting stable performance. We are now focused on clearing the accumulated backlog of CloudWorks jobs. Our engineering teams are actively managing and verifying the processing queue to ensure all delayed jobs complete as quickly and safely as possible. We will continue to supervise the queue clearance and will provide our next update in 30 minutes, or sooner as we approach full restoration. If you have any questions, concerns, or continue to experience issues, please do not hesitate to contact Anaplan Support. We will provide a final update to you when we consider this situation fully resolved.

6. 2026년 6월 11일 AM 6:14 UTCmonitoring

   The platform remains stable and fully operational. We are continuing to process the remaining backlog of CloudWorks jobs. Our engineering teams are actively overseeing the processing queues to ensure all jobs complete successfully and system performance remains steady. We appreciate your continued patience as we work through this remaining queue. We will provide our next update in 30 minutes, or sooner as queue clearance nears completion.

7. 2026년 6월 11일 AM 6:30 UTCmonitoring

   Service has now been restored; you should now be able to resume normal activities. We will continue to monitor the platform to ensure no additional issues arise. If you have any questions, concerns, or continue to experience issues, please do not hesitate to contact Anaplan Support. We will provide a final update to you when we consider this situation fully resolved.

8. 2026년 6월 11일 AM 11:05 UTCmonitoring

   We want to keep you informed with the latest update on the service disruption affecting our platform. What we've done We have identified the source of the instability and are actively working to resolve it. Our engineering team, in collaboration with our vendor, has already implemented a configuration change that has reduced the frequency of errors. We are monitoring the platform closely and have seen improvement as a result. We are aware that some customers are experiencing delays and interruptions with their CloudWorks integrations as a direct result of this incident. Our engineering team is actively identifying and resolving any affected integration jobs. Current status The platform is operational. Integration processing is being actively monitored and remediated. We will not consider this incident closed until we are fully satisfied that the platform is stable, all integration jobs are running normally, and the risk of recurrence has been addressed. We will now provide updates every 2 hours, as our investigation progresses and we work with our Vendor. We understand the impact this has had on your operations and we appreciate your patience.

9. 2026년 6월 11일 PM 2:01 UTCmonitoring

   We want to keep you informed with the latest update on the service disruption affecting our platform. After collaboration with our Vendor, we have identified two fixes to our underlying infrastructure. The first fix has now been implemented successfully without further disruption and initial monitoring is proving positive. We are continuing to liaise with our Vendor for the secondary fix, to ensure no further disruption is caused. The platform remains stable and all Cloudworks integrations are working as expected and the backlog has been cleared. The incident will remain open and we will provide updates every 2 hours or sooner, as we continue to investigate and have full resolution. We understand the impact this has had on your operations and we appreciate your patience

10. 2026년 6월 11일 PM 2:31 UTCresolved

    We want to provide you with the latest update regarding the recent service disruption affecting our platform. All agreed-upon fixes have been successfully implemented across our underlying infrastructure. Our ongoing monitoring shows that system performance remains stable and positive. Our engineering teams will continue to monitor the platform closely to ensure continued stability. Additionally, we are conducting thorough Root Cause Analysis (RCA) and this will be provided within 7 business days. We sincerely understand the impact this disruption has had on your daily operations, and we deeply appreciate your patience and continued partnership as we work to ensure a reliable experience.

11. 2026년 6월 19일 PM 3:02 UTCpostmortem

    **June 8–12, 2026 Platform Disruptions** On June 8, 2026, at 11:05 UTC, our monitoring detected a brief drop in incoming traffic across the Anaplan platform, with automated monitoring checks failing across all affected regions \(us1: Data Center - US East, us2: Data Center - US West, eu1: Data Center - Netherlands, eu2: Data Center - Germany, eu4: Cloud - Europe, us5: Cloud - US East, us7: Cloud - US, and ap1: Cloud - Japan\). Over the four days, a series of related disruptions affected the same regions. Customers experienced intermittent difficulties logging in, opening models, and running integrations. The platform was fully stabilized on June 11, 2026, at 18:12 UTC. These disruptions are linked to our previously communicated infrastructure modernization program. On the weekend of June 6, we migrated our control plane, the part of the platform that directs how traffic is routed between services. This was the most complex of the planned migration weekends, and it was completed successfully, as had the two previous migration weekends. The issues described in this report emerged in the days following that migration. This report covers the seven linked incidents that occurred between June 8 and June 11, 2026. **Root cause** As part of our infrastructure modernization program, on the weekend of June 6, we completed a successful migration of our control plane. In the days that followed, we observed two discrete network-hardware issues that interacted to drive these disruptions. _Issue 1: Media Access Control \(MAC\) flapping \(June 8–9\)_ Every device on a network has a MAC address, a unique hardware identifier that network switches use to route traffic to the correct destination. In our environment, the MAC addresses involved are virtual — assigned to logical network gateways rather than to fixed physical hardware — which allows them to legitimately move between hosts as part of normal operation. MAC flapping occurs when a switch sees the same MAC address appearing on two different physical ports in rapid succession, forcing it repeatedly to update its routing tables. This briefly slows or interrupts traffic. For customers, this surfaced as a brief, self-recovering instability. Short bursts of load and intermittent errors appeared and cleared on their own within minutes. The trigger for this behavior was the specific way live production traffic interacted with the new post-migration network. To resolve the issue, we scaled capacity, engaged our vendor, and deployed configuration changes to contain the impact. _Issue 2: network card driver defect \(June 10–11\)_ Once the first set of mitigations were in place, we identified a second issue: A defect in the network card driver, which is the software that controls how a network card sends and receives data. The defect affected fewer than 0.005% of the cards in our estate. Those cards failed randomly and unpredictably, dropping traffic while still appearing healthy to our monitoring systems. This is known as a "gray failure" condition, because the affected components don’t flag themselves as broken. The cards sat in the part of the network that routes traffic between the regions impacted. This resulted in failures that cascaded across the platform and drove disruptions on June 10 and June 11. The defect hadn't been observed in previous migrations or in any other environment, and there were no indicators in pre-deployment testing. The gray failure pattern was also what initially masked the defect as a load issue, until further investigation pointed us to the driver itself. We engaged our vendor, who confirmed the defect. Working closely with them, we rapidly prepared, tested, and deployed the patch to the affected hosts on the evening of June 11, UTC. After that, the platform stabilized. **Recovery** From the first occurrence on June 8 through to permanent resolution on June 11, our engineering team led a continuous, round-the-clock response, working closely with our vendor to identify, diagnose, and resolve the underlying defect. We deployed configuration mitigations, repeatedly rerouted traffic between hosts and across alternative network paths, and scaled out capacity to restore service to customers as quickly as possible while the underlying defect was being addressed. The seven linked incidents and their impact windows were: * **June 8, 2026, 11:00–11:20 UTC** — A short network disruption from the initial MAC flapping event caused intermittent login failures and slow page loads. For most customers, this appeared as a brief 6-minute blip and recovered automatically. Some basic authentication users experienced a longer impact and needed to start a new browser session, with full recovery by 11:20 UTC. * **June 9, 2026, 11:05–11:29 UTC** — A recurrence of the same MAC flapping condition caused a similar brief disruption. Again, most customers experienced only a short blip of around 6 minutes, with basic authentication users seeing a longer impact. We applied scaling changes to address the issue. * **June 10, 2026, 11:02–12:40 UTC** — Customers across all affected regions experienced a loss of access to the platform for approximately 98 minutes. We worked with the vendor and applied configuration changes to address the issue. * **June 10–11, 2026, 23:06–00:04 UTC** — A disruption of approximately 58 minutes, caused when the network card defect affected the backup host that traffic had been moved to. We restored connectivity by moving traffic onto an alternative network path. * **June 11, 2026, 03:43–05:20 UTC** — A disruption of approximately 97 minutes, as the next backup host was affected by the same defect. We restored connectivity by moving traffic onto an alternative network path. * **June 11, 2026, 11:10–13:02 UTC** — A further recurrence of the network traffic surge caused customers to experience slow or failed access to the platform. We restored service by applying an underlying configuration change. * **June 11, 2026, 17:04–17:48 UTC** — A final disruption of approximately 44 minutes during which we moved traffic to a host running the updated network card driver. The platform was fully stabilized at 18:12 UTC on June 11, 2026, once traffic was successfully moved to a host running the updated network card driver. We then applied the same update to a second host for resilience. Monitoring continued through to midday Friday before the incident was closed. CloudWorks™ experienced a backlog of queued jobs during and immediately after each disruption. Our engineering team scaled out CloudWorks capacity to accelerate processing, and the backlog was fully cleared shortly after each recovery. **Corrective and preventative actions** The control plane migration that preceded these disruptions was a one-time, foundational piece of work. The actions below reflect the learnings we are carrying forward from the event to further strengthen the platform. 1. The updated network card driver has been rolled out across all hosts matching the affected hardware profile, in every region. This removes the underlying defect from our infrastructure, even though it hasn't been observed in any other region. 2. The conditions that allowed MAC flapping to surface as customer-visible instability have been addressed at multiple layers. Configuration changes have been deployed in the affected regions. The underlying network configuration has been standardized across the wider production estate, and we have tuned the network behavior that triggered the initial event. 3. During the incident, our engineering team deployed dedicated alerting in real time for the specific network conditions causing the disruptions, enabling faster detection and intervention throughout the response. We are continuing to strengthen proactive monitoring and early-warning detection across post-release windows, so that emerging anomalies are surfaced and investigated before they escalate into customer-visible disruptions. 4. The remaining infrastructure update that supports the network card fix is being completed across our other environments. This brings the full benefit of the fix to every part of our infrastructure. **What's next** One final migration weekend is scheduled for June 20, 2026. After this, the migration phase of the infrastructure modernization program is complete. **Closing** We apologize for the impact this issue has had on your operations. We're committed to the improvements outlined above to prevent similar disruptions. If you have questions or concerns, please contact [Support](https://support.anaplan.com/).

1. 2026년 6월 10일 PM 11:14 UTCinvestigating

   We are currently investigating an issue impacting customers’ ability to access the Anaplan Platform. We are working to resolve this issue as quickly as possible and will provide updates every 30 minutes or upon resolution.

2. 2026년 6월 10일 PM 11:34 UTCinvestigating

   Thank you for your patience as we continue to investigate this issue. Currently, we do not yet have a time to resolution. We will continue to provide updates every 30 minutes as we work to resolve this issue as quickly as possible.

3. 2026년 6월 11일 AM 12:07 UTCidentified

   We are starting to observe the first initial signs of platform recovery. Our engineering teams are proceeding with extreme caution and are closely monitoring system stability and telemetry as services begin to stabilize. We remain actively engaged in verifying that this early recovery is sustained. We will provide our next update in 30 minutes, or sooner if we detect any changes in performance.

4. 2026년 6월 11일 AM 12:41 UTCidentified

   The core platform has successfully recovered, and all primary services are fully operational. We are currently processing a backlog of queued jobs within Cloudworks resulting from the incident. While this backlog is being processed, some customers may experience delays in processing times. We will continue to track performance and will provide our next update in 30 minutes, or sooner as the backlog clears.

5. 2026년 6월 11일 AM 12:57 UTCmonitoring

   We are pleased to report that the CloudWorks backlog is actively processing, and we are now seeing jobs successfully and steadily completing. System throughput has returned to normal operational levels as the queue continues to clear. Our engineering teams remain focused on monitoring the queue velocity until the backlog is fully exhausted and all services have returned to a completely nominal state. We will provide our next update in 30 minutes, or sooner once queue clearance is complete.

6. 2026년 6월 11일 AM 1:15 UTCmonitoring

   We are currently processing a backlog of queued jobs within Cloudworks for US1 and US2 region. While this backlog is being processed, some customers may experience delays in processing times. We will continue to track performance and will provide our next update in 30 minutes, or sooner as the backlog clears.

7. 2026년 6월 11일 AM 1:52 UTCresolved

   We have confirmed that the issue is now resolved. We deeply apologize for any impact this issue may have caused. We appreciate your patience and partnership as we worked through this issue. We will follow up within 7 business days with a detailed root cause analysis (RCA) that will be shared on our Status Page. If you have any question or concerns, please do not hesitate to contact us at Anaplan Support.

8. 2026년 6월 19일 PM 3:00 UTCpostmortem

   **June 8–12, 2026 Platform Disruptions** On June 8, 2026, at 11:05 UTC, our monitoring detected a brief drop in incoming traffic across the Anaplan platform, with automated monitoring checks failing across all affected regions \(us1: Data Center - US East, us2: Data Center - US West, eu1: Data Center - Netherlands, eu2: Data Center - Germany, eu4: Cloud - Europe, us5: Cloud - US East, us7: Cloud - US, and ap1: Cloud - Japan\). Over the four days, a series of related disruptions affected the same regions. Customers experienced intermittent difficulties logging in, opening models, and running integrations. The platform was fully stabilized on June 11, 2026, at 18:12 UTC. These disruptions are linked to our previously communicated infrastructure modernization program. On the weekend of June 6, we migrated our control plane, the part of the platform that directs how traffic is routed between services. This was the most complex of the planned migration weekends, and it was completed successfully, as had the two previous migration weekends. The issues described in this report emerged in the days following that migration. This report covers the seven linked incidents that occurred between June 8 and June 11, 2026. **Root cause** As part of our infrastructure modernization program, on the weekend of June 6, we completed a successful migration of our control plane. In the days that followed, we observed two discrete network-hardware issues that interacted to drive these disruptions. _Issue 1: Media Access Control \(MAC\) flapping \(June 8–9\)_ Every device on a network has a MAC address, a unique hardware identifier that network switches use to route traffic to the correct destination. In our environment, the MAC addresses involved are virtual — assigned to logical network gateways rather than to fixed physical hardware — which allows them to legitimately move between hosts as part of normal operation. MAC flapping occurs when a switch sees the same MAC address appearing on two different physical ports in rapid succession, forcing it repeatedly to update its routing tables. This briefly slows or interrupts traffic. For customers, this surfaced as a brief, self-recovering instability. Short bursts of load and intermittent errors appeared and cleared on their own within minutes. The trigger for this behavior was the specific way live production traffic interacted with the new post-migration network. To resolve the issue, we scaled capacity, engaged our vendor, and deployed configuration changes to contain the impact. _Issue 2: network card driver defect \(June 10–11\)_ Once the first set of mitigations were in place, we identified a second issue: A defect in the network card driver, which is the software that controls how a network card sends and receives data. The defect affected fewer than 0.005% of the cards in our estate. Those cards failed randomly and unpredictably, dropping traffic while still appearing healthy to our monitoring systems. This is known as a "gray failure" condition, because the affected components don’t flag themselves as broken. The cards sat in the part of the network that routes traffic between the regions impacted. This resulted in failures that cascaded across the platform and drove disruptions on June 10 and June 11. The defect hadn't been observed in previous migrations or in any other environment, and there were no indicators in pre-deployment testing. The gray failure pattern was also what initially masked the defect as a load issue, until further investigation pointed us to the driver itself. We engaged our vendor, who confirmed the defect. Working closely with them, we rapidly prepared, tested, and deployed the patch to the affected hosts on the evening of June 11, UTC. After that, the platform stabilized. **Recovery** From the first occurrence on June 8 through to permanent resolution on June 11, our engineering team led a continuous, round-the-clock response, working closely with our vendor to identify, diagnose, and resolve the underlying defect. We deployed configuration mitigations, repeatedly rerouted traffic between hosts and across alternative network paths, and scaled out capacity to restore service to customers as quickly as possible while the underlying defect was being addressed. The seven linked incidents and their impact windows were: * **June 8, 2026, 11:00–11:20 UTC** — A short network disruption from the initial MAC flapping event caused intermittent login failures and slow page loads. For most customers, this appeared as a brief 6-minute blip and recovered automatically. Some basic authentication users experienced a longer impact and needed to start a new browser session, with full recovery by 11:20 UTC. * **June 9, 2026, 11:05–11:29 UTC** — A recurrence of the same MAC flapping condition caused a similar brief disruption. Again, most customers experienced only a short blip of around 6 minutes, with basic authentication users seeing a longer impact. We applied scaling changes to address the issue. * **June 10, 2026, 11:02–12:40 UTC** — Customers across all affected regions experienced a loss of access to the platform for approximately 98 minutes. We worked with the vendor and applied configuration changes to address the issue. * **June 10–11, 2026, 23:06–00:04 UTC** — A disruption of approximately 58 minutes, caused when the network card defect affected the backup host that traffic had been moved to. We restored connectivity by moving traffic onto an alternative network path. * **June 11, 2026, 03:43–05:20 UTC** — A disruption of approximately 97 minutes, as the next backup host was affected by the same defect. We restored connectivity by moving traffic onto an alternative network path. * **June 11, 2026, 11:10–13:02 UTC** — A further recurrence of the network traffic surge caused customers to experience slow or failed access to the platform. We restored service by applying an underlying configuration change. * **June 11, 2026, 17:04–17:48 UTC** — A final disruption of approximately 44 minutes during which we moved traffic to a host running the updated network card driver. The platform was fully stabilized at 18:12 UTC on June 11, 2026, once traffic was successfully moved to a host running the updated network card driver. We then applied the same update to a second host for resilience. Monitoring continued through to midday Friday before the incident was closed. CloudWorks™ experienced a backlog of queued jobs during and immediately after each disruption. Our engineering team scaled out CloudWorks capacity to accelerate processing, and the backlog was fully cleared shortly after each recovery. **Corrective and preventative actions** The control plane migration that preceded these disruptions was a one-time, foundational piece of work. The actions below reflect the learnings we are carrying forward from the event to further strengthen the platform. 1. The updated network card driver has been rolled out across all hosts matching the affected hardware profile, in every region. This removes the underlying defect from our infrastructure, even though it hasn't been observed in any other region. 2. The conditions that allowed MAC flapping to surface as customer-visible instability have been addressed at multiple layers. Configuration changes have been deployed in the affected regions. The underlying network configuration has been standardized across the wider production estate, and we have tuned the network behavior that triggered the initial event. 3. During the incident, our engineering team deployed dedicated alerting in real time for the specific network conditions causing the disruptions, enabling faster detection and intervention throughout the response. We are continuing to strengthen proactive monitoring and early-warning detection across post-release windows, so that emerging anomalies are surfaced and investigated before they escalate into customer-visible disruptions. 4. The remaining infrastructure update that supports the network card fix is being completed across our other environments. This brings the full benefit of the fix to every part of our infrastructure. **What's next** One final migration weekend is scheduled for June 20, 2026. After this, the migration phase of the infrastructure modernization program is complete. **Closing** We apologize for the impact this issue has had on your operations. We're committed to the improvements outlined above to prevent similar disruptions. If you have questions or concerns, please contact [Support](https://support.anaplan.com/).

1. 2026년 6월 10일 AM 11:11 UTCinvestigating

   We are currently investigating an active incident that may affect Basic Authentication access. If you encounter issues when attempting to access the platform please use the following workaround while we resolve the issue: - Close your current session— Close the active browser tab or open a new Incognito/Private window. - Re-authenticate— Navigate to the portal and log in again with your credentials to establish a fresh session. We are actively monitoring the platform and will continue to do so until the issue is fully resolved. If you are still experiencing difficulties or have any questions, please reach out to Anaplan Support

2. 2026년 6월 10일 AM 11:35 UTCinvestigating

   Since our last update, we have detected a further degradation in general platform performance. Our engineering teams are actively investigating the root cause with the highest priority, and we will provide further updates as the situation develops Currently, we do not yet have a time to resolution. We will continue to provide updates every 30 minutes as we work to resolve this issue as quickly as possible.

3. 2026년 6월 10일 PM 12:01 UTCinvestigating

   Following our previous notification, the ongoing performance issues have escalated, resulting in broader platform-wide degradation. Our senior engineering teams have successfully identified the root cause of the issue and are currently executing targeted remediation steps to restore normal operations as our absolute highest priority. Currently, we do not yet have a time to resolution. We will continue to provide updates every 30 minutes as we work to resolve this issue as quickly as possible.

4. 2026년 6월 10일 PM 12:34 UTCinvestigating

   Our engineering teams continue to actively investigate the incident while simultaneously implementing targeted remediation steps to stabilize the platform. We are closely monitoring the system's response to these actions and will provide our updates every 30 minutes as we work to resolve this issue as quickly as possible.

5. 2026년 6월 10일 PM 12:51 UTCidentified

   The general platform has successfully recovered and is operating normally; however, we are actively addressing a residual issue impacting Cloudworks that is currently preventing integration jobs from completing. Our technical teams remain focused on resolving this remaining component to restore full service across all integrations as quickly as possible. Currently, we do not yet have a time to resolution. We will provide further updates in 30 minutes or upon resolution.

6. 2026년 6월 10일 PM 1:18 UTCidentified

   We are pleased to report that integration jobs are now successfully completing, and our systems are actively processing the accumulated backlog across all regions. To accelerate this recovery, we have scaled out our service capacity, with a particular focus on the us7: Cloud - US region to expedite the clearance of its more significant backlog. We will provide further updates in 30 minutes or upon resolution.

7. 2026년 6월 10일 PM 1:27 UTCidentified

   We are pleased to report that integration processing has returned to normal operational levels across all global regions, with the sole exception of us7: Cloud - US. The us7: Cloud - US region continues to steadily work through its remaining queue utilizing our expanded capacity, and we are monitoring progress closely to ensure a complete return to baseline performance. Currently, we do not yet have a time to resolution. We will provide further updates in 30 minutes or upon resolution.

8. 2026년 6월 10일 PM 1:55 UTCidentified

   As we continue our active recovery efforts, we have identified localized capacity constraints in the us1: Data Center - US East region that may intermittently affect customers attempting to load models. Our engineering teams are addressing this resource bottleneck to restore full service. The CloudWorks backlog in us7: Cloud - US has finished processing, and the service has returned to normal operations. While an estimated time to resolution is not yet established, our teams are treating this with the highest urgency. We will provide our next update in 30 minutes, or sooner if a resolution is reached.

9. 2026년 6월 10일 PM 2:33 UTCinvestigating

   Our investigation indicates that the backend connectivity issues in US1, stemming from a localized network disruption, are specifically isolated to the loading of large models in excess of 200GB. Customers attempting to load smaller models should experience normal performance and remain unaffected as our network engineering teams actively work to restore stable pathways for larger model payloads. Currently, we do not yet have a time to resolution. We will continue to provide updates every 30 minutes as we work to resolve this issue as quickly as possible.

10. 2026년 6월 10일 PM 3:04 UTCidentified

    Our network engineering teams continue to actively implement remediation steps to address the localized network issue in the us1: Data Center - US East region. We remain focused on resolving the backend connectivity disruptions affecting the loading of larger models, while smaller models continue to perform normally. We are closely monitoring system behavior as we deploy these targeted fixes and will provide our next update in 30 minutes, or sooner if significant progress is made. Currently, we do not yet have a time to resolution. We will provide further updates in 30 minutes or upon resolution.

11. 2026년 6월 10일 PM 3:27 UTCmonitoring

    Service has now been restored; you should now be able to resume normal activities. We will continue to monitor the platform to ensure no additional issues arise. If you have any questions, concerns, or continue to experience issues, please do not hesitate to contact Anaplan Support. We will provide a final update to you when we consider this situation fully resolved.

12. 2026년 6월 10일 PM 4:35 UTCresolved

    We have confirmed that the issue is now resolved. We deeply apologize for any impact this issue may have caused. We appreciate your patience and partnership as we worked through this issue. We will follow up within 7 business days with a detailed root cause analysis (RCA) that will be shared on our Status Page. If you have any question or concerns, please do not hesitate to contact us at Anaplan Support.

13. 2026년 6월 19일 PM 2:58 UTCpostmortem

    **June 8–12, 2026 Platform Disruptions** On June 8, 2026, at 11:05 UTC, our monitoring detected a brief drop in incoming traffic across the Anaplan platform, with automated monitoring checks failing across all affected regions \(us1: Data Center - US East, us2: Data Center - US West, eu1: Data Center - Netherlands, eu2: Data Center - Germany, eu4: Cloud - Europe, us5: Cloud - US East, us7: Cloud - US, and ap1: Cloud - Japan\). Over the four days, a series of related disruptions affected the same regions. Customers experienced intermittent difficulties logging in, opening models, and running integrations. The platform was fully stabilized on June 11, 2026, at 18:12 UTC. These disruptions are linked to our previously communicated infrastructure modernization program. On the weekend of June 6, we migrated our control plane, the part of the platform that directs how traffic is routed between services. This was the most complex of the planned migration weekends, and it was completed successfully, as had the two previous migration weekends. The issues described in this report emerged in the days following that migration. This report covers the seven linked incidents that occurred between June 8 and June 11, 2026. **Root cause** As part of our infrastructure modernization program, on the weekend of June 6, we completed a successful migration of our control plane. In the days that followed, we observed two discrete network-hardware issues that interacted to drive these disruptions. _Issue 1: Media Access Control \(MAC\) flapping \(June 8–9\)_ Every device on a network has a MAC address, a unique hardware identifier that network switches use to route traffic to the correct destination. In our environment, the MAC addresses involved are virtual — assigned to logical network gateways rather than to fixed physical hardware — which allows them to legitimately move between hosts as part of normal operation. MAC flapping occurs when a switch sees the same MAC address appearing on two different physical ports in rapid succession, forcing it repeatedly to update its routing tables. This briefly slows or interrupts traffic. For customers, this surfaced as a brief, self-recovering instability. Short bursts of load and intermittent errors appeared and cleared on their own within minutes. The trigger for this behavior was the specific way live production traffic interacted with the new post-migration network. To resolve the issue, we scaled capacity, engaged our vendor, and deployed configuration changes to contain the impact. _Issue 2: network card driver defect \(June 10–11\)_ Once the first set of mitigations were in place, we identified a second issue: A defect in the network card driver, which is the software that controls how a network card sends and receives data. The defect affected fewer than 0.005% of the cards in our estate. Those cards failed randomly and unpredictably, dropping traffic while still appearing healthy to our monitoring systems. This is known as a "gray failure" condition, because the affected components don’t flag themselves as broken. The cards sat in the part of the network that routes traffic between the regions impacted. This resulted in failures that cascaded across the platform and drove disruptions on June 10 and June 11. The defect hadn't been observed in previous migrations or in any other environment, and there were no indicators in pre-deployment testing. The gray failure pattern was also what initially masked the defect as a load issue, until further investigation pointed us to the driver itself. We engaged our vendor, who confirmed the defect. Working closely with them, we rapidly prepared, tested, and deployed the patch to the affected hosts on the evening of June 11, UTC. After that, the platform stabilized. **Recovery** From the first occurrence on June 8 through to permanent resolution on June 11, our engineering team led a continuous, round-the-clock response, working closely with our vendor to identify, diagnose, and resolve the underlying defect. We deployed configuration mitigations, repeatedly rerouted traffic between hosts and across alternative network paths, and scaled out capacity to restore service to customers as quickly as possible while the underlying defect was being addressed. The seven linked incidents and their impact windows were: * **June 8, 2026, 11:00–11:20 UTC** — A short network disruption from the initial MAC flapping event caused intermittent login failures and slow page loads. For most customers, this appeared as a brief 6-minute blip and recovered automatically. Some basic authentication users experienced a longer impact and needed to start a new browser session, with full recovery by 11:20 UTC. * **June 9, 2026, 11:05–11:29 UTC** — A recurrence of the same MAC flapping condition caused a similar brief disruption. Again, most customers experienced only a short blip of around 6 minutes, with basic authentication users seeing a longer impact. We applied scaling changes to address the issue. * **June 10, 2026, 11:02–12:40 UTC** — Customers across all affected regions experienced a loss of access to the platform for approximately 98 minutes. We worked with the vendor and applied configuration changes to address the issue. * **June 10–11, 2026, 23:06–00:04 UTC** — A disruption of approximately 58 minutes, caused when the network card defect affected the backup host that traffic had been moved to. We restored connectivity by moving traffic onto an alternative network path. * **June 11, 2026, 03:43–05:20 UTC** — A disruption of approximately 97 minutes, as the next backup host was affected by the same defect. We restored connectivity by moving traffic onto an alternative network path. * **June 11, 2026, 11:10–13:02 UTC** — A further recurrence of the network traffic surge caused customers to experience slow or failed access to the platform. We restored service by applying an underlying configuration change. * **June 11, 2026, 17:04–17:48 UTC** — A final disruption of approximately 44 minutes during which we moved traffic to a host running the updated network card driver. The platform was fully stabilized at 18:12 UTC on June 11, 2026, once traffic was successfully moved to a host running the updated network card driver. We then applied the same update to a second host for resilience. Monitoring continued through to midday Friday before the incident was closed. CloudWorks™ experienced a backlog of queued jobs during and immediately after each disruption. Our engineering team scaled out CloudWorks capacity to accelerate processing, and the backlog was fully cleared shortly after each recovery. **Corrective and preventative actions** The control plane migration that preceded these disruptions was a one-time, foundational piece of work. The actions below reflect the learnings we are carrying forward from the event to further strengthen the platform. 1. The updated network card driver has been rolled out across all hosts matching the affected hardware profile, in every region. This removes the underlying defect from our infrastructure, even though it hasn't been observed in any other region. 2. The conditions that allowed MAC flapping to surface as customer-visible instability have been addressed at multiple layers. Configuration changes have been deployed in the affected regions. The underlying network configuration has been standardized across the wider production estate, and we have tuned the network behavior that triggered the initial event. 3. During the incident, our engineering team deployed dedicated alerting in real time for the specific network conditions causing the disruptions, enabling faster detection and intervention throughout the response. We are continuing to strengthen proactive monitoring and early-warning detection across post-release windows, so that emerging anomalies are surfaced and investigated before they escalate into customer-visible disruptions. 4. The remaining infrastructure update that supports the network card fix is being completed across our other environments. This brings the full benefit of the fix to every part of our infrastructure. **What's next** One final migration weekend is scheduled for June 20, 2026. After this, the migration phase of the infrastructure modernization program is complete. **Closing** We apologize for the impact this issue has had on your operations. We're committed to the improvements outlined above to prevent similar disruptions. If you have questions or concerns, please contact [Support](https://support.anaplan.com/).

1. 2026년 6월 10일 AM 9:48 UTCinvestigating

   We are currently investigating an issue impacting customers’ ability to run Cloudworks integrations. We are working to resolve this issue as quickly as possible and will provide updates every 30 minutes or upon resolution.

2. 2026년 6월 10일 AM 10:15 UTCmonitoring

   Service has now been restored; you should now be able to resume normal activities. We will continue to monitor the platform to ensure no additional issues arise. If you have any questions, concerns, or continue to experience issues, please do not hesitate to contact Anaplan Support. We will provide a final update to you when we consider this situation fully resolved.

3. 2026년 6월 10일 AM 10:42 UTCresolved

   We have confirmed that the issue is now resolved. We deeply apologize for any impact this issue may have caused. We appreciate your patience and partnership as we worked through this issue. We will follow up within 7 business days with a detailed root cause analysis (RCA) that will be shared on our Status Page. If you have any question or concerns, please do not hesitate to contact us at Anaplan Support.

4. 2026년 6월 19일 PM 3:12 UTCpostmortem

   **Introduction**   On June 10, 2026, at 09:48 UTC, customers in us1: Data Center - US East experienced slight delays in the processing and successful completion of CloudWorks™ integrations.   **Root cause**  During routine database patching on June 10, all regions completed without issue except for the us1: Data Center - US East region, where CloudWorks encountered an unexpected loss of database connectivity. This caused deadlocks within the scheduler service.  Our investigation determined that one remote connection had been dropped while a second remained active, resulting in connection conflicts and errors. The issue was remediated by performing a rolling restart of the scheduler service and clearing the database rules.  **Recovery**  Upon identifying the issue, our engineering team acted quickly to initiate a rolling restart of the scheduler service across the affected region. To fully resolve the connection conflict and errors, the team cleared the internal routing and caching rules associated with the database gateway. Following this action, the database connection errors ceased immediately, and manual validation confirmed that integration scheduling had been fully restored. The issue was completely resolved by 10:42 UTC.  **Corrective and preventative actions**  We are implementing the following actions to prevent recurrence and improve service reliability:  * We are developing enhanced system alerts to immediately detect database connectivity issues and abnormal error volumes.  * We are working to replicate the scenario in non-production environments to strengthen CloudWorks' ability to recover from database disconnections.   * We are currently reviewing the errors encountered, along with the relevant system settings, to determine whether any changes can be implemented to better handle this type of issue in the future.  * We are reviewing and optimizing the capacity and sizing of our integration services across all regions to ensure they are robust and resilient.  * We are establishing more detailed incident response runbooks and centralizing triage procedures to accelerate resolution of similar issues.   * We are strengthening our platform observability and system telemetry to improve our diagnostic capabilities and detect connection issues more rapidly.  We apologize for any impact this issue may have had on your business operations.` `We are continuously strengthening our systems and procedures to ensure we avoid future disruptions to your business and users.  If you have further questions or concerns, please visit our [Support website](https://www.google.com/url?q=https%3A%2F%2Fsupport.anaplan.com%2F). We appreciate your patience during this incident and value the trust you place in Anaplan.

1. 2026년 6월 9일 AM 11:14 UTCinvestigating

   We are currently investigating an active incident that may affect Basic Authentication access. If you encounter errors when attempting to log in please do the following: - Close your current session— Close the active browser tab or open a new Incognito/Private window. - Re-authenticate— Navigate to the portal and log in again with your credentials to establish a fresh session. We are actively monitoring the platform and will continue to do so until the issue is fully resolved. If you are still experiencing difficulties or have any questions, please reach out to Anaplan Support We are working to resolve this issue as quickly as possible and will provide updates every 30 minutes or upon resolution.

2. 2026년 6월 9일 AM 11:28 UTCresolved

   We have confirmed that the issue is now resolved. We deeply apologize for any impact this issue may have caused. We appreciate your patience and partnership as we worked through this issue. We will follow up within 7 business days with a detailed root cause analysis (RCA) that will be shared on our Status Page. If you have any question or concerns, please do not hesitate to contact us at Anaplan Support.

3. 2026년 6월 19일 PM 2:45 UTCpostmortem

   **June 8–12, 2026 Platform Disruptions** On June 8, 2026, at 11:05 UTC, our monitoring detected a brief drop in incoming traffic across the Anaplan platform, with automated monitoring checks failing across all affected regions \(us1: Data Center - US East, us2: Data Center - US West, eu1: Data Center - Netherlands, eu2: Data Center - Germany, eu4: Cloud - Europe, us5: Cloud - US East, us7: Cloud - US, and ap1: Cloud - Japan\). Over the four days, a series of related disruptions affected the same regions. Customers experienced intermittent difficulties logging in, opening models, and running integrations. The platform was fully stabilized on June 11, 2026, at 18:12 UTC. These disruptions are linked to our previously communicated infrastructure modernization program. On the weekend of June 6, we migrated our control plane, the part of the platform that directs how traffic is routed between services. This was the most complex of the planned migration weekends, and it was completed successfully, as had the two previous migration weekends. The issues described in this report emerged in the days following that migration. This report covers the seven linked incidents that occurred between June 8 and June 11, 2026. **Root cause** As part of our infrastructure modernization program, on the weekend of June 6, we completed a successful migration of our control plane. In the days that followed, we observed two discrete network-hardware issues that interacted to drive these disruptions. _Issue 1: Media Access Control \(MAC\) flapping \(June 8–9\)_ Every device on a network has a MAC address, a unique hardware identifier that network switches use to route traffic to the correct destination. In our environment, the MAC addresses involved are virtual — assigned to logical network gateways rather than to fixed physical hardware — which allows them to legitimately move between hosts as part of normal operation. MAC flapping occurs when a switch sees the same MAC address appearing on two different physical ports in rapid succession, forcing it repeatedly to update its routing tables. This briefly slows or interrupts traffic. For customers, this surfaced as a brief, self-recovering instability. Short bursts of load and intermittent errors appeared and cleared on their own within minutes. The trigger for this behavior was the specific way live production traffic interacted with the new post-migration network. To resolve the issue, we scaled capacity, engaged our vendor, and deployed configuration changes to contain the impact. _Issue 2: network card driver defect \(June 10–11\)_ Once the first set of mitigations were in place, we identified a second issue: A defect in the network card driver, which is the software that controls how a network card sends and receives data. The defect affected fewer than 0.005% of the cards in our estate. Those cards failed randomly and unpredictably, dropping traffic while still appearing healthy to our monitoring systems. This is known as a "gray failure" condition, because the affected components don’t flag themselves as broken. The cards sat in the part of the network that routes traffic between the regions impacted. This resulted in failures that cascaded across the platform and drove disruptions on June 10 and June 11. The defect hadn't been observed in previous migrations or in any other environment, and there were no indicators in pre-deployment testing. The gray failure pattern was also what initially masked the defect as a load issue, until further investigation pointed us to the driver itself. We engaged our vendor, who confirmed the defect. Working closely with them, we rapidly prepared, tested, and deployed the patch to the affected hosts on the evening of June 11, UTC. After that, the platform stabilized. **Recovery** From the first occurrence on June 8 through to permanent resolution on June 11, our engineering team led a continuous, round-the-clock response, working closely with our vendor to identify, diagnose, and resolve the underlying defect. We deployed configuration mitigations, repeatedly rerouted traffic between hosts and across alternative network paths, and scaled out capacity to restore service to customers as quickly as possible while the underlying defect was being addressed. The seven linked incidents and their impact windows were: * **June 8, 2026, 11:00–11:20 UTC** — A short network disruption from the initial MAC flapping event caused intermittent login failures and slow page loads. For most customers, this appeared as a brief 6-minute blip and recovered automatically. Some basic authentication users experienced a longer impact and needed to start a new browser session, with full recovery by 11:20 UTC. * **June 9, 2026, 11:05–11:29 UTC** — A recurrence of the same MAC flapping condition caused a similar brief disruption. Again, most customers experienced only a short blip of around 6 minutes, with basic authentication users seeing a longer impact. We applied scaling changes to address the issue. * **June 10, 2026, 11:02–12:40 UTC** — Customers across all affected regions experienced a loss of access to the platform for approximately 98 minutes. We worked with the vendor and applied configuration changes to address the issue. * **June 10–11, 2026, 23:06–00:04 UTC** — A disruption of approximately 58 minutes, caused when the network card defect affected the backup host that traffic had been moved to. We restored connectivity by moving traffic onto an alternative network path. * **June 11, 2026, 03:43–05:20 UTC** — A disruption of approximately 97 minutes, as the next backup host was affected by the same defect. We restored connectivity by moving traffic onto an alternative network path. * **June 11, 2026, 11:10–13:02 UTC** — A further recurrence of the network traffic surge caused customers to experience slow or failed access to the platform. We restored service by applying an underlying configuration change. * **June 11, 2026, 17:04–17:48 UTC** — A final disruption of approximately 44 minutes during which we moved traffic to a host running the updated network card driver. The platform was fully stabilized at 18:12 UTC on June 11, 2026, once traffic was successfully moved to a host running the updated network card driver. We then applied the same update to a second host for resilience. Monitoring continued through to midday Friday before the incident was closed. CloudWorks™ experienced a backlog of queued jobs during and immediately after each disruption. Our engineering team scaled out CloudWorks capacity to accelerate processing, and the backlog was fully cleared shortly after each recovery. **Corrective and preventative actions** The control plane migration that preceded these disruptions was a one-time, foundational piece of work. The actions below reflect the learnings we are carrying forward from the event to further strengthen the platform. 1. The updated network card driver has been rolled out across all hosts matching the affected hardware profile, in every region. This removes the underlying defect from our infrastructure, even though it hasn't been observed in any other region. 2. The conditions that allowed MAC flapping to surface as customer-visible instability have been addressed at multiple layers. Configuration changes have been deployed in the affected regions. The underlying network configuration has been standardized across the wider production estate, and we have tuned the network behavior that triggered the initial event. 3. During the incident, our engineering team deployed dedicated alerting in real time for the specific network conditions causing the disruptions, enabling faster detection and intervention throughout the response. We are continuing to strengthen proactive monitoring and early-warning detection across post-release windows, so that emerging anomalies are surfaced and investigated before they escalate into customer-visible disruptions. 4. The remaining infrastructure update that supports the network card fix is being completed across our other environments. This brings the full benefit of the fix to every part of our infrastructure. **What's next** One final migration weekend is scheduled for June 20, 2026. After this, the migration phase of the infrastructure modernization program is complete. **Closing** We apologize for the impact this issue has had on your operations. We're committed to the improvements outlined above to prevent similar disruptions. If you have questions or concerns, please contact [Support](https://support.anaplan.com/).

1. 2026년 6월 8일 PM 1:25 UTCinvestigating

   We are currently investigating an issue impacting customers’ ability to run Cloudworks integrations. We are working to resolve this issue as quickly as possible and will provide updates every 30 minutes or upon resolution.

2. 2026년 6월 8일 PM 1:52 UTCinvestigating

   Thank you for your patience as we continue to investigate this issue. Currently, we do not yet have a time to full resolution.  Access to the UI has been restored and we are currently investigating the degradation to integrations. We will continue to provide updates every 30 minutes as we work to resolve this issue as quickly as possible.

3. 2026년 6월 8일 PM 3:18 UTCinvestigating

   We are currently investigating an issue impacting impacting Cloudworks. We are working to resolve this issue as quickly as possible and will provide updates every 30 minutes or upon resolution.

4. 2026년 6월 8일 PM 3:31 UTCmonitoring

   Service has now been restored; you should now be able to resume normal activities. We will continue to monitor the platform to ensure no additional issues arise. If you have any questions, concerns, or continue to experience issues, please do not hesitate to contact Anaplan Support. We will provide a final update to you when we consider this situation fully resolved.

5. 2026년 6월 8일 PM 3:51 UTCresolved

   We have confirmed that the issue is now resolved. We deeply apologize for any impact this issue may have caused. We appreciate your patience and partnership as we worked through this issue. We will follow up within 7 business days with a detailed root cause analysis (RCA) that will be shared on our Status Page. If you have any question or concerns, please do not hesitate to contact us at Anaplan Support.

6. 2026년 6월 17일 PM 5:08 UTCpostmortem

   **Introduction**  On June 8, 2026, at 13:14 UTC, customers in our ap1: Cloud - Japan, eu1: Data Center - Netherlands, eu2: Data Center - Germany, us2: Data Center - US West, us5: Cloud - US East, us7: Cloud - US, and eu4: Cloud - Europe regions experienced delays and difficulties accessing the CloudWorks™ user interface. During this period, users experienced slow UI access and a temporary inability to create new integrations or run certain scheduled jobs. Existing workflows were unaffected, although some experienced minor delays in completion.  **Root cause**  The root cause of this incident was an incorrect configuration setting where certain backend components did not automatically pick up updated hostname configurations following a scheduled system migration. Consequently, these components continued to attempt connections using the outdated configuration, leading to connection failures. This prevented users from accessing the user interface and successfully initiating new integration runs. The issue was resolved by reloading the updated configuration on the affected services.  **Recovery**  Our engineering team identified the issue and took immediate action. We initiated a rolling restart of the job management service across the affected regions, which restored user interface access. To fully resolve the connection errors, the engineering team performed a comprehensive restart of all related service components in every affected region, forcing them to load the updated database configurations. Following these restarts, database connection errors immediately ceased, and manual validation confirmed that both user-interface access and integration scheduling were fully restored and functioning normally. By 15:52 UTC, the issue was fully resolved.  **Corrective and preventative actions**  We are implementing the following actions to prevent recurrence and improve service reliability:  * We are developing enhanced system alerts to immediately detect database connectivity issues and abnormal error volumes.  * We are reviewing and optimizing the capacity and sizing of our integration services across all regions to ensure they are robust and resilient.  * We are establishing more detailed incident response runbooks and centralizing triage procedures to accelerate resolution of similar configuration mismatches.  * We are strengthening our platform observability and system telemetry to improve our diagnostic capabilities and detect connection issues more rapidly.  * We are refining our strategy and APIs to proactively detect and manage delayed integration workflows.   We apologize for any impact this issue may have had on your business operations. We are continuously strengthening our systems and procedures to ensure we avoid future disruptions to your business and users.  If you have further questions or concerns, please visit our [Support website](https://www.google.com/url?q=https%3A%2F%2Fsupport.anaplan.com%2F). We appreciate your patience during this incident and value the trust you place in Anaplan.