Mixpanel 中断历史

1. 2026年10月21日 UTC 18:04monitoring

   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日 UTC 20:15resolved

   This incident has been resolved.

1. 2026年10月21日 UTC 22:28monitoring

   有报道称,要求决定. mixpanel.com失败了. 任何通过second.mixpanel.com发送的流量可能会受到影响,包括地物旗和事件跟踪. 现在要恢复服务,请将请求点到 api.mixpanel.com (US), api-eu.mixpanel.com (EU), 或 api-in.mixpanel.com (IN), 取决于您的项目的数据滞留度. 我们已经推出一个缓解方案,并正在监测结果。 我们看到交通恢复了 我们将在我们的状况页面上公布最新进展。 如果您有任何问题,请联系支援.

2. 2026年10月22日 UTC 01:34resolved

   这一事件已经得到解决.

3. 2026年10月24日 UTC 01:58postmortem

   # ** Mixpanel RCA: request to ** [** decide.mixpanel.com**] (http://decide.mixpanel.com)** 失败,2026年10月15-21日** ** 概要** 从2026年10月15日至2026年10月21日,向`decide.mixpanel.com'和`api-decide.mixpanel.com'提出的请求失败。 这影响了客户通常通过代理向这个主机名发送事件跟踪,配置更新,或功能旗请求. 在此窗口中发送到此域的事件没有被Mixpanel收到,而且此数据无法被Mixpanel还原. ** 发往** api.mixpanel.com`**;** api-js.mixpanel.com;'api-eu.mixpanel.com`**;** api-in.mixpanel.com;** 我们没有受到影响。 ** 在我们拆除`/决定 ' 终点基础设施时,关于这个主机名称的服务无意中受到影响。 由于对系统依赖性的理解不正确,主机名被视作端点的一部分. 为了防止这类问题,我们正在增加 " dedecide.mixpanel.com " 和 " api-decide.mixpanel.com " 东道主名的交通监测。 我们还要求在删除任何主机名之前,在主机名级别上确认流量为零。 ** 我们已恢复在** decide.mixpanel.com的服务。 发生了什么事? 年长的Mixpanel SDKs称取取出配置的`/决定'终点[**Legacy自动跟踪移动事件**](https://docs.mixpanel.com/docs/tracking-methods/sdks/ios#legacy-automatically-tracted-events)。 我们[宣布终点退休](https://docs.mixpanel.com/changelogs#2026-01-26),一段时间以来,`/decide ' 回复了`410 ' 答复。 另外,`decide.mixpanel.com'和`api-decide.mixpanel.com'作为我们标准API主机名的别名。 例如,`decide.mixpanel.com/track'摄入的事件与`api-js.mixpanel.com/track'一样。 一些客户设置了代理或SDK配置,将流量发送到这些主机名. 10月15日7时40分,在最后清理`/决定'终点时,我们删除了`decide.mixpanel.com'和`api-decide.mixpanel.com'的DNS记录,并删除了两个主机名。 在作出修改之前,我们确认 " 决定 " 终点的交通量已降至零。 然而,我们的监测是根据终端而不是主机名衡量流量的。 因此,它没有表明其他请求,例如`/track'和`/lags',仍然通过这些主机名到达Mixpanel。 从那时起,对这个主机名的所有请求都失败了,包括 " /跟踪 " 、 " /参与 " 、 " /团体 " 和 " /旗 " 等终点。 * ** 事件和简介:** 事件、简介和任何数据,目的是[摄取API端点](https://docs.mixpanel.com/reference/inintition-api)在这个窗口期间提供给这些主机名,从未到达Mixpanel,所以我们没有副本要恢复. 如果您将这些数据保留在其它地方,例如代理日志或数据仓库中,可以将其重新发送到Introduction API的[/import](https://docs.mixpanel.com/reference/import-events),[/engage,](https://docs.mixpanel.com/reference/proference-set-set)和[/group](https://docs.mixpanel.com/reference/group-set-proferty). *** 花旗:** 发送到这些主机名的特性旗请求失败 。 SDKs为最后一个存储的变体服务,如果一个变体存在,或者在您代码中配置的倒置值. QQ 时间线\ (中央时间, 2026年10月\) * 10月15日 7:40 PM CDT:** 应用了主机名去除. `decide.mixpanel.com'和`api-decide.mixpanel.com'的要求开始失败。 * 10月16日,5时22分 我们收到第一份客户报告 它最初被理解为与计划的 " 决定 " 退休有关。 * 10月21日,11时42分 在客户关于追踪代理失败的报告增加后,我们确定删除主机名是原因. * 10月21日,12:26 PM CDT:** 我们恢复主机名。 `决定 ' 仍予退休。 * 10月21日,下午1:51 我们确认恢复主机名的交通恢复了 * 10月21日,8:34 PM CDT:** 此事已决. ** 循环原因** 1. 在 " /决定 " 退休期间, " decide.mixpanel.com " 和 " api-decide.mixpanel.com " 被无意地删除。 2. 这些主机名的配置是为了接受所有API流量,而不仅仅是 " /决定 " 请求,而这种行为是没有记录的。 3. 我们的监测跟踪到 " /决定 " 终点的流量,但没有跟踪到这些主机名的流量,因此,更改前的检查没有显示其他流量仍然活跃。 4. 由于主机名和已退休终点共用一个名称,早期的客户报告最初被解释为宣布的 " /决定 " 退休的预期影响。 这种拖延升级。 我们的改变 * ** 监测和警报:** 我们正在为`dedecide.mixpanel.com'和`api-decide.mixpanel.com'增加流量和误差率监测和警报,因此不通过客户报告自动发现故障。 * ** 名审计:** 我们正在审核所有公共API主机名以及类似无证入站点的路由别名,我们将在新主机名和别名上线前审查. 我们还在追踪任何意外的客流 * ** 清除量:** 在将来更改为公共主机名之前,我们将确认主机名级别的流量为零,我们将确定并联系任何仍在使用它的项目. * ** 客户通信:** 我们将事先通知客户影响公共主机名称的材料基础设施变化,包括在我们的更改日志中公布这些变化的时间表。 ** 已部署:** * 恢复`decide.mixpanel.com'和`api-decide.mixpanel.com' * " /决定 " 已退休 ** 共同问题** 我的数据受到影响了吗? 只有你的SDK或代理在10月15日至10月21日期间向`decide.mixpanel.com'或`api-decide.mixpanel.com'发出请求时,才能这样做。 该窗口期间发送的数据没有收到,无法被Mixpanel恢复. 如果您保留了该数据的复制件,可以使用我们的摄入API端点,如“/导入”事件,将其重新发送到Mixpanel。 *我需要改变什么吗* 不,域又起作用了。 我们建议使用`api.mixpanel.com'\(或`api-eu.mixpanel.com'/`api-in.mixpanel.com')作为欧盟和印度的数据居住权。 * ** `/决定 ' 是否回来了? 没有 它仍然如所宣布的那样退休,与`decide.mixpanel.com'主机名分开。 我们对此感到抱歉。 如果您对您的项目有疑问, 请联系您的账户团队或 Mixpanel 支持 .

