{
"vendor": "Mixpanel",
"slug": "mixpanel",
"platform": "statuspage",
"status_url": "https://www.mixpanelstatus.com",
"last_checked": "2026-09-16T12:28:20Z",
"last_state": "ok",
"history_backfilled": true,
"first_watched": "2026-09-04T07:16:22Z",
"incidents": [
{
"body": "# Mixpanel RCA: Temporary Query Service Disruption for US Projects August 26, 2026\n\n# Summary\n\nBetween approximately **2:02 PM and 3:19 PM PT on August 26, 2026**, projects in the US region experienced failures loading reports and running queries through the Mixpanel UI and Query API. During this window, some queries in the region failed or returned errors. **No customer data was lost, and data ingestion was not affected.** All events continued to be collected and stored normally throughout the incident; once query service was restored, all reports reflected complete, accurate data with no customer action required.\n\nThe cause was identified as a recently deployed internal tool for diagnostic query replay, a capability our engineers use to re-run copies of past queries to debug performance, which unexpectedly wrote large amounts of data to the disks of our query servers, consuming storage capacity the servers need to operate. When those disks filled, the affected servers took themselves out of service. Service was restored, the impacted servers were brought back online, and the internal tooling was disabled. The remediations below add storage safeguards to remove internal tooling's ability to consume resources on query servers, and are designed to prevent this class of failure from happening again in the future.\n\n# What happened\n\nMixpanel's query engine runs on a fleet of servers that each use a set of local storage volumes to cache the data needed to answer queries quickly. Separately, our engineers use diagnostic query replay tooling, a capability our engineers use to reproduce and debug query performance.\n\nWhile applying the diagnostic query replay tooling to a large, complex query, a software bug caused the query replay captures to fan out across the entire fleet instead of remaining confined to a single server. Additionally, it caused far more data than intended to be saved without timely eviction on a single server. Two factors then widened the impact of the issue:\n\n* A single full storage volume took a server fully out of service. Each server treats its cache as unhealthy if any one of its storage volumes crosses a usage threshold, even when all other volumes are healthy. The replay data was written to one specific volume on every server, so servers across the region failed their health checks nearly simultaneously.\n* Cleanup limits did not account for data size. The safeguard limiting replay data on disk counted items at the application level rather than bytes at the filesystem level, so a small number of unexpectedly large captures passed the check while consuming most of the volume\u2019s capacity.\n\nTogether, these allowed a single debugging workflow that normally has a negligible footprint to interrupt production query serving across the US region.\n\n# Timeline \\(Pacific Time, August 26, 2026\\)\n\n* **2:00 PM** \u2014 First oversized diagnostic replay capture was written; storage volumes began to reach their capacity and query success rate began to drop shortly after.\n* **2:17 PM** \u2014 Automated alerting paged the on-call engineer; investigation began immediately and additional engineers were engaged.\n* **2:39 PM** \u2014 Status page incident posted; in-app banner displayed at 2:40 PM.\n* **2:53 PM** \u2014 Root cause identified; recovery efforts began on the first affected server group.\n* **3:19 PM** \u2014 Query service restored for the vast majority of traffic; the final server group fully recovered at 3:27 PM.\n* **3:45 PM** \u2014 Incident resolved after a stable observation period. The diagnostic replay tooling that triggered the issue was fully disabled the same evening.\n\n# Root cause\n\n1. **A software bug in our query replay tooling caused unbounded writes to production storage.** A recently deployed capability for reproducing queries mishandled a particular class of complex query, causing captures to spread to every query server in the region and to write far more data to the affected volumes than the design assumed.\n2. **Replay files consumed disk capacity that query serving depends on.** The replay tooling wrote its files to the query servers' local disks, so runaway replay data exhausted storage capacity the servers need to answer queries.\n3. **Safeguards only partially accounted for the behavior.** The cleanup policy for diagnostic replay data limited the number of items on disk, but not their total size, so it did not engage. Alerting on storage volumes flagged the growth but was not escalated as critical on a per-server basis, which delayed detection until query failures began.\n\n# What we're changing\n\nThe end state we are building toward: internal diagnostic query replay data stored in dedicated object storage, placing no load on production query servers.\n\nAlready deployed:\n\n* **Disabled the internal tooling** that caused the incident, and remediated the underlying issue so diagnostic captures are confined to a single server and the specific query class is handled correctly.\n* **Documented the targeted recovery procedure** used during the incident, i.e., clearing only the affected storage volume rather than restarting full server groups, in our operational runbooks, shortening recovery time if any volume\u2019s capacity runs out in the future.\n\nIn progress:\n\n* **Filesystem-level, size-based limits on diagnostic replay data**, capping total bytes on disk rather than item counts, so oversized captures are rejected or evicted before they can affect the volume\u2019s capacity.\n* **Stricter storage alerting**, escalating per-server volume saturation as critical before it can affect query health checks.\n* **Moving query replay data to dedicated object storage,** so it consumes no resources on production query servers.\n\n# Common questions\n\n* **Was any data lost?** No. Data ingestion was unaffected throughout the incident: events continued to be collected, queued, and stored normally. Only the ability to query was interrupted. Once service was restored, all reports reflected complete data.\n* **Were saved reports, dashboards, or project settings affected?** No. The incident affected query execution only. Nothing stored in your project changed.\n* **Why did it affect multiple US projects at once?** The oversized diagnostic replay data written to every query server's disks at nearly the same time, and each server removes itself from service when any one volume fills. Preventing internal tooling from consuming query-server storage is a core part of our remediation work.\n* **How is this prevented going forward?** The tooling issue is resolved and the tooling remains disabled until size-based limits are in place. Storage alerting is being tightened so saturation is caught before it affects query serving. Structurally, we are moving diagnostic data off production query servers entirely, so internal debugging data will consume no storage on the servers responsible for queries processing.\n\nWe apologize for the disruption and for the time reports were unavailable. Please reach out through your account team or support with any questions.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "major",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-08-26T15:45:49.876-07:00",
"resolved_inferred": false,
"started_at": "2026-08-26T14:39:13.441-07:00",
"state": "postmortem",
"title": "Degraded Query API Performance impacting US Projects",
"updated_at": "2026-09-08T11:28:15.747-07:00",
"url": "https://stspg.io/p7k1qngjlzn1"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "major",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-08-19T20:05:17.077-07:00",
"resolved_inferred": false,
"started_at": "2026-08-19T16:20:44.618-07:00",
"state": "resolved",
"title": "Issues Populating Event Properties in dropdown menus",
"updated_at": "2026-08-19T20:05:17.093-07:00",
"url": "https://stspg.io/f5cgy867j1tj"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-08-06T06:32:35.151-07:00",
"resolved_inferred": false,
"started_at": "2026-08-06T00:19:23.956-07:00",
"state": "resolved",
"title": "Mixpanel MCP: Get-Report degraded",
"updated_at": "2026-08-06T06:32:35.174-07:00",
"url": "https://stspg.io/cqmxbxgp67r6"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-07-22T07:47:22.947-07:00",
"resolved_inferred": false,
"started_at": "2026-07-22T01:03:32.780-07:00",
"state": "resolved",
"title": "Issues serving responses by the Mixpanel agent",
"updated_at": "2026-07-22T07:47:22.966-07:00",
"url": "https://stspg.io/7y5gqnzctpr0"
},
{
"body": "# Summary\n\nBetween approximately **11:35 PM PT on July 10 and 7:19 AM PT on July 11, 2026**, data ingestion for Mixpanel projects in the US region ran behind by up to ~2 hours. During this window, reports and dashboards temporarily showed incomplete data \u2014 recent time ranges could appear as sharp, artificial drops in metrics such as active users or revenue. **No data was lost.** All events were queued durably and processed in full once the backlog cleared; metrics returned to accurate values on their own, with no customer action required.\n\nThe cause originated in our ingestion controls: for a small number of very high-volume projects, the ingestion rates we allowed had drifted out of alignment with the capacity provisioned for those projects. Large historical imports \u2014 entirely legitimate use of the platform \u2014 were therefore admitted faster than their infrastructure could absorb, and two properties of our pipeline turned that localized overload into a region-wide delay. The fixes below realign those controls so that any import, of any size, is automatically kept within safe bounds.\n\n# What happened\n\nMixpanel's ingestion pipeline is sharded and multi-tenant: each project's data is distributed across a set of partitions sized for its expected volume, and for throughput, events from many customers are processed together in batches. This design delivers high efficiency, but it depends on one invariant: the rate at which we admit a project's traffic must match the capacity provisioned for it. When that invariant holds, even very large imports are absorbed smoothly.\n\nHere, it did not hold. A small number of very large historical data imports ran on projects whose allowed ingestion rates had, over time, grown well beyond their provisioned partition capacity. The excess volume concentrated onto specific partitions as **hot spots**, saturating the portion of the streaming fleet serving them. Two factors then widened the impact:\n\n* **Batched, multi-tenant processing amplified the hot spots.** Because events from many customers travel together in batches, slowness and failures on the overloaded partitions delayed unrelated customers' events sharing those batches.\n* **Automatic scale-up was ineffective.** Adding capacity cannot dissolve a hot spot of this kind, because the overloaded partitions stay pinned to the same infrastructure, and a capacity limit in a component of our streaming infrastructure prevented the added capacity from taking effect.\n\nTogether, these turned what should have been a brief, self-healing slowdown into a multi-hour delay requiring manual intervention.\n\n# Timeline \\(Pacific Time, July 10\u201311\\)\n\n* **11:35 PM** \u2014 Automated alerting detected the ingestion backlog; on-call engineer engaged immediately.\n* **12:49 AM** \u2014 Status page incident posted; impact scoped to the US region only.\n* **1:23 AM** \u2014 The largest contributing import was paused.\n* **1:55\u20136:48 AM** \u2014 Progressive mitigations: additional traffic sources throttled, certain backlogged data deferred with the owning customer's agreement, failure isolation enabled in the pipeline, and affected infrastructure nodes replaced.\n* **7:19 AM** \u2014 Backlog fully processed; all projects current. Status page moved to monitoring, then resolved after a stable observation period.\n\n# Root cause\n\n1. **Ingestion rate limits misaligned with provisioned capacity.** For the driving projects, the rates our platform admitted had grown out of step with the infrastructure provisioned for them, so legitimate high-volume imports were let in faster than their partitions could absorb. This is the systemic root cause. The imports themselves were a legitimate use of the platform.\n2. **Batched, multi-tenant processing amplified the overload.** Failures on the overloaded partitions delayed unrelated customers' events sharing the same processing batches, spreading a localized problem across the platform.\n3. **Traffic to the overloaded partitions could not be redistributed.** Partition-to-server assignment in the streaming layer was not load-aware, so the hot spots stayed pinned to the same servers regardless of fleet size \u2014 total capacity was sufficient, but it could not be brought to bear. A scaling limit in a component of our streaming infrastructure compounded this by preventing scale-up from adding capacity, which delayed diagnosis until engineers intervened manually.\n\n# What we're changing\n\nThe end state we are building toward: **every project's ingestion limits automatically match its provisioned capacity, so that imports of any size, including full historical backfills and data warehouse syncs, can run without advance coordination, and one project's volume is prevented from affecting another's data freshness.**.\n\nAlready deployed \u2014 improving our ingestion handling:\n\n* **Improved hot-spot handling.** Traffic distribution in the streaming layer is now load-aware, spreading concentrated load more evenly across the fleet, and individual problem items are now retried separately instead of holding up the rest of their batch \u2014 reducing, though not eliminating, the impact a localized overload can have on unrelated traffic.\n* **Re-provisioned the highest-volume workloads** onto appropriately sized infrastructure, prioritized by risk.\n\nAlready deployed \u2014 changing how we operate the third-party streaming service:\n\n* **Audited and re-tuned the fleet's capacity profile** so individual servers have substantially more headroom for concentrated load, and worked with the provider to resolve the scaling limitation encountered during the incident.\n\nIn progress:\n\n* **Capacity-aware rate limiting** \u2014 closing the gaps between individually granted project rate limits and each project's real provisioned capacity, extending rate limiting to ingestion paths that previously lacked it, and coupling any future limit increase to a capacity increase, which is designed to prevent this class of misalignment from recurring..\n* **Finer-grained volume monitoring and alerting** so capacity misalignment is detected and corrected before it can affect any customer.\n* Evaluating stronger workload isolation/backlog recovery prioritization for bulk/backfill traffic paths, so historical imports have reduced impact on live traffic\n\n# Common questions\n\n* **Was any data lost?** No. Events were durably queued throughout the incident and were fully processed once the backlog cleared. Any metric drops seen during the window were a display artifact of the delay and self-corrected.\n* **Do I need to coordinate large imports or backfills with Mixpanel?** No \u2014 Our goal is for the platform to keep any import within safe rates automatically, so that backfills and warehouse syncs can run without scheduling or notice. We are still rolling out the capacity-aware controls that deliver this. In the meantime, if you are planning an unusually large import or backfill, we recommend coordinating with your account team so we can confirm capacity in advance.\n* **How is this prevented going forward?** The systemic fix is tightening the gaps between individually granted project rate limits and each project's real provisioned capacity, and extending rate limiting to the ingestion paths that previously lacked it \u2014 so overload of this kind is stopped at admission. In addition, the scaling limitation that prolonged the incident is fixed, the pipeline now retries individual problem items separately so a localized overload has far less impact on unrelated traffic, and bulk traffic is being further isolated from live traffic.\n* **Can individual projects be prioritized during recovery?** This capability did not exist during the incident \u2014 all projects recovered at the same rate. We are evaluating prioritization mechanisms for backlog recovery as part of our follow-up work.\n\nWe apologize for the disruption and for the concern the temporarily depressed metrics caused. Please reach out through your account team or support with any questions.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-07-11T08:54:09.168-07:00",
"resolved_inferred": false,
"started_at": "2026-07-11T00:53:32.250-07:00",
"state": "postmortem",
"title": "Temporary Data Ingestion Delay for US Projects",
"updated_at": "2026-07-17T05:11:37.332-07:00",
"url": "https://stspg.io/hdvh21fgtdzd"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-06-29T20:30:14.022-07:00",
"resolved_inferred": false,
"started_at": "2026-06-29T12:47:13.055-07:00",
"state": "resolved",
"title": "Query API Degraded Performance",
"updated_at": "2026-06-29T20:30:14.038-07:00",
"url": "https://stspg.io/whg5ydkh3b8m"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-06-03T14:27:08.222-07:00",
"resolved_inferred": false,
"started_at": "2026-06-03T13:05:03.464-07:00",
"state": "resolved",
"title": "Issue with Inviting and Deleting Users",
"updated_at": "2026-06-03T14:27:08.239-07:00",
"url": "https://stspg.io/29vwsbz39l6q"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-06-02T09:53:09.779-07:00",
"resolved_inferred": false,
"started_at": "2026-06-02T04:02:18.579-07:00",
"state": "resolved",
"title": "Temporary Data Ingestion Delay for US, India and EU projects",
"updated_at": "2026-06-02T09:53:09.794-07:00",
"url": "https://stspg.io/j411dyjz85l8"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-06-01T12:42:16.204-07:00",
"resolved_inferred": false,
"started_at": "2026-06-01T07:15:11.441-07:00",
"state": "resolved",
"title": "Temporary Data Ingestion Delay for US, India and EU projects",
"updated_at": "2026-06-01T12:42:16.218-07:00",
"url": "https://stspg.io/5g40197fw2xr"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-05-19T14:18:42.245-07:00",
"resolved_inferred": false,
"started_at": "2026-05-19T12:03:41.000-07:00",
"state": "resolved",
"title": "Board Access Issues",
"updated_at": "2026-05-19T14:18:42.262-07:00",
"url": "https://stspg.io/sgh5vcdl5tqw"
},
{
"body": "# Mixpanel RCA: Transient Data Access Issue, May 14, 2026\n\n## Summary\n\nOn 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.\n\n## What happened\n\nThis 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.\n\nAs 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.\n\nThe 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.\n\n## Customer impact\n\nImpact unfolded in two phases.\n\nThe first phase ran from Thursday at approximately 2:30 PM PT until 8:11 PM PT \u2014 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 \u2014 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.\n\nThe 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 \u2014 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.\n\n## Timeline \\(Pacific Time\\)\n\n* May 14, 2:30 PM \u2014 Cleanup operation begins\n* May 14, 3:11 PM \u2014 Internal alerting flags query failures; the cleanup operation is stopped within minutes\n* May 14, 4:07 PM \u2014 Status page banner posted\n* May 14, 4:45 PM \u2014 Mitigation deployed: queries automatically retry against an alternate availability zone\n* May 14, 7:12 PM \u2014 Mitigation deployed: queries fall back to a backup datastore for missing files\n* May 14, 8:11 PM \u2014 Query success rate and latency fully restored to normal levels\n* May 15, 5:15 PM \u2014 File restore from backup complete; status page banner resolved\n\n## Why this happened\n\nSeveral contributing factors lined up.\n\nThe 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.\n\nOur 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.\n\nThe extended cleanup was being executed in parallel across two storage layers by two different engineers, which increased the room for error.\n\n## What we're doing to prevent recurrence\n\nWe have already made or have actively in flight the following changes.\n\nWe 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.\n\nDestructive cleanup operations will now run in phased stages, starting with internal projects and pausing for a holding period before any broader execution.\n\nDestructive 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.\n\nWe 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.\n\nLonger 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.\n\n## Closing\n\nReliability 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.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-05-15T19:50:50.660-07:00",
"resolved_inferred": false,
"started_at": "2026-05-14T16:17:21.000-07:00",
"state": "postmortem",
"title": "Query API degraded performance",
"updated_at": "2026-05-21T15:03:05.083-07:00",
"url": "https://stspg.io/4szjc4xm29vg"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-05-14T06:35:42.200-07:00",
"resolved_inferred": false,
"started_at": "2026-05-13T09:34:49.860-07:00",
"state": "resolved",
"title": "Data Volume Monitoring degraded performance",
"updated_at": "2026-05-14T06:35:42.218-07:00",
"url": "https://stspg.io/bbkxpnf0yvxn"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-05-12T14:14:55.000-07:00",
"resolved_inferred": false,
"started_at": "2026-05-12T10:17:38.000-07:00",
"state": "resolved",
"title": "Data Volume Monitoring degraded performance",
"updated_at": "2026-05-12T14:45:12.447-07:00",
"url": "https://stspg.io/b54y1507jv7k"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-05-06T13:04:32.058-07:00",
"resolved_inferred": false,
"started_at": "2026-05-05T17:00:06.884-07:00",
"state": "resolved",
"title": "Snowflake pipeline exports degraded",
"updated_at": "2026-05-06T13:04:32.075-07:00",
"url": "https://stspg.io/df8kn00zn5b1"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-04-09T14:44:42.557-07:00",
"resolved_inferred": false,
"started_at": "2026-04-09T13:03:37.304-07:00",
"state": "resolved",
"title": "Credit Card Processing Interruption",
"updated_at": "2026-04-09T14:44:42.576-07:00",
"url": "https://stspg.io/lk0xcrv7wxhs"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-03-16T14:47:11.125-07:00",
"resolved_inferred": false,
"started_at": "2026-03-16T09:50:48.586-07:00",
"state": "resolved",
"title": "Degraded Query API Performance impacting EU Projects",
"updated_at": "2026-03-16T14:47:11.149-07:00",
"url": "https://stspg.io/rd253px1jtvl"
},
{
"body": "This incident has been resolved. If Mixpanel is still not loading, please clear your cache and cookies.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-03-02T13:53:25.000-08:00",
"resolved_inferred": false,
"started_at": "2026-03-02T13:00:54.643-08:00",
"state": "resolved",
"title": "Error loading Mixpanel Webapp",
"updated_at": "2026-03-03T10:01:11.453-08:00",
"url": "https://stspg.io/0833gfppb7vv"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-03-02T17:43:03.098-08:00",
"resolved_inferred": false,
"started_at": "2026-03-02T11:37:53.000-08:00",
"state": "resolved",
"title": "Degraded MCP Availability",
"updated_at": "2026-03-02T17:43:03.113-08:00",
"url": "https://stspg.io/fbhsxp8ljxb6"
},
{
"body": "This incident is resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-03-02T10:39:26.000-08:00",
"resolved_inferred": false,
"started_at": "2026-03-02T10:02:52.000-08:00",
"state": "resolved",
"title": "Degraded MCP Availability",
"updated_at": "2026-03-02T10:53:33.570-08:00",
"url": "https://stspg.io/zg27fp01xqbj"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-01-30T18:41:22.658-08:00",
"resolved_inferred": false,
"started_at": "2026-01-30T10:39:20.221-08:00",
"state": "resolved",
"title": "Delays with Integrations Syncs (Cohort Exports)",
"updated_at": "2026-01-30T18:41:22.962-08:00",
"url": "https://stspg.io/sj9g048sr4t4"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-01-24T10:00:50.365-08:00",
"resolved_inferred": false,
"started_at": "2026-01-24T06:25:54.373-08:00",
"state": "resolved",
"title": "Degraded Query API Performance impacting US Projects",
"updated_at": "2026-01-24T10:00:50.379-08:00",
"url": "https://stspg.io/fdjrcn397d22"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-01-21T12:48:57.849-08:00",
"resolved_inferred": false,
"started_at": "2026-01-21T12:20:53.000-08:00",
"state": "resolved",
"title": "Errors Loading Mixpanel.com",
"updated_at": "2026-01-21T12:48:58.154-08:00",
"url": "https://stspg.io/pggsgjdw27rj"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-12-09T03:55:36.733-08:00",
"resolved_inferred": false,
"started_at": "2025-12-09T00:41:18.229-08:00",
"state": "resolved",
"title": "Query Data Discrepancies",
"updated_at": "2025-12-09T03:55:37.035-08:00",
"url": "https://stspg.io/l9w1hyjhztst"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-12-03T09:36:14.119-08:00",
"resolved_inferred": false,
"started_at": "2025-12-03T05:54:15.035-08:00",
"state": "resolved",
"title": "SSO outage",
"updated_at": "2025-12-03T09:36:14.136-08:00",
"url": "https://stspg.io/ghfyq5f9q85y"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-11-20T19:04:57.528-08:00",
"resolved_inferred": false,
"started_at": "2025-11-20T17:56:54.000-08:00",
"state": "resolved",
"title": "Query API Errors",
"updated_at": "2025-11-20T19:04:57.872-08:00",
"url": "https://stspg.io/k9ffjh8kf1kj"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-11-20T16:20:08.333-08:00",
"resolved_inferred": false,
"started_at": "2025-11-18T18:40:30.873-08:00",
"state": "resolved",
"title": "Degraded MCP Availability",
"updated_at": "2025-11-20T16:20:08.640-08:00",
"url": "https://stspg.io/kkj229rvdwjv"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-10-27T08:34:15.308-07:00",
"resolved_inferred": false,
"started_at": "2025-10-27T07:09:06.505-07:00",
"state": "resolved",
"title": "Temporary Data Ingestion Delay for Projects with EU Residency",
"updated_at": "2025-10-27T08:34:15.611-07:00",
"url": "https://stspg.io/kp5jj9bbwrrj"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-10-17T17:01:00.634-07:00",
"resolved_inferred": false,
"started_at": "2025-10-17T14:34:04.000-07:00",
"state": "resolved",
"title": "Elevated API Errors",
"updated_at": "2025-10-17T17:01:00.651-07:00",
"url": "https://stspg.io/6z2rmty719pt"
},
{
"body": "The issue has been resolved and all reports are showing imported events as usual. No events were lost during this incident, events were only delayed.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-10-01T08:18:27.000-07:00",
"resolved_inferred": false,
"started_at": "2025-10-01T03:02:47.085-07:00",
"state": "resolved",
"title": "Elevated /import Delays for a subset of US Projects",
"updated_at": "2025-10-01T17:22:19.619-07:00",
"url": "https://stspg.io/29k0tspdlsz4"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-09-08T14:12:05.840-07:00",
"resolved_inferred": false,
"started_at": "2025-09-08T12:24:37.887-07:00",
"state": "resolved",
"title": "Temporary Data Ingestion Delay",
"updated_at": "2025-09-08T14:12:05.856-07:00",
"url": "https://stspg.io/fzr6sxw990jj"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:16:22Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-08-28T15:25:01.606-07:00",
"resolved_inferred": false,
"started_at": "2025-08-28T14:39:38.660-07:00",
"state": "resolved",
"title": "Temporary Data Ingestion Delay for US Projects",
"updated_at": "2025-08-28T15:25:01.973-07:00",
"url": "https://stspg.io/3xjrn54p7fmn"
}
]
}