Mixpanel 장애 기록

1. 2026년 10월 21일 오후 6:04 UTCmonitoring

   We’ve received reports that requests to decide.mixpanel.com are failing. Any traffic sent through decide.mixpanel.com may be affected, including feature flags and event tracking. To restore service now, point requests to api.mixpanel.com (US), api-eu.mixpanel.com (EU), or api-in.mixpanel.com (IN) depending on your project's Data Residency. We’re rolling out a mitigation and monitoring the results. We will post progress updates on our status page. If you have any questions, please contact support.

2. 2026년 10월 21일 오후 8:15 UTCresolved

   This incident has been resolved.

1. 2026년 10월 21일 오후 10:28 UTCmonitoring

   우리는 결정하는 요청이 된 보고서를 받았습니다.mixpanel.com은 실패합니다. crystal.mixpanel.com을 통해 전송된 모든 트래픽은 기능 플래그 및 이벤트 추적을 포함하여 영향을 미칠 수 있습니다. 이제 서비스를 복원하려면 api.mixpanel.com (미국), api-eu.mixpanel.com (EU) 또는 api-in.mixpanel.com (IN)로 요청하십시오. 프로젝트의 데이터 레거시에 따라. 우리는 완화를 압연하고 결과를 모니터링하고 있습니다. 교통이 복원되었습니다. 우리는 우리의 상태 페이지에 진행 상황을 게시합니다. 궁금한 점이 있으시면 연락 주시기 바랍니다.

2. 2026년 10월 22일 오전 1:34 UTCresolved

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

3. 2026년 10월 24일 오전 1:58 UTCpostmortem

   #**Mixpanel RCA: 신청** [**decide.mixpanel.com**](http://decide.mixpanel.com) **10월 15–21, 2026** ###**일반** 에서 10월 15, 2026 에 10월 21, 2026, 요청은 `decide.mixpanel.com` 과 `api-decide.mixpanel.com` 실패. 이벤트 추적, 프로필 업데이트, 또는 이 호스트 이름에 플래그 요청을 전송 하는이 영향을 받는 고객은 일반적으로 프록시를 통해. 이 창에서이 도메인에 전송 된 이벤트는 Mixpanel에 의해 수신되지 않았고이 데이터는 Mixpanel에 의해 복원 될 수 없습니다. **‘api.mixpanel.com’**,** `api-js.mixpanel.com,`api-eu.mixpanel.com'**,** `api-in.mixpanel.com'**에 보내진 경우 ** 이 hostname에 대한 서비스는 unintentionally 충격을 받았고, `/decide` endpoint 인프라를 제거했습니다. hostnames는 시스템 의존성에 대한 잘못된 이해 때문에 endpoint의 일부로 처리되었습니다. 이 문제를 방지하기 위해, 우리는 `decide.mixpanel.com`과 `api-decide.mixpanel.com` hostnames에 대한 트래픽 모니터링을 추가하고 있습니다. 우리는 또한 어떤 hostname가 제거되기 전에 hostname 수준에 0 트래픽을 확인해야합니다. ** 'decide.mixpanel.com'에 복원 된 서비스 이후 있습니다. ###**What 일어난 일에 태어난** 이전 Mixpanel SDK는 `/decide` endpoint to fetch configuration for [**Legacy Automatically Tracked Mobile Events**](https://docs.mixpanel.com/docs/tracking-methods/sdks/ios#legacy-automatically-tracked-events)를 호출합니다. 우리는 [endpoint의 은퇴 발표](https://docs.mixpanel.com/changelogs#2026-01-26), 그리고 몇 시간 동안 `/decide`는 `410` 응답을 반환했습니다. 별도, `decide.mixpanel.com`과 `api-decide.mixpanel.com`는 표준 API hostname에 대한 별칭 역할을 합니다. 예를 들어, `decide.mixpanel.com/track`는 같은 방식으로 `api-js.mixpanel.com/track`가 동작합니다. 일부 고객은 프록시 또는 SDK 구성을 설정하여 해당 호스트 이름에 트래픽을 보냅니다. 10월 15일 오후 7시 40분 CDT에서 `/decide` endpoint의 최종 정리 중에 `decide.mixpanel.com`과 `api-decide.mixpanel.com`의 DNS 레코드를 제거하고 로드밸런서에서 호스트명을 모두 제거했습니다. 변경하기 전에 `/decide` endpoint가 0으로 떨어졌다는 것을 확인했습니다. 그러나, 우리의 감시는 hostname에 의해 오히려 endpoint에 의하여 측정된 교통을 측정했습니다. 즉, `/track`와 `/flags`와 같은 다른 요청이 여전히 Mixpanel에 도달하지 않았다. 다음에서, 이 hostname에 모든 요청은 `/track`, `/engage`, `/groups`, 그리고 `/flags`와 같은 엔드포인트를 포함하지 못했습니다. * ** 이벤트 및 프로필:** 이벤트, 프로필, 그리고 [Ingestion API endpoints](https://docs.mixpanel.com/reference/ingestion-api)에 대한 모든 데이터는 Mixpanel에 도달하지 않았으므로 복원 할 사본이 없습니다. 프록시 로그 또는 데이터 창고와 같은이 데이터를 다른 곳에서 유지하면 Ingestion API의 [/import](https://docs.mixpanel.com/reference/import-events), [/engage,](https://docs.mixpanel.com/reference/profile-set) 및 [/groups](https://docs.mixpanel.com/reference/group-propertyer)에 다시 보내실 수 있습니다. * ** 특징 플래그:** 이 hostnames가 실패한 기능 플래그 요청. SDK는 존재한 경우 마지막 저장된 변형을 제공하거나 코드에 설정된 fallback 값. ## 타임라인 \(중앙 시각, 10월 2026\) * ** 10 월 15, 7 : 40 PM CDT : ** hostname 제거가 적용됩니다. `decide.mixpanel.com`과 `api-decide.mixpanel.com`에 요청하면 실패합니다. * ** 10 월 16, 5 : 22 AM CDT : ** 우리는 첫번째 고객 보고를 받습니다. 계획된 `/decide` 은퇴와 관련된 것이 처음 이해됩니다. * **10월 21, 11:42 오전 CDT:** 프록시에 대한 추적에 대한 고객의 증가에 따라, 우리는 원인으로 hostname 제거를 확인합니다. ***10월 21, 12:26 오후 CDT:** 우리는 hostnames를 복원합니다. `/decide`는 은퇴합니다. * **10월 21, 1:51 오후 CDT:** 우리는 복원 된 hostnames에 트래픽을 확인합니다. * **10월 21, 8:34 오후 CDT:** 사건은 해결됩니다. ###**Root 원인** 1. `/decide` 은퇴 도중, `decide.mixpanel.com`와 `api-decide.mixpanel.com`는 unintentionally 제거되었습니다. 2. 이 호스트명은 모든 API 트래픽을 수용하기 위해 구성되었다, 뿐만 아니라 `/decide` 요청, 이 행동은 문서화되지 않았다. 3. 우리의 모니터링은 `/decide` endpoint에 트래픽을 추적하지만, 이러한 hostnames에, 그래서 사전 변경 체크는 다른 트래픽이 여전히 활성화되었는지 표시하지 않았다. 4. 호스트 이름과 은퇴한 엔드포인트가 이름을 공유하기 때문에, 초기 고객 보고서는 발표 된 `/decide` 은퇴의 예상 효과로 초기 해석되었습니다. 이 지연된 에스컬레이션. ###** 우리가 변화하는 것** * **Monitoring 및 경고:** `decide.mixpanel.com`과 `api-decide.mixpanel.com`에 대한 트래픽 및 오류 평가 모니터링 및 알림을 추가하고 있으므로 고객의 보고서를 통해 자동으로 감지됩니다. * **호스팅:** 우리는 유사한 문서화되지 않은 항목에 대한 모든 공개 API 호스트 이름과 라우팅 별명을 감사하고, 우리는 그들이 살고 가기 전에 새로운 호스트 이름과 별명을 검토 할 것입니다. 예기치 않은 호스트 이름에 도착하는 트래픽도 추적하고 있습니다. * **안전 제거:** 대중적인 hostname에 어떤 미래 변화든지의 앞에, 우리는 hostname 수준에 0개의 소통량을 확인하고, 우리는 그것을 사용하여 어떤 프로젝트든지 아직도 연락할 것입니다. * **고객 통신:** 우리는 우리의 changelog에 타임 라인에 게시를 포함하여 공공 호스트 이름에 영향을 미치는 재료 인프라 변경의 고객 사전 통지를 줄 것입니다. ** 이미 배포:** * 복원 `decide.mixpanel.com`와 `api-decide.mixpanel.com` * `/decide`는 퇴직 ####**일반 질문** * ** 내 데이터가 영향을 받습니까? ** SDK 또는 프록시가 10월 15일부터 10월 21일까지 `decide.mixpanel.com` 또는 `api-decide.mixpanel.com`에 요청을 보내면 됩니다. 해당 창이 수신되지 않았고 Mixpanel에 의해 복원 할 수 없습니다. 그 데이터의 복사본을 유지한 경우, 이벤트에 대한 `/import`와 같은 Ingestion API 엔드포인트를 사용하여 Mixpanel에 다시 보내실 수 있습니다. * ** 아무것도 변경해야합니까?** 아니요, 도메인은 다시 작동합니다. API 도메인으로 `api.mixpanel.com`\(또는 `api-eu.mixpanel.com`/`api-in.mixpanel.com`를 사용하여 추천합니다. * ** '/decide`가 다시 오나요? 이름 * 그것은 발표로 은퇴 남아, 그리고 그것은 'decide.mixpanel.com' 호스트 이름에서 분리. 우리는 혼란에 대해 죄송합니다. 프로젝트에 대한 질문이 있으시면 계정 팀 또는 Mixpanel 지원으로 문의하십시오.

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