自动翻译自官方事件更新。

1. 2026年10月8日 UTC 16:32investigating

   目前我们的数据摄取管道出现延误,这影响到在美国项目注册的项目的实时数据,导致一系列项目的延迟。 虽然没有数据丢失,但我们的工程组正在积极调查此事并努力尽快恢复实时功能。 我们感谢你在这期间的耐心。 如果您有任何问题,请联系支援.

2. 2026年10月8日 UTC 17:32identified

   这一问题已经确定,一个解决办法正在实施之中.

3. 2026年10月8日 UTC 18:31identified

   我们已经确定摄入延迟的原因 是一个上游问题 我们的云存储供应商,谷歌云, 影响子集 美国的项目。 Google证实这在他们的结尾是一个高度优先的问题,但尚未提供ETA. 我们已部署缓解措施,以确保一旦清空就能够顺利恢复。 没有失去任何事件。 这完全是摄入延迟,一旦问题得到解决,所有受影响的数据将继续被重新处理.

4. 2026年10月8日 UTC 19:30monitoring

   我们的衡量标准显示摄入量已经赶上,不再出现拖延。 Google尚未确认如何解决上游问题.

5. 2026年10月8日 UTC 21:30monitoring

   自我们上次更新以来,没有发生任何变化,我们继续观察到我们最后没有出现主动摄入延迟,所有系统都保持健康。 我们继续密切监测.

