История сбоев Mixpanel

1. 26 августа 2026 г. в 21:39 UTCinvestigating

   Mixpanel испытывает ухудшение производительности API-интерфейса запросов, что приводит к ответам HTTP 500 при запросе отчетов для проектов с резиденцией данных США. Проекты с ЕС и IN Data Residency остаются без изменений. Мы ценим ваше терпение, пока наши инженеры работают над восстановлением нормальной функциональности. Мы будем публиковать обновления прогресса на нашей странице статуса. Если у вас есть какие-либо вопросы, пожалуйста, обратитесь в службу поддержки.

2. 26 августа 2026 г. в 22:11 UTCidentified

   Этот вопрос был определен, и в настоящее время осуществляется исправление.

3. 26 августа 2026 г. в 22:28 UTCmonitoring

   Было реализовано исправление, и мы видим улучшенные показатели успеха для API запросов. Мы продолжим мониторинг для обеспечения стабильности.

4. 26 августа 2026 г. в 22:45 UTCresolved

   Этот инцидент был урегулирован.

Автоматический перевод официального обновления инцидента.

1. 19 августа 2026 г. в 23:20 UTCidentified

   В настоящее время мы испытываем проблемы с заполнением свойств событий в выпадающих меню. Мы ценим ваше терпение, пока наши инженеры работают над восстановлением функциональности. Если у вас есть вопросы, пожалуйста, свяжитесь с [email protected]

2. 20 августа 2026 г. в 01:04 UTCidentified

   Мы продолжаем работать над решением этой проблемы.

3. 20 августа 2026 г. в 02:52 UTCmonitoring

   Реализовано исправление, и мы отслеживаем результаты.

4. 20 августа 2026 г. в 03:05 UTCresolved

   Этот инцидент был урегулирован.

Автоматический перевод официального обновления инцидента.

1. 6 августа 2026 г. в 07: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. 6 августа 2026 г. в 08:39 UTCidentified

   The issue has been identified and fix is being implemented.

3. 6 августа 2026 г. в 09: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. 6 августа 2026 г. в 13:32 UTCresolved

   This incident has been resolved.

1. 22 июля 2026 г. в 08:03 UTCinvestigating

   В настоящее время мы испытываем проблемы с агентом Mixpanel в веб-приложении. Наша инженерная команда была предупреждена и изучает проблему и работает над восстановлением ее функциональности. Мы ценим ваше терпение, поскольку мы работаем над решением этой проблемы. Если у вас есть какие-либо вопросы, пожалуйста, обратитесь в службу поддержки.

2. 22 июля 2026 г. в 09:52 UTCinvestigating

   команда продолжает исследовать проблему и дальнейшие шаги. Спасибо за ваше терпение.

3. 22 июля 2026 г. в 10:55 UTCmonitoring

   Реализовано исправление, и мы отслеживаем результаты.

4. 22 июля 2026 г. в 14:47 UTCresolved

   Этот инцидент был урегулирован.

Автоматический перевод официального обновления инцидента.

1. 11 июля 2026 г. в 07:53 UTCinvestigating

   В настоящее время мы испытываем задержки в приеме данных, что влияет на данные в реальном времени для проектов, зарегистрированных в проектах США, что приводит к задержкам для подмножества проектов. Несмотря на то, что данные не теряются, наша команда инженеров активно изучает этот вопрос и работает над восстановлением функциональности в режиме реального времени. Мы ценим ваше терпение в это время. Если у вас есть какие-либо вопросы, пожалуйста, обратитесь в службу поддержки.

2. 11 июля 2026 г. в 09:17 UTCinvestigating

   Мы продолжаем расследование этого вопроса.

3. 11 июля 2026 г. в 10:15 UTCidentified

   Этот вопрос был определен, и в настоящее время осуществляется исправление.

4. 11 июля 2026 г. в 12:54 UTCidentified

   Мы продолжаем работать над решением этой проблемы.

5. 11 июля 2026 г. в 14:25 UTCmonitoring

   Реализовано исправление, и мы отслеживаем результаты.

6. 11 июля 2026 г. в 15:54 UTCresolved

   Этот инцидент был урегулирован.