1. 2026년 10월 8일 오후 4:32 UTCinvestigating

   우리는 현재 미국 프로젝트에 등록 된 프로젝트를위한 실시간 데이터에 영향을 미치는 데이터 섭취 파이프라인의 지연을 경험하고 있으며 프로젝트의 하위 세트에 대한 지연을 유발합니다. 데이터가 손실되지 않는 동안, 우리의 엔지니어링 팀은 적극적으로 가능한 한 빨리 실시간 기능을 복원하기 위해 문제 및 작업에 투자하고 있습니다. 우리는 이 시간에 당신의 인내를 평가합니다. 궁금한 점이 있으시면 연락 주시기 바랍니다.

2. 2026년 10월 8일 오후 5:32 UTCidentified

   문제는 식별되고 수정이 구현됩니다.

3. 2026년 10월 8일 오후 6:31 UTCidentified

   우리는 우리의 클라우드 스토리지 제공 업체, 구글 클라우드, 미국 프로젝트의 하위 세트에 영향을 미치는 ingestion 지연의 원인을 확인했습니다. Google은 끝에서 높은 선량 문제로 이것을 확인했지만 ETA를 아직 제공하지 않았습니다. 우리는 매끄럽게 복구를 보장하기 위해 완화를 배포했습니다. 이벤트가 손실되지 않습니다. 이것은 엄격히 섭취 지연, 모든 영향을받는 데이터는 문제가 해결되면 다시 처리됩니다.

4. 2026년 10월 8일 오후 7:30 UTCmonitoring

   우리의 미터 쇼 ingestion는 붙잡고 더 긴 경험 지연 없음. Google은 아직 그들의 끝에 하향 상류 문제의 해결을 확인하지 않았습니다. 그래서 우리는 반복의 경우 밀접하게 모니터링 할 수 있습니다.

5. 2026년 10월 8일 오후 9:30 UTCmonitoring

   우리의 마지막 갱신부터 변화 없음, 우리는 우리의 끝에 활동적인 소화 지연을 관찰하지 않으며, 모든 체계는 건강하게 남아 있습니다. 우리는 밀접하게 감시하는 것을 계속합니다.

6. 2026년 10월 8일 오후 10:30 UTCmonitoring

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