6. 2026年10月8日 UTC 22:30monitoring

   我们正在继续监测任何其他问题.

7. 2026年10月8日 UTC 23:30monitoring

   系统保持稳定,没有再发生摄入延迟。 我们正密切关注事情.

8. 2026年10月9日 UTC 00:22resolved

   这一事件已经得到解决。 我国云存储供应商的上游问题已经解决,我国摄入管正常运行,没有主动拖延. 在整个事件中没有丢失任何事件,所有受影响的数据都经过了全面的再处理。 谢谢你在这起事件中的耐心.

自动翻译自官方事件更新。

1. 2026年8月26日 UTC 21:39investigating

   Mixpanel正在经历退化的查询API性能,导致HTTP 500在使用美国数据存储查询项目报告时得到回复. 与欧盟和IN数据居住有关的项目没有受到影响。 我们赞赏你的耐心,同时我们的工程师们努力恢复正常的功能. 我们将在我们的状况页面上公布最新进展。 如果您有任何问题,请联系支援.

2. 2026年8月26日 UTC 22:11identified

   这一问题已经确定,一个解决办法正在实施之中.

3. 2026年8月26日 UTC 22:28monitoring

   已实施修复,我们看到"查询API"成功率提高. 我们将继续进行监测,以确保稳定.

4. 2026年8月26日 UTC 22:45resolved

   这一事件已经得到解决.