7. 16 июля 2026 г. в 23:47 UTCpostmortem

   # Summary Between 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 — 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. The 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 — entirely legitimate use of the platform — 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. # What happened Mixpanel'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. Here, 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: * **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. * **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. Together, these turned what should have been a brief, self-healing slowdown into a multi-hour delay requiring manual intervention. # Timeline \(Pacific Time, July 10–11\) * **11:35 PM** — Automated alerting detected the ingestion backlog; on-call engineer engaged immediately. * **12:49 AM** — Status page incident posted; impact scoped to the US region only. * **1:23 AM** — The largest contributing import was paused. * **1:55–6:48 AM** — 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. * **7:19 AM** — Backlog fully processed; all projects current. Status page moved to monitoring, then resolved after a stable observation period. # Root cause 1. **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. 2. **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. 3. **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 — 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. # What we're changing The 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.**. Already deployed — improving our ingestion handling: * **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 — reducing, though not eliminating, the impact a localized overload can have on unrelated traffic. * **Re-provisioned the highest-volume workloads** onto appropriately sized infrastructure, prioritized by risk. Already deployed — changing how we operate the third-party streaming service: * **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. In progress: * **Capacity-aware rate limiting** — 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.. * **Finer-grained volume monitoring and alerting** so capacity misalignment is detected and corrected before it can affect any customer. * Evaluating stronger workload isolation/backlog recovery prioritization for bulk/backfill traffic paths, so historical imports have reduced impact on live traffic # Common questions * **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. * **Do I need to coordinate large imports or backfills with Mixpanel?** No — 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. * **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 — 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. * **Can individual projects be prioritized during recovery?** This capability did not exist during the incident — all projects recovered at the same rate. We are evaluating prioritization mechanisms for backlog recovery as part of our follow-up work. We 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.

Автоматический перевод официального обновления инцидента.

1. 29 июня 2026 г. в 19:47 UTCinvestigating

   Mixpanel испытывает ухудшение производительности с помощью нашего API запросов, включая повышенную задержку. Вы можете увидеть отчеты о медленной загрузке или ошибки запросов. Мы ценим ваше терпение, пока наши инженеры работают над восстановлением нормальной функциональности. Мы будем публиковать обновления прогресса на нашей странице статуса. Если у вас есть какие-либо вопросы, пожалуйста, обратитесь в службу поддержки.

2. 29 июня 2026 г. в 21:04 UTCidentified

   Этот вопрос был определен, и в настоящее время осуществляется исправление.

3. 29 июня 2026 г. в 22:42 UTCidentified

   Задержка запросов стабилизировалась, хотя наша команда продолжает исследовать основную причину ухудшения производительности. Мы будем продолжать публиковать обновления по мере продвижения нашего расследования. Спасибо за ваше терпение.

4. 30 июня 2026 г. в 02:15 UTCmonitoring

   Реализовано исправление, и мы отслеживаем результаты.

5. 30 июня 2026 г. в 03:30 UTCresolved

   Этот инцидент был урегулирован.

Автоматический перевод официального обновления инцидента.

1. 3 июня 2026 г. в 20: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. 3 июня 2026 г. в 20:17 UTCidentified

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

3. 3 июня 2026 г. в 21:27 UTCresolved

   This incident has been resolved.

1. 2 июня 2026 г. в 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. 2 июня 2026 г. в 12:31 UTCidentified

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

3. 2 июня 2026 г. в 14:31 UTCmonitoring

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

4. 2 июня 2026 г. в 16:53 UTCresolved

   This incident has been resolved.

1. 1 июня 2026 г. в 14: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. 1 июня 2026 г. в 15: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. 1 июня 2026 г. в 15:29 UTCidentified

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

4. 1 июня 2026 г. в 16:38 UTCmonitoring

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

5. 1 июня 2026 г. в 19:42 UTCresolved

   This incident has been resolved.

1. 19 мая 2026 г. в 19: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. 19 мая 2026 г. в 19: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. 19 мая 2026 г. в 20:23 UTCmonitoring

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