7. 2026년 10월 8일 오후 11:30 UTCmonitoring

   시스템은 ingestion 지연의 recurrence로 안정적으로 유지되었습니다. 우리는 우리가 우리의 상류 공급자에게서 마지막 확인을 기다리는 동안 일에 가까운 눈을 유지하고 있습니다.

8. 2026년 10월 9일 오전 12:22 UTCresolved

   이 사건은 해결되었습니다. 클라우드 스토리지 제공 업체와 업스트림 문제는 고정되었으며, 우리의 섭취 파이프라인은 일반적으로 활성 지연없이 작동되었습니다. 이 사건을 잃지 않았습니다. 모든 영향을받는 데이터는 완전히 재처리되었습니다. 이 사건을 통해 당신의 인내를 감사하십시오.

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

1. 2026년 8월 26일 오후 9:39 UTCinvestigating

   Mixpanel는 미국 데이터 레지스트리와 프로젝트를 위한 보고서를 조회할 때 HTTP 500 응답에서 유래하는 degraded Query API 성과를 경험하고 있습니다. 유럽 연합 (EU)과 IN 데이터 레지스트리 (In Data Residency)의 프로젝트는 비공식적으로 남아 있습니다. 우리는 우리의 엔지니어가 정상적인 기능을 복원하는 동안 당신의 인내력을 평가합니다. 우리는 우리의 상태 페이지에 진행 상황을 게시합니다. 궁금한 점이 있으시면 연락 주시기 바랍니다.

2. 2026년 8월 26일 오후 10:11 UTCidentified

   문제는 식별되고 수정이 구현됩니다.

3. 2026년 8월 26일 오후 10:28 UTCmonitoring

   수정이 구현되었습니다. Query API의 성공률이 향상되었습니다. 우리는 안정성을 보장하기 위해 계속 감시할 것입니다.

4. 2026년 8월 26일 오후 10:45 UTCresolved

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