5. 2026年9月8日 UTC 18:25postmortem

   # Mixpanel RCA:美国项目临时查询服务中断 2026年8月26日 总结 2026年8月26日大约2:02 PM至3:19 PM PT**之间,美国地区的项目通过Mixpanel UI和Query API发生装入报告失败并运行查询. 在此窗口中, 区域内的一些查询失败或返回出错 。 ** 没有丢失客户数据,也没有影响数据摄入。 ** 在整个事件中,继续正常收集和储存所有事件;一旦恢复查询服务,所有报告都反映完整、准确的数据,无需客户采取行动。 这个原因被确定为最近部署的诊断查询回放的内部工具,这是我们工程师用来重新运行过去查询的副本去调试性能的能力,它出乎意料地将大量数据写入我们的查询服务器的磁盘,消耗了服务器运行所需的存储能力. 当这些磁盘被填满时,受影响的服务器自己就退出了服务. 服务被恢复,被影响的服务器被带回网上,内部工具被禁用. 以下的补救增加了存储保障来去除内部工具化在查询服务器上消耗资源的能力,并旨在防止这一类故障在未来再次发生. 发生了什么事 Mixpanel的查询引擎运行在一组服务器上,每个服务器都使用一组本地存储卷来缓存快速回答查询所需的数据. 另外,我们的工程师使用诊断查询重放工具,这是我们工程师用来复制和调试查询性能的能力. 在将诊断性查询回放工具应用到一个大而复杂的查询中的同时,一个软件bug使得查询回放捕捉器在整个机队中扇出而不再局限于一个单一的服务器. 此外,它产生的数据远远多于在不及时驱离单一服务器的情况下保存的预期。 有两个因素扩大了问题的影响: * 一个完整的存储量使一个服务器完全失去服务。 每个服务器如果存储量超过使用阈值,即使其他所有存储量都健康,其存储量仍被视为不健康。 重播数据被写到每个服务器上一个特定的音量,因此整个区域的服务器几乎同时未能实现健康检查. * 清理限额不包括数据大小。 限制磁盘上重放数据的保障措施在应用级别上计数项目,而不是在文件系统级别上计数字节,因此少量出乎意料地大抓取在消耗了音量的大部分容量的同时通过了检查. 这使得一个单一的调试工作流程能够中断整个美国地区的生产查询。 # 时间线\ (太平洋时间, 2026年8月26日\) ***2:00 PM** — 第一次超大小的诊断回放捕获被写入;存储量开始达到其容量,查询成功率在不久后开始下降. * **2:17 PM** — 自动警报呼呼待命工程师;立即开始调查,并雇用了更多的工程师。 * **2:39 PM** — 状况页面事件贴出;应用中标于2:40 PM. * **2:53 PM**——查明了根源;第一个受影响服务器组开始了恢复工作。 ***3:19 PM** — 绝大多数流量恢复了查询服务;最终服务器组在下午3:27完全恢复. * **3:45 PM**——事件在稳定观察后得到解决。 引发了这个问题的诊断回放工具在同晚被完全禁用. {\fn方正粗倩简体\fs12\an8\1cHFFFF00\b0}根本原因 1. ** 我们的查询回放工具中的软件错误导致未绑定的书写到生产存储处。 ** 最近部署的复制查询的能力使特定类别的复杂查询处理不当,导致捕获量扩散到区域内的每个查询服务器,并将数据写入受影响的卷中远多于所假设的设计. 2. ** 重播已消耗的磁盘容量,查询服务取决于。 ** 重放工具将其文件写入了查询服务器的本地磁盘,因此跑出回放数据耗尽了服务器回答查询所需的存储能力. 3. ** 安全卫士只是部分地说明了这种行为。 ** 诊断回放数据的清理政策限制了磁盘上的项目数量,但并不限制其总尺寸,因此没有参与. 关于存储量的警告标志着增长,但并未升级为每服务器的临界值,这推迟了检测,直到查询失败开始。 # 我们正在改变 我们正在构建的最终状态: 内部诊断查询重放存储在专用对象存储中的数据, 不给生产查询服务器加载。 已经部署: * ** 造成事故的内部工具** 并补救了根本问题,因此诊断捕捉被限制在一个单一的服务器上,具体查询类被正确处理. * ** 记录了事件期间使用的目标明确的恢复程序**,即在我们的运行记录中,只清理受影响的储存量,而不是重新启动完整的服务器组,如果今后任何容量耗尽,则缩短恢复时间。 进行中: * ** 基于Filesystem级别、大小的诊断重放数据限制**,将总字节数限制在磁盘上,而不是项目计数上,因此超大小的捕获在影响体积容量之前被拒绝或驱逐。 * **Striter存储提醒**,在影响查询健康检查之前,每服务器体积饱和度不断升级。 * ** 将查询数据重放到专用对象存储中,** 因此它不会消耗生产查询服务器上的资源. # 常见问题 * 是否有任何数据丢失? ** 号. 数据摄入在整个事件中没有受到影响:事件继续被收集,排队并正常存储. 只有查询能力被中断. 一旦恢复服务,所有报告都反映了完整的数据。 * ** 已保存报告、仪表板或项目设置受到影响? ** 没有 该事件仅影响查询执行. 存储在您的项目中,没有什么变化。 * 为什么它同时影响多个美国项目? ** 过度大小的诊断重放数据几乎在同一时间写给每个查询服务器的磁盘,当任何一卷被填充时,每个服务器都会自动退出服务. 防止内部工具消耗查询服务器储存是我们补救工作的核心部分。 * 如何防止这种情况继续下去? ** 工具问题得到解决,在大小限制确定之前,工具仍然无法使用。 存储提醒正在收紧,所以饱和度在它影响查询服务之前被捕获. 结构上,我们正在将诊断数据完全移出生产查询服务器,因此内部调试数据不会消耗负责查询处理的服务器上的存储. 我们对中断和没有时间报告表示歉意。 请通过你的账户团队 或支持任何问题.

自动翻译自官方事件更新。

1. 2026年8月19日 UTC 23:20identified

   目前,我们在下放菜单中正遇到大量事件属性的问题。 我们赞赏你的耐心 因为我们的工程师在努力恢复功能 如有任何问题,请联系@mixpanel.com

2. 2026年8月20日 UTC 01:04identified

   我们正在继续努力解决这个问题。