4. 19 мая 2026 г. в 21:18 UTCresolved

   This incident has been resolved.

1. 14 мая 2026 г. в 23: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. 14 мая 2026 г. в 23:48 UTCidentified

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

3. 15 мая 2026 г. в 10:19 UTCidentified

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

4. 15 мая 2026 г. в 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. 15 мая 2026 г. в 14: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. 15 мая 2026 г. в 16: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. 15 мая 2026 г. в 18: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. 15 мая 2026 г. в 19: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. 15 мая 2026 г. в 21:23 UTCidentified

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

10. 15 мая 2026 г. в 22: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. 16 мая 2026 г. в 00: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. 16 мая 2026 г. в 01:52 UTCmonitoring

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

13. 16 мая 2026 г. в 02:50 UTCresolved

    This incident has been resolved.

14. 21 мая 2026 г. в 21: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. 13 мая 2026 г. в 16:34 UTCidentified

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

2. 13 мая 2026 г. в 21:40 UTCidentified

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

3. 14 мая 2026 г. в 13:35 UTCresolved

   This incident has been resolved.

1. 12 мая 2026 г. в 17: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. 12 мая 2026 г. в 17:46 UTCidentified

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

3. 12 мая 2026 г. в 20:24 UTCmonitoring

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

4. 12 мая 2026 г. в 21:44 UTCresolved

   This incident has been resolved.

1. 6 мая 2026 г. в 00: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. 6 мая 2026 г. в 09: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. 6 мая 2026 г. в 20:04 UTCresolved

   This incident has been resolved.

1. 9 апреля 2026 г. в 20: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. 9 апреля 2026 г. в 21: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. 9 апреля 2026 г. в 21:44 UTCresolved

   This incident has been resolved.

1. 16 марта 2026 г. в 16: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. 16 марта 2026 г. в 19:29 UTCmonitoring

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

3. 16 марта 2026 г. в 21:47 UTCresolved

   This incident has been resolved.

1. 2 марта 2026 г. в 21: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. 2 марта 2026 г. в 21:09 UTCidentified

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

3. 2 марта 2026 г. в 21:09 UTCmonitoring

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

4. 2 марта 2026 г. в 21:53 UTCresolved

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

1. 2 марта 2026 г. в 19:48 UTCinvestigating

   A subset of users are experiencing OAuth issues when connecting to our MCP server. We are currently investigating this issue.

2. 2 марта 2026 г. в 19:49 UTCidentified

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

3. 2 марта 2026 г. в 19:50 UTCmonitoring

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

4. 2 марта 2026 г. в 20:08 UTCmonitoring

   We have partially mitigated the issue and are continuing to monitor for any further impact. We are also actively working to address the root cause.

5. 3 марта 2026 г. в 01:43 UTCresolved

   This incident has been resolved.

1. 2 марта 2026 г. в 18:41 UTCinvestigating

   A subset of users are experiencing OAuth issues when connecting to our MCP server. We are currently investigating this issue.

2. 2 марта 2026 г. в 18:44 UTCidentified

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

3. 2 марта 2026 г. в 18:45 UTCmonitoring

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

4. 2 марта 2026 г. в 18:53 UTCresolved

   This incident is resolved.

1. 30 января 2026 г. в 18:39 UTCinvestigating

   We are currently experiencing delays with Cohort Syncs to external destinations, including custom webhooks and engagement platforms. Our team is investigating the issue and actively working on a resolution. We sincerely apologize for the inconvenience and thank you for your kind understanding. If you have any questions, please contact support

2. 30 января 2026 г. в 20:05 UTCmonitoring

   A fix has been implemented, and we are monitoring the results. Recurring cohort syncs should resume on the next scheduled run with no additional action required.

3. 30 января 2026 г. в 22:14 UTCmonitoring

   We are continuing to monitor for further issues. We have identified that a subset of Cohort Syncs are still experiencing delays and are working to resolve these remaining cases.

4. 31 января 2026 г. в 01:48 UTCmonitoring

   Additional fixes have been implemented. We are continuing to monitor for any further issues.

5. 31 января 2026 г. в 02:41 UTCresolved

   This incident has been resolved.