5. 2026년 9월 8일 오후 6:25 UTCpostmortem

   # Mixpanel RCA : 미국 프로젝트의 임시 쿼리 서비스 중단 8 월 26, 2026 # 요약 사이 대략 **2:02 오후와 3:19 오후 PT 에 8월 26, 2026**, 미국 지역의 프로젝트는 Mixpanel UI 및 Query API를 통해 보고서 및 실행 쿼리를로드. 이 창 중 일부 쿼리는 실패하거나 오류를 반환. ** 고객 데이터가 손실되지 않았고 데이터 섭취는 영향을받지 않았습니다. ** 모든 이벤트는 일반적으로 사건에 걸쳐 수집되고 저장됩니다. 한 번 쿼리 서비스는 복원되었습니다. 모든 보고서는 전체를 반영하여 고객 행동이 필요하지 않습니다. 원인은 진단 쿼리 재생을위한 최근 배치 된 내부 도구로 식별되었으며, 과거 쿼리의 재 실행 사본을 사용하여 성능 디버그를 디버그 할 수 있습니다. 예기치 않게 우리의 쿼리 서버의 디스크에 데이터의 큰 양을 썼고 저장 용량을 운영해야합니다. 그 디스크가 채워지면, 영향을받는 서버가 서비스에서 나왔습니다. 서비스 복원 된, 영향 서버는 온라인을 다시 가져왔다, 내부 도구가 비활성화되었습니다. 아래 구제는 내부 툴링의 기능을 제거하기 위해 저장 안전장치를 추가하고 쿼리 서버에 리소스를 소비하는 기능을 제거하고 앞으로 다시 일어나기에서 실패의이 종류를 방지하도록 설계되었습니다. # 무슨 일이 있었는지 Mixpanel의 쿼리 엔진은 로컬 스토리지 볼륨 세트를 사용하여 쿼리에 신속하게 응답 할 필요가 데이터를 캐시합니다. 분리, 우리의 엔지니어 사용 진단 쿼리 재생 도구, 기능 우리의 엔지니어 사용 재현 및 디버그 쿼리 성능. 큰 복잡한 쿼리에 대한 진단 쿼리 재생 툴링을 적용하는 동안, 소프트웨어 버그는 쿼리 재생 캡처가 나머지 단일 서버에 confined 대신 전체 함대에서 팬을 발생. 또한 단일 서버에서 적시 퇴치 없이 저장될 예정보다 훨씬 더 많은 데이터가 발생했습니다. 두 가지 요소는 문제가 발생했습니다. * 단 하나 가득 차있는 저장 양은 서버가 서비스에서 완전히 했습니다. 각 서버는 다른 모든 볼륨이 건강할 때 사용 임계값을 가로질러 저장 볼륨 중 하나가 사용 임계값을 가로질러 건강하지 않는 경우 캐시를 치료합니다. 재생 데이터는 각 서버에 한 특정 볼륨으로 작성되었으므로 지역 전역의 서버는 거의 동시에 건강 검사를 실패했습니다. * Cleanup 제한은 데이터 크기를 고려하지 않았습니다. 파일시스템 수준에서 바이트가 아닌 애플리케이션 레벨에서 디스크 카운트된 항목에 데이터를 제한하는 Safeguard는 작은 숫자의 예기치 않게 큰 캡처가 볼륨의 용량의 대부분을 소모하면서 체크를 통과했습니다. 함께, 이들은 일반적으로 미국 전역의 생산 쿼리를 중단 할 수있는 negligible 발자국을 가지고 단일 디버깅 워크플로우를 허용. # 타임라인 \ (태평양 시간, 8 월 26, 2026 \) * **2:00 PM** — 첫번째 대형 진단 재생 붙잡음은 썼습니다; 저장 양은 수용량을 도달하기 위하여 시작되고 조회 성공 비율은 후에 곧 떨어지기 시작합니다. * **2:17 PM** — 자동 경고는 on-call 엔지니어; 조사는 즉시 시작되고 추가 엔지니어는 관여되었습니다. * **2:39 PM** - 상태 페이지 사건 게시; 오후 2시 40분에 표시된 앱 배너. * **2:53 PM** — 루트 원인 확인; 복구 노력은 첫 번째 영향 서버 그룹에 시작. * **3:19 PM** - 트래픽의 광대한 대부분을 위해 복원 된 쿼리 서비스; 최종 서버 그룹은 오후 3시 27분에 완전히 회복되었습니다. * **3:45 PM** — 안정된 관측 기간 후에 해결된 이유. 이 문제를 트리거 한 진단 재생 도구는 완전히 같은 저녁을 사용하지 않았습니다. # 뿌리 원인 1. ** 우리의 쿼리 재생 도구에 소프트웨어 버그는 생산 저장에 unbounded 쓰기 발생.** 이 웹 사이트는 애플 리케이션에 전념. 우리는 정품 앱과 게임을 제공 할 목적으로이 사이트를 만들었습니다. 4AppsApk 최고의 안드로이드 애플 리케이션을위한 무료 APK 파일 다운로드 서비스, 계략. 2. **Replay 파일은 서빙에 의존하는 디스크 용량을 소비. ** 재생 툴링은 쿼리 서버의 로컬 디스크에 파일을 썼습니다. 따라서 runaway replay data 소진된 저장 용량은 서버가 쿼리에 응답해야 합니다. 3. **Safeguards는 부분적으로 행동을 고려합니다. ** 진단 재생 데이터를 위한 정리 정책은 디스크에 항목의 수를 제한했지만 총 크기가 아니라 참여하지 않았습니다. 스토리지 볼륨에 저장하는 것은 성장을 끌어 당기고 있지만 쿼리 오류가 시작될 때까지 탐지를 지연하는 per-server 기초에 중요한 것으로 간주되지 않았습니다. # 우리가 변화하는 것 끝 국가 우리는 건물을 향해 입니다: 내부 진단 조회 재생 자료는 전용 물체 저장에서 저장해, 생산 쿼리 서버에 짐 없음. Already 배포 : * **내부 툴링**를 비활성화한 경우, 아래 문제점을 재개하여 진단 캡처는 단일 서버로 confined되며 특정 쿼리 클래스는 올바르게 처리됩니다. * ** 대상 복구 절차 ** 사건 중 사용, 즉, 전체 서버 그룹을 재시작하는 것보다 영향을받은 저장 볼륨 만 삭제, 우리의 운영 런북에서, 어떤 볼륨의 용량이 미래에 실행되는 경우 복구 시간을 단축. 진행 중: * **Filesystem-level, 진단 재생 데이터의 크기 기반 제한 **, 항목 개수보다 디스크에 전체 바이트를 캡핑, 그래서 크기 캡처는 볼륨의 용량에 영향을 미칠 수 전에 거부 또는 evicted. * ** 엄격한 저장 alerting**, 쿼리 건강 검사에 영향을 미칠 수 있기 전에 중요 한 per-server 볼륨 포화. ***Moving query replay data to dedicated object storage,** 그래서 생산 쿼리 서버에 리소스를 사용하지 않습니다. # 자주 묻는 질문 * ** 손실된 데이터는? ** No. Data ingestion은 사건을 통해 비난되었다: 이벤트는 수집, 누락되고, 일반적으로 저장됩니다. 쿼리 할 수있는 능력은 중단되었습니다. 일단 서비스는 복원되었습니다, 모든 보고서는 전체 데이터를 반영. * **저장된 보고서, 대시보드 또는 프로젝트 설정이 영향을 받습니까?** 이름 * 사건은 쿼리 실행에만 영향을 미칩니다. 프로젝트가 변경되지 않았습니다. * ** 한 번에 여러 미국 프로젝트에 영향을 줬습니까? ** 거의 동일한 시간에 각 쿼리 서버의 디스크에 기록 된 대형 진단 재생 데이터, 각 서버는 하나의 볼륨 채우면 서비스에서 자체를 제거합니다. consuming query-server 저장에서 내부 장식을 방지하는 것은 우리의 구제 일의 핵심 부분입니다. * **이 방지 된 방법은? ** 도구 문제 해결 및 도구는 크기 기반 제한이 장소에있을 때까지 비활성화 남아. 저장 경고는 이렇게 포화가 붙기 때문에 붙잡음은 그것이 질문 서빙에 영향을하기 전에 붙잡습니다. 구조상으로, 우리는 생산 쿼리 서버에서 진단 데이터를 전적으로 이동하고, 그래서 내부 디버깅 데이터는 쿼리 처리에 책임있는 서버에 저장을 사용하지 않습니다. 우리는 혼란에 대해 사과하고 시간 보고서를 사용할 수 없습니다. 귀하의 계정 팀이나 질문에 대한 지원에 도달하십시오.

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

1. 2026년 8월 19일 오후 11:20 UTCidentified

   우리는 현재 dropdown 메뉴에서 팝업 이벤트 속성과 문제가 있습니다. 우리는 우리의 엔지니어가 기능을 복원하는 동안 당신의 인내력을 평가합니다. 질문이 있으시면 [email protected]으로 문의하십시오

2. 2026년 8월 20일 오전 1:04 UTCidentified

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

3. 2026년 8월 20일 오전 2:52 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

4. 2026년 8월 20일 오전 3:05 UTCresolved

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

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

1. 2026년 8월 6일 오전 7:19 UTCinvestigating

   We are aware that the Get-Report tool in the Mixpanel MCP server is currently failing when called with skip_results: false. Report metadata is unaffected. We are investigating the issue and will provide updates as we have them.

2. 2026년 8월 6일 오전 8:39 UTCidentified

   The issue has been identified and fix is being implemented.

3. 2026년 8월 6일 오전 9:12 UTCmonitoring

   A fix has been deployed and we're now monitoring the results. Report queries in the Mixpanel MCP server should be functioning normally. We'll continue to watch closely and provide a final update once we've confirmed full resolution.

4. 2026년 8월 6일 오후 1:32 UTCresolved

   This incident has been resolved.

1. 2026년 7월 22일 오전 8:03 UTCinvestigating

   현재 웹앱 내에서 Mixpanel 에이전트와 문제가 있습니다. 엔지니어링 팀은 경고를 받고 문제점을 조사하고 기능을 복원하기 위해 노력하고 있습니다. 우리는 이 문제를 해결하기 위해 노력으로 당신의 인내를 평가합니다. 궁금한 점이 있으시면 연락 주시기 바랍니다.