3. 2026年8月20日 UTC 02:52monitoring

   一项措施已经执行,我们正在监测结果.

4. 2026年8月20日 UTC 03:05resolved

   这一事件已经得到解决.

自动翻译自官方事件更新。

1. 2026年8月6日 UTC 07:19investigating

   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日 UTC 08:39identified

   The issue has been identified and fix is being implemented.

3. 2026年8月6日 UTC 09:12monitoring

   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日 UTC 13:32resolved

   This incident has been resolved.

1. 2026年7月22日 UTC 08:03investigating

   我们正与Mixpanel代理商在网络应用中遇到问题。 我们的工程小组已接到警报,正在调查这一问题并努力恢复其功能。 我们赞赏你耐心地努力解决这一问题。 如果您有任何问题,请联系支援.

2. 2026年7月22日 UTC 09:52investigating

   小组继续调查这一问题和下一步工作。 谢谢你的耐心.

3. 2026年7月22日 UTC 10:55monitoring

   一项措施已经执行,我们正在监测结果.

4. 2026年7月22日 UTC 14:47resolved

   这一事件已经得到解决.

自动翻译自官方事件更新。

1. 2026年7月11日 UTC 07:53investigating

   目前我们的数据摄取管道出现延误,这影响到在美国项目注册的项目的实时数据,导致一系列项目的延迟。 虽然没有数据丢失,但我们的工程组正在积极调查此事并努力尽快恢复实时功能。 我们感谢你在这期间的耐心。 如果您有任何问题,请联系支援.

2. 2026年7月11日 UTC 09:17investigating

   我们正在继续调查这一问题.

3. 2026年7月11日 UTC 10:15identified

   这一问题已经确定,一个解决办法正在实施之中.

4. 2026年7月11日 UTC 12:54identified

   我们正在继续努力解决这个问题。

5. 2026年7月11日 UTC 14:25monitoring

   一项措施已经执行,我们正在监测结果.

6. 2026年7月11日 UTC 15:54resolved

   这一事件已经得到解决.

7. 2026年7月16日 UTC 23:47postmortem

   总结 大约从7月10日的**11:35 PM PT到2026年7月11日的7:19 AM PT**,美国地区的Mixpanel项目的数据摄入量落后了长达~2小时. 在这一窗口中,报告和仪表板暂时显示数据不完整——最近的时间范围可能显示为活跃用户或收入等计量值的急剧、人为下降。 ** 没有丢失数据。 ** 所有事件都排好队列,一旦积压处理完毕,就全部处理完毕;衡量标准自行恢复到准确值,无需客户采取行动。 其原因源于我们的摄入控制:对于少数量很高的项目,我们允许的摄入率已经偏离了为这些项目提供的能力。 因此,大量的历史进口——完全合法地使用该平台——被承认的速度比其基础设施能够吸收的速度快,而且我们管道的两个属性将局部超载变为全区域的延误。 以下各项修正调整了这些控制,使任何大小的进口自动保持在安全范围内。 发生了什么事 Mixpanel的摄取管被打碎并具有多租位:每个项目的数据都分布在一组分区中,按其预期体积大小,而对于吞吐量,许多客户的事件一起分批处理. 这种设计能提供高效益,但取决于一个变化不定的因素:我们承认项目流量的速度必须与为其提供的容量相匹配. 当这种不稳定性存在时,即使是非常大的进口品也被平稳地吸收。 这里,它没有坚持。 少数非常大的历史数据进口来自一些项目,其允许的摄入率随着时间推移而远远超过其规定的分块能力。 多余的体积集中在特定的分块上,作为**热点**,饱和了为它们服务的溪流分舰队的部分. 有两个因素扩大了影响: *** 批量、多租户加工扩大了热点。 ** 由于来自许多客户的事件分批一起出行,超载分区的缓慢和故障延误了分享这些批次的无关客户事件. * 自动扩大是无效的。 ** 添加能力不能溶解这种热点,因为超载隔板仍被固定在同一个基础设施上,而且我们溪流基础设施的一个部分的容量限制使所增加的能力无法生效。 所有这些都将本来应该短暂的自我缓解的减缓转变为需要人工干预的多小时拖延。 # 时间线\(太平洋时间,7月10日-11日) * **11:35 PM**——自动警报检测到摄入积压;待命工程师立即投入使用。 * **12:49 AM**——张贴情况页事件;影响范围仅指美国地区。 * **1:23 AM** - 最大贡献导入被暂停 。 * **1:55-6:48 AM**——逐步缓解:额外的交通源被节制,某些积压数据经自有客户同意而推迟,输油管中的故障隔离被启用,受影响的基础设施节点被替换。 * **7:19 AM** — 已完全处理后置日志;所有项目正在进行。 状态页移到监测上,然后在稳定观察期后解决. {\fn方正粗倩简体\fs12\an8\1cHFFFF00\b0}根本原因 1. ** 摄入率限制与提供能力不符。 ** 对驱动项目来说,我们平台所接受的费率与为其提供的基础设施发展不相上下,因此合法的大量进口被允许的速度比其分区所能吸收的速度快。 这是系统性的根源。 进口本身是平台的合法用途。 2. ** 批量、多租户处理放大了超载。 ** 超载分区出故障,延误了共享同一批处理的不相干客户活动,将本地化问题传播到整个平台. 3. ** 无法重新分配超载分区的面积。 ** 分流层中的分流到服务器任务没有负载意识,因此无论机队规模大小,热点都被固定在同一个服务器上——总容量足够了,但无法承受. 我们的溪流基础设施的一个部分的缩放限制使情况更加复杂,阻止了扩大规模增加能力,从而推迟诊断,直到工程师进行人工干预。 # 我们正在改变 我们正在建立的最终状态是:**每个项目的摄入量限制自动符合其提供的能力,这样,任何规模的进口,包括完整的历史回填和数据仓同步,都可以在没有预先协调的情况下运行,一个项目的数量不能影响另一个项目的数据新鲜度。 ** 已经部署——改进我们的摄入处理: * ** 改进热点处理。 ** 溪流地层的交通分布现在已意识到负载,将集中的负载更平均地分散出整个船队,个别出问题的物品现在被单独地重新试验,而不是把其余的批次牵起来——虽然没有消除,但减少局部超载可能对无关的交通造成的影响. ** 将工作量最多的工作量** 重新分配给适当规模的基础设施,按风险排列优先次序。 已经部署——改变我们如何操作第三方流动服务: *** 审计和重新调整了机队的能力概况**,因此单个服务器有相当多用于集中装载的头室,并与供应商合作解决事故期间遇到的缩放限制. 进行中: * ** 能力-认识率限制**——缩小个别发放的项目费率限额与每个项目实际提供能力之间的差距,将费率扩大到摄取以前缺乏的路径,并将未来任何限额增加合并到能力增加,以防止这一类错位现象再起。 * ** Finer-grained 体积监测和警报** 因此在影响任何客户之前发现并纠正了能力错配。 * 评估对大宗/回填交通通道的更强工作量隔离/背负恢复的优先次序,因此,历史进口减少了对现场交通的影响 # 常见问题 * 是否有任何数据丢失? ** 否. 在整个事件中,事件被长期排队,一旦积压工作得到清理,将得到充分处理。 在窗户上看到的任何一分一秒的下降都是延迟的展示品,并自我纠正。 * 我是否需要与Mixpanel协调大量进口或回填? ** 没有... 我们的目标是让平台自动将任何进口都保持在安全费率之内,这样回填和仓库同步就可以运行,而无需安排或通知. 我们仍然在推出能感应到的控制措施。 同时,如果你计划一个异常大的进口或回填,我们建议与你的账户团队进行协调,以便我们事先确认能力。 * 如何防止这种情况继续下去? ** 系统性的固定措施是缩小个别发放的项目费率限额与每个项目的实际供给能力之间的差距,并将费率扩大到以前缺乏的摄取路径——因此这种超载量在入院时停止。 此外,延长事件的规模限制是固定的,管道现在单独重复个别的问题项目,因此,局部超载对无关交通的影响要小得多,散装交通正被进一步同活通隔离. ** 个别项目能否在恢复期间列为优先事项? ** 事故期间没有这种能力——所有项目都以同样的速度收回。 我们正在评估为积压的回收工作确定优先次序的机制,作为我们后续工作的一部分。 我们为破坏和暂时压抑的衡量标准所造成的关切而道歉。 请通过你的账户团队 或支持任何问题.

自动翻译自官方事件更新。

1. 2026年6月29日 UTC 19:47investigating

   Mixpanel的性能正在下降 与我们的查询API, 包括增加延迟。 您可能看到慢装报告或查询错误 。 我们赞赏你的耐心,同时我们的工程师们努力恢复正常的功能. 我们将在我们的状况页面上公布最新进展。 如果您有任何问题,请联系支援.

2. 2026年6月29日 UTC 21:04identified

   这一问题已经确定,一个解决办法正在实施之中.

3. 2026年6月29日 UTC 22:42identified

   尽管我们的小组继续调查造成业绩下降的根本原因,但调查的延迟已经稳定下来。 随着调查的进展,我们将继续公布最新情况。 谢谢你的耐心.

4. 2026年6月30日 UTC 02:15monitoring

   一项措施已经执行,我们正在监测结果.

5. 2026年6月30日 UTC 03:30resolved

   这一事件已经得到解决.

自动翻译自官方事件更新。

1. 2026年6月3日 UTC 20:05investigating

   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日 UTC 20:17identified

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

3. 2026年6月3日 UTC 21:27resolved

   This incident has been resolved.

1. 2026年6月2日 UTC 11:02investigating

   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日 UTC 12:31identified

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

3. 2026年6月2日 UTC 14:31monitoring

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

4. 2026年6月2日 UTC 16:53resolved

   This incident has been resolved.

1. 2026年6月1日 UTC 14:15investigating

   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日 UTC 15:08investigating

   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日 UTC 15:29identified

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

4. 2026年6月1日 UTC 16:38monitoring

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

5. 2026年6月1日 UTC 19:42resolved

   This incident has been resolved.

1. 2026年5月19日 UTC 19:03investigating

   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日 UTC 19:10identified

   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日 UTC 20:23monitoring

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

4. 2026年5月19日 UTC 21:18resolved

   This incident has been resolved.

1. 2026年5月14日 UTC 23:17investigating

   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日 UTC 23:48identified

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

3. 2026年5月15日 UTC 10:19identified

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

4. 2026年5月15日 UTC 12:28identified

   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日 UTC 14:31identified

   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日 UTC 16:37identified

   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日 UTC 18:47identified

   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日 UTC 19:56identified

   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日 UTC 21:23identified

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

10. 2026年5月15日 UTC 22:14identified

    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日 UTC 00:17identified

    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日 UTC 01:52monitoring

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

13. 2026年5月16日 UTC 02:50resolved

    This incident has been resolved.

14. 2026年5月21日 UTC 21:43postmortem

    # 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日 UTC 16:34identified

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

2. 2026年5月13日 UTC 21:40identified

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

3. 2026年5月14日 UTC 13:35resolved

   This incident has been resolved.

1. 2026年5月12日 UTC 17:45investigating

   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日 UTC 17:46identified

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

3. 2026年5月12日 UTC 20:24monitoring

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

4. 2026年5月12日 UTC 21:44resolved

   This incident has been resolved.

1. 2026年5月6日 UTC 00:00investigating

   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日 UTC 09:32identified

   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日 UTC 20:04resolved

   This incident has been resolved.

1. 2026年4月9日 UTC 20:03identified

   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日 UTC 21:00monitoring

   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日 UTC 21:44resolved

   This incident has been resolved.

1. 2026年3月16日 UTC 16:50identified

   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日 UTC 19:29monitoring

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

3. 2026年3月16日 UTC 21:47resolved

   This incident has been resolved.

1. 2026年3月2日 UTC 21:00investigating

   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日 UTC 21:09identified

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

3. 2026年3月2日 UTC 21:09monitoring

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

4. 2026年3月2日 UTC 21:53resolved

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