2. 2026년 7월 22일 오전 9:52 UTCinvestigating

   팀은 문제점과 다음 단계를 조사하는 것을 계속합니다. 당신의 patience를 위한 감사합니다.

3. 2026년 7월 22일 오전 10:55 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

4. 2026년 7월 22일 오후 2:47 UTCresolved

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

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

1. 2026년 7월 11일 오전 7:53 UTCinvestigating

   우리는 현재 미국 프로젝트에 등록 된 프로젝트를위한 실시간 데이터에 영향을 미치는 데이터 섭취 파이프라인의 지연을 경험하고 있으며 프로젝트의 하위 세트에 대한 지연을 유발합니다. 데이터가 손실되지 않는 동안, 우리의 엔지니어링 팀은 적극적으로 가능한 한 빨리 실시간 기능을 복원하기 위해 문제 및 작업에 투자하고 있습니다. 우리는 이 시간에 당신의 인내를 평가합니다. 궁금한 점이 있으시면 연락 주시기 바랍니다.

2. 2026년 7월 11일 오전 9:17 UTCinvestigating

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

3. 2026년 7월 11일 오전 10:15 UTCidentified

   문제는 식별되고 수정이 구현됩니다.

4. 2026년 7월 11일 오후 12:54 UTCidentified

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

5. 2026년 7월 11일 오후 2:25 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

6. 2026년 7월 11일 오후 3:54 UTCresolved

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

7. 2026년 7월 16일 오후 11:47 UTCpostmortem

   # 요약 7월 10일 오후 7시 35분부터 7월 11일 오전 7시 19분까지, 2026**, 미국 지역의 Mixpanel 프로젝트에 대한 데이터 섭취는 최대 ~2시간에 달합니다. 이 창 도중, 보고 및 대쉬보드는 일시적으로 불완전한 자료 — 최근 시간 범위는 능동적 사용자 또는 수익과 같은 미터에 있는 예리한, 인공적인 하락으로 나타날 수 있었습니다. **자료가 분실되지 않았습니다. ** 모든 이벤트는 두드러지게 되었고, 한 번의 백로그가 명확하게 처리되었습니다. 메트릭스는 고객의 행동이 필요하지 않습니다. 우리의 소화 통제에서 시작된 원인: 아주 높은 볼륨 프로젝트의 작은 수를 위해, 우리가 허용한 섭취 비율은 그 프로젝트를 위해 규정된 수용량과 일치의 밖으로 강제했습니다. 큰 역사적인 수입 - 플랫폼의 전적으로 합법적 인 사용 - 따라서 인프라가 흡수 될 수보다 빨리 인정하고, 우리의 파이프라인의 두 가지 속성은 지역 전체 지연으로 현지화되었다. 아래 수정은 그 제어를 정렬하므로 어떤 크기로 가져가 안전 경계 내에서 자동으로 유지됩니다. # 무슨 일이 있었는지 Mixpanel의 주입 파이프라인은 sharded와 다 강렬합니다: 각 프로젝트의 자료는 그것의 예상한 양을 위해 치수를 재는 분할의 세트의 맞은편에 배부되고, 많은 고객에게서 사건은 배치에서 함께 가공됩니다. 이 디자인은 고능률을 전달합니다, 그러나 그것은 1개의 invariant에 달려 있습니다: 우리가 프로젝트의 소통량이 그것을 위해 규정된 수용량과 일치해야 하는 비율. Invariant가 보유 할 때 매우 큰 수입이 부드럽게 흡수됩니다. 여기, 그것은 붙지 않았다. 작은 숫자의 매우 큰 역사적인 데이터 가져 오기 ran에 허용 ingestion 비율을 가지고, 시간이 지남에 따라, 자신의 제공 파티션 용량보다 잘 성장. 초과 볼륨은 특정 파티션에 집중 ** 핫 스폿 **, 스트리밍 함대의 일부를 포화. 두 가지 요소는 영향을 미칩니다. ***Batched, 멀티텐트 가공은 핫 스팟을 증폭.** 많은 고객의 이벤트가 일괄 처리, 느린 및 실패에 함께 여행하기 때문에 과부하 된 파티션은 해당 배치를 공유하는 관련 고객의 이벤트를 지연. * ** 자동 스케일 업 효과.** 추가 용량은 이 종류의 핫 스폿을 용해 할 수 없습니다. 과부하 된 파티션은 동일한 인프라에 핀으로 유지되기 때문에 스트리밍 인프라의 구성 요소의 용량 한계가 추가 된 용량을 복용하는 효과가 있습니다. 함께, 이들은 수동 개입을 필요로하는 다 시간 지연으로 간단한, 자기 치유의 slowdown을 갖는 것을 돌았습니다. # 타임라인 \ (태평양 시간, 7 월 10-11 \) * **11:35 PM** — 자동화된 경고는 ingestion backlog를 검출했습니다; On-call 엔지니어는 즉시 관여시켰습니다. * **12:49 AM** - 상태 페이지 사건 게시; 미국 지역에 영향을 미치는 영향. * ** 1:23 오전 ** — 가장 큰 기여 수입은 일시적이었습니다. * **1:55–6:48 AM** — 프로그레시브 마이그레이션: 추가 트래픽 소스 throttled, 특정 backl 로그 데이터는 고객의 계약으로 방어, 실패는 파이프라인에서 활성화, 및 영향 인프라 노드 대체. * **7:19 AM** — Backlog 완전 처리; 모든 프로젝트의 현재. 상태 페이지는 모니터링으로 이동, 다음 안정적인 관측 기간 후 해결. # 뿌리 원인 1. **급료로 구분된 용량은 제한됩니다.** 운전 프로젝트의 경우, 우리의 플랫폼이 인정 된 비율은 인프라가 제공 한 단계로 성장했습니다. 따라서 합법적 인 높은 볼륨 수입은 파티션보다 더 빨리 흡수 할 수있었습니다. 이것은 체계적인 뿌리 원인입니다. 수입은 플랫폼의 합법적 인 사용이었다. 2. ** 배치 된 멀티 텐트 처리는 과부하를 증폭. ** 과부하된 분할에 실패는 동일한 처리 배치를 공유하는 관련 고객의 사건을 연기했습니다, 플랫폼의 맞은편에 현지화한 문제를 퍼. 3. ** 과부하된 파티션에주의를 기울일 수 없습니다. ** 스트리밍 레이어의 파티션 서버 할당은 로드 인식되지 않았다, 그래서 뜨거운 반점은 함대 크기에 관계없이 동일한 서버에 핀을 유지 - 총 용량 충분했다, 하지만 곰에 가져 갈 수 없습니다. 우리의 스트리밍 인프라의 구성 요소에 대한 스케일 업을 방지하여이 화합물의 한계는 엔지니어가 수동으로 분해 될 때까지 진단을 지연. # 우리가 변화하는 것 우리는 건물을 향해 있습니다 : ** 모든 프로젝트의 섭취 제한은 자동으로 제공 용량에 일치하므로 전체 역사적인 백필 및 데이터 창고 동기화를 포함한 모든 크기의 수입이 사전 조정없이 실행 할 수 있으며 하나의 프로젝트의 볼륨은 다른 데이터 신선도에 영향을 미칩니다. **. Already 배포 - 우리의 섭취 취급 개선 : * ** 핫스팟 취급 개선.** 스트리밍 레이어의 트래픽 배포는 이제 로드 인식, 집중된 부하를 분산, 함대에 걸쳐 균등하게, 그리고 개별 문제 항목은 이제 자신의 일괄 처리의 나머지를 유지 대신 제한 - 감소, 하지만 제거하지 않는, 지역화 된 하중에 영향을 미칠 수 관련 트래픽. * **높은 볼륨 워크로드를 제공 ** 적절한 크기의 인프라에, 위험에 의해 우선. Already deployed — 우리가 타사 스트리밍 서비스를 운영하는 방법을 변경: * ** 함대의 용량 프로파일을 재조정하고 재조정 ** 그래서 개별 서버는 집중된 부하에 대한 실질적으로 더 헤드룸이 있으며, 사건 중 발생하는 스케일링 제한을 해결하기 위해 공급자와 협력했습니다. 진행 중: ***Capacity-aware rate limiting** — 프로젝트 속도 제한과 각 프로젝트의 실제 프로비저닝 용량 사이의 격차를 닫고 이전에 부족한 구급차 경로에 제한하는 확장률을 확장하고, 재커링에서 이 클래스를 방지하기 위해 설계된 용량 증가에 대한 향후 제한 증가를 연결하십시오. * **Finer-grained volume monitoring and alerting** 그래서 용량의 misalignment는 어떤 고객에 영향을 미칠 수 있기 전에 감지 및 수정됩니다. * 대량/백필 교통 경로에 대 한 더 강한 작업 부하 고립/백 로그 복구 우선화, 그래서 역사적인 수입은 살아있는 교통에 영향을 감소 # 자주 묻는 질문 * ** 손실된 데이터는? ** No. 이벤트는 사건을 통해 크게 빚어 졌고, backlog가 명확하게 처리되었습니다. 창문에서 볼 수있는 모든 미터 방울은 지연과 자정의 디스플레이 artifact이었다. * ** Mixpanel과 큰 수입 또는 백필을 조정해야 합니까?** 없음 — 우리의 목표는 안전한 비율 안에 어떤 수입품든지 자동적으로 지키는 플랫폼, 그래서 backfills 및 창고 syncs는 스케줄링 또는 고시 없이 달릴 수 있습니다. 우리는 여전히이를 제공하는 용량 인식 제어를 압연하고 있습니다. 반면에, 비정상적으로 큰 수입 또는 백필을 계획하는 경우, 우리는 당신의 계정 팀과 공동으로 조정을 권장합니다 그래서 우리는 사전에 용량을 확인 할 수 있습니다. * **이 방지 된 방법은? ** 시스템 수정은 개별적으로 부여 된 프로젝트 속도 제한과 각 프로젝트의 실제 프로비저닝 용량 사이의 격차를 강화하고 이전에 부족한 섭취 경로에 제한 된 비율을 확장합니다. 이 종류의 과부하가 입학에 중지됩니다. 또한, 사건을 머리말을 붙인 스케일링 제한은, 파이프라인은 지금 개인 문제 품목을 따로따로 반송합니다 그래서 지방화된 하중 초과는 관련 트래픽에 더 적은 충격이 있고, 대량 교통은 살아있는 교통에서 더 고립됩니다. * **개인 프로젝트는 복구 중 우선 순위가 될 수 있습니까? ** 이 기능은 사건 중 존재하지 않았습니다. — 모든 프로젝트는 동일한 속도로 회복했습니다. 우리는 우리의 후속 작업의 일부로 백로 복구를위한 우선 순위 메커니즘을 평가하고 있습니다. 우리는 붕괴를 위해 사과하고 일시적으로 depressed 메트릭에 대한 우려. 귀하의 계정 팀이나 질문에 대한 지원에 도달하십시오.

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

1. 2026년 6월 29일 오후 7:47 UTCinvestigating

   Mixpanel은 향상된 대기시간을 포함하여 Query API와 향상된 성능을 경험하고 있습니다. 느린 로드 보고서 또는 쿼리 오류를 볼 수 있습니다. 우리는 우리의 엔지니어가 정상적인 기능을 복원하는 동안 당신의 인내력을 평가합니다. 우리는 우리의 상태 페이지에 진행 상황을 게시합니다. 궁금한 점이 있으시면 연락 주시기 바랍니다.

2. 2026년 6월 29일 오후 9:04 UTCidentified

   문제는 식별되고 수정이 구현됩니다.

3. 2026년 6월 29일 오후 10:42 UTCidentified

   Query latency는 안정적으로 유지되었지만, 우리 팀은 고급 성능의 밑단 원인을 조사하기 위해 계속되었습니다. 우리는 우리의 조사 진도로 업데이트를 계속합니다. 감사합니다.

4. 2026년 6월 30일 오전 2:15 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

5. 2026년 6월 30일 오전 3:30 UTCresolved

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

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

1. 2026년 6월 3일 오후 8:05 UTCinvestigating

   Mixpanel is currently experiencing a disruption in the ability to invite and delete internal users within organizations. We appreciate your patience while our engineers work to restore this functionality. If you have any questions, please contact [email protected]

2. 2026년 6월 3일 오후 8:17 UTCidentified

   The issue has been identified and a fix is being implemented.

3. 2026년 6월 3일 오후 9:27 UTCresolved

   This incident has been resolved.

1. 2026년 6월 2일 오전 11:02 UTCinvestigating

   We are experiencing delays with our data ingestion and shuffling pipeline to projects with all projects. No data is being lost but as a result, real-time data is delayed. We appreciate your patience while our engineers work to restore real-time functionality. If you have any questions, please contact support

2. 2026년 6월 2일 오후 12:31 UTCidentified

   The issue has been identified and a fix is being implemented.

3. 2026년 6월 2일 오후 2:31 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

4. 2026년 6월 2일 오후 4:53 UTCresolved

   This incident has been resolved.

1. 2026년 6월 1일 오후 2:15 UTCinvestigating

   We are experiencing delays with our data ingestion and shuffling pipeline to projects with US & India data residency. No data is being lost but as a result, real-time data is delayed. We appreciate your patience while our engineers work to restore real-time functionality. If you have any questions, please contact support

2. 2026년 6월 1일 오후 3:08 UTCinvestigating

   We have now identified an ingestion delay for EU projects, and are continuing to investigate the issue. Thank you for your patience.

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

   The issue has been identified, and a fix is being implemented.

4. 2026년 6월 1일 오후 4:38 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

5. 2026년 6월 1일 오후 7:42 UTCresolved

   This incident has been resolved.

1. 2026년 5월 19일 오후 7:03 UTCinvestigating

   A subset of users are currently facing issues accessing boards that they previously had access to view. Our Engineering team is actively investigating and will update shortly.

2. 2026년 5월 19일 오후 7:10 UTCidentified

   The issues has been identified and a fix is being implemented. As a workaround boards can be explicitly shared with users who are having issues viewing them currently.

3. 2026년 5월 19일 오후 8:23 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

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

   This incident has been resolved.

1. 2026년 5월 14일 오후 11:17 UTCinvestigating

   We are experiencing degraded performance with our Query API, including increased latency. You may see slow-loading reports, incomplete query results, query errors, or data discrepancies. We appreciate your patience while our engineers work to restore normal functionality. We will post progress updates on our status page. If you have any questions, please contact support.

2. 2026년 5월 14일 오후 11:48 UTCidentified

   The issue has been identified and a fix is being implemented.

3. 2026년 5월 15일 오전 10:19 UTCidentified

   We are continuing to work on a fix for this issue.

4. 2026년 5월 15일 오후 12:28 UTCidentified

   We've continued to make progress on the issue affecting some US projects. Query success rates have returned to normal levels, and the related processing delays have also recovered. A subset of affected projects may still see incomplete data in query results while our recovery process runs. We're actively working on this and will share another update in 2 hours. Impact remains limited to our US region. We do not currently believe any data has been permanently lost.

5. 2026년 5월 15일 오후 2:31 UTCidentified

   Recovery is progressing well. Query success rates remain at normal levels, and missing data has now been restored for a portion of affected projects. We're continuing the recovery process for the remaining affected projects and currently estimate full recovery within approximately 3–5 hours. Some customers may still see incomplete data in query results until this work is complete.

6. 2026년 5월 15일 오후 4:37 UTCidentified

   We are continuing to work on resolving this issue. Our current estimate for full recovery is approximately 3–5 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.

7. 2026년 5월 15일 오후 6:47 UTCidentified

   Recovery is continuing to progress and query latency has returned to normal levels. Our current estimate for full recovery is approximately 3–4 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.

8. 2026년 5월 15일 오후 7:56 UTCidentified

   We are investigating an increase in query latency that appears to be unrelated to the ongoing recovery. You may experience slower-loading reports. Our team is actively looking into the cause and we will provide an update shortly. Recovery is continuing to progress. Our current estimate for full recovery is approximately 3–4 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.

9. 2026년 5월 15일 오후 9:23 UTCidentified

   Query latency has returned to normal levels. We are continuing to monitor.

10. 2026년 5월 15일 오후 10:14 UTCidentified

    Query latency has returned to normal levels and has been resolved. Recovery is continuing to progress, and our current estimate for full recovery is approximately 4–5 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.

11. 2026년 5월 16일 오전 12:17 UTCidentified

    Recovery is continuing to progress. Our current estimate for full recovery is approximately 1-2 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.

12. 2026년 5월 16일 오전 1:52 UTCmonitoring

    A fix has been implemented and we are monitoring the results.

13. 2026년 5월 16일 오전 2:50 UTCresolved

    This incident has been resolved.

14. 2026년 5월 21일 오후 9:43 UTCpostmortem

    # Mixpanel RCA: Transient Data Access Issue, May 14, 2026 ## Summary On Thursday, May 14, 2026 at approximately 2:30 PM PT, a routine but infrequent cleanup operation in Mixpanel's storage system mistakenly removed a portion of production data files in addition to the unused files it was intended to remove. Some customers experienced query errors during the hours that followed. We detected the issue within minutes, deployed mitigations the same evening that returned query success rates and latency to normal, and restored the affected files from backup by 5:15 PM PT on Friday, May 15. Mixpanel's ingestion pipeline was not affected and no event data was lost in transit. ## What happened This incident was triggered by a storage cleanup procedure that runs periodically to remove files no longer referenced by Mixpanel's metadata. The procedure was more involved than usual: it followed a recent enhancement to our file storage strategy that left a set of unused files behind in our storage backend, and addressing them required extending our standard cleanup approach to cover a new code path. As part of executing this extended cleanup, an engineer generated the list of files to delete using a SQL query whose date filter was not strictly earlier than the reference snapshot it was being compared against. As a result, a small set of legitimate production files that had been written in the gap window between the snapshot and the filter date were incorrectly classified as unused and removed. The deletion ran for roughly half an hour before internal alerting caught the resulting query failures and the operation was stopped. The trigger was operator error against an ambiguous runbook, not a defect in the live serving path or in our ingestion pipeline. ## Customer impact Impact unfolded in two phases. The first phase ran from Thursday at approximately 2:30 PM PT until 8:11 PM PT — roughly five and a half hours. During this window, customers across the platform may have seen slower or failed queries when their requests touched files that had been deleted. The breadth and severity varied by project depending on which data each query touched. By 8:11 PM PT, mitigations had fully rolled out — queries automatically retried against an alternate availability zone, and a fallback path was put in place to serve missing files from a backup datastore. After this point, query success rate and latency returned to normal. The second phase lasted from 8:11 PM PT Thursday through approximately 5:15 PM PT Friday, May 15. During this window, fewer than 2% of customers were still affected — specifically, those whose deleted files had not yet been fully restored from backup. The vast majority of these files were recovered by Friday afternoon. A small number of projects \(under 30\) had files that could not be fully recovered from backup, and we are following up with those accounts directly. ## Timeline \(Pacific Time\) * May 14, 2:30 PM — Cleanup operation begins * May 14, 3:11 PM — Internal alerting flags query failures; the cleanup operation is stopped within minutes * May 14, 4:07 PM — Status page banner posted * May 14, 4:45 PM — Mitigation deployed: queries automatically retry against an alternate availability zone * May 14, 7:12 PM — Mitigation deployed: queries fall back to a backup datastore for missing files * May 14, 8:11 PM — Query success rate and latency fully restored to normal levels * May 15, 5:15 PM — File restore from backup complete; status page banner resolved ## Why this happened Several contributing factors lined up. The runbook for this cleanup procedure had ambiguous wording around the ordering and timing of its inputs. It had been recently authored to handle the new file-storage code path and had not gone through a formal review before being used. Our cleanup tooling did not programmatically enforce the safety invariant that the date filter must be strictly before the reference snapshot. That invariant lived only in operator-authored SQL. The extended cleanup was being executed in parallel across two storage layers by two different engineers, which increased the room for error. ## What we're doing to prevent recurrence We have already made or have actively in flight the following changes. We are adding programmatic safeguards to our cleanup tooling so that an input set whose date filter is not safely before the reference snapshot is rejected before any deletion occurs, along with a reconciliation step that flags any production-referenced file before deletion proceeds. Destructive cleanup operations will now run in phased stages, starting with internal projects and pausing for a holding period before any broader execution. Destructive storage operations now require a second engineer to sign off on the exact deletion set and to be present during execution, matching the practice we already follow for database migrations. We have updated the cleanup runbook with explicit guidance on input timing, required safety buffers, and an enforced review process for any runbook covering a destructive operation. Longer term, we are working to eliminate the manual portion of this cleanup procedure entirely and route it through our existing automated cleanup infrastructure, so the class of failure that produced this incident is no longer reachable through human input. ## Closing Reliability and data integrity are foundational to the trust our customers place in Mixpanel, and we recognize the impact this incident had on the teams who rely on us. We are sorry for the disruption. If you have questions about how this incident may have affected a specific project, please reach out to your account team or Mixpanel Support.

1. 2026년 5월 13일 오후 4:34 UTCidentified

   Data Volume Monitoring is again experiencing degraded performance due to a recurring upstream provider disruption. We're mitigating now.

2. 2026년 5월 13일 오후 9:40 UTCidentified

   We are continuing to work on a fix for this issue.

3. 2026년 5월 14일 오후 1:35 UTCresolved

   This incident has been resolved.

1. 2026년 5월 12일 오후 5:45 UTCinvestigating

   We are currently investigating an issue that leads to degraded performance of Data Volume Monitoring in a subset of US-based projects. We truly appreciate your patience and apologize for the inconvenience. If you have any questions, please contact support (https://mixpanel.com/get-support).

2. 2026년 5월 12일 오후 5:46 UTCidentified

   An upstream service provider outage is causing this issue. We are deploying a fix to mitigate the disruption.

3. 2026년 5월 12일 오후 8:24 UTCmonitoring

   A fix has been implemented, and we are monitoring the result.

4. 2026년 5월 12일 오후 9:44 UTCresolved

   This incident has been resolved.

1. 2026년 5월 6일 오전 12:00 UTCinvestigating

   A subset of projects are experiencing issues exporting data to the Snowflake warehouse via Mixpanel pipelines. We are currently investigating this issue.

2. 2026년 5월 6일 오전 9:32 UTCidentified

   We have identified the issue affecting Snowflake pipeline exports for a subset of projects, and our engineering team is working on a resolution.

3. 2026년 5월 6일 오후 8:04 UTCresolved

   This incident has been resolved.

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

   We are currently experiencing an interruption with our credit card processing. Our engineers have identified the issue and are working on a fix.

2. 2026년 4월 9일 오후 9:00 UTCmonitoring

   A fix has been deployed, and all impacted accounts have had their billing re-run. If you continue to receive errors, please ensure the card on file is up to date. If you are still experiencing issues, please submit a support ticket.

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

   This incident has been resolved.

1. 2026년 3월 16일 오후 4:50 UTCidentified

   Mixpanel is experiencing increased query latency for projects with EU residency, which may result in HTTP 500 responses when querying or saving reports. Projects with US and IN residency remain unaffected. Our engineering team is working on a resolution.

2. 2026년 3월 16일 오후 7:29 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

3. 2026년 3월 16일 오후 9:47 UTCresolved

   This incident has been resolved.

1. 2026년 3월 2일 오후 9:00 UTCinvestigating

   We are currently experiencing issues with loading Mixpanel.com and are working to restore service as quickly as possible. Our team is investigating the issue and will provide updates as soon as we have more information. Thank you for your patience.

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

   The issue has been identified and a fix is being implemented.

3. 2026년 3월 2일 오후 9:09 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

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

   This incident has been resolved. If Mixpanel is still not loading, please clear your cache and cookies.