Is Sardine down?

We are currently investigating an issue affecting Advanced Aggregations, where some customers may experience inaccurate results. We will post updates as we learn more.

We are continuing to investigate this issue

We have identified the root cause of the issue affecting Advanced Aggregations and our engineering team is actively working on a fix. We will provide a further update once the fix has been deployed and verified.

team is actively looking into it. Issue is partially mitigated, and we're still working on fixing the root cause.

fix is being validated and being rolled out

incident is resolved. We'll provide post mortem.

### Summary On September 4–5, 2026 \(UTC\), we experienced an issue affecting **Advanced Aggregations** **in which some customers saw inaccurate aggregation results because recent card transaction data may have been missing**. We fixed **the issue, and backfilled the data**. Advanced Aggregations results are expected to be correct again after **2026-09-05 03:50 UTC**. ### What happened A subset of card transaction records failed to be written into one of our tables because the column used to store the payment method id could not support the size of newly generated card IDs. As a result, those specific transactions were missing from the aggregated dataset, which could lead to incorrect results for customers ingesting this type of data. An impact assessment is available upon request. No data was permanently lost: failed writes were routed to a durable deadletter queue for later reprocessing. After mitigation was deployed, we replayed the queued events and completed a backfill so that aggregations reflected the correct underlying transaction data. Incident started at 2026-09-04 01:02 UTC and resolved at 2026-09-05 03:50 UTC. ### Why it happened The root cause was a **data type mismatch**: the `cards` table `id` values grew beyond the maximum value supported by a **4-byte integer**. `id` field has 8-byte integer so there was no error storing cards. However, `card_id` field in the Advanced Aggregations schema was 4-byte, causing inserts to fail for transactions related to newer cards. To remediate safely at scale, we: * Added new **8-byte integer \(**`bigint`\) columns for the affected identifiers and updated write logic to use them. * Introduced a **compatibility read path** so reads return the correct identifier whether data is stored in the old or new columns, along with new indexes to preserve query performance. ### What we are doing about it * We’re reviewing improvements to monitor schema limit risks earlier and prevent similar issues in the future. * We’ll enhance monitoring on deadletter queue so we can detect issue like this sooner.

We are currently investigating this issue.

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

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

New sessions are being shown OK, a few older ones might still be missing, they'll be shown shortly.

This incident has been resolved.

We are currently experiencing degraded performance in retrieving the latest customer sessions in the Customer Intelligence page. Root cause has been determined. We are working on resolution.

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

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

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

A fix has been implemented and results are being displayed in the Customer Intelligence page. We are monitoring the process until full service is restored.

We are continuing to monitor for any further issues.

The issue has been resolved.

We are currently investigating this issue.

This incident has been resolved. A Postmortem will be published soon.

**Summary** On 2026-07-15, API requests experienced elevated error rates and increased tail latency \(p99\). Median latency \(p50\) was not affected and there was little effect on 95th percentile latency \(p95\), so most requests performed normally. We began investigating at 14:34 UTC and applied a fix at approximately 19:56 UTC, after which performance returned to normal. **What happened?** Through the affected period, a portion of API requests returned errors, responded with reason code SITO \(Sardine internal timeout\) or timed out rather than completing, with intermittent spikes during which a larger share of requests were affected. **Why did it happen?** A scaling configuration prevented part of our platform from adding capacity as traffic increased. As traffic rose through the day, available capacity was exhausted, causing timeouts and errors for some requests. **What are we doing about this?** We corrected the configuration at **19:56 UTC**, which immediately restored normal performance. We are also making the affected part of the platform more resilient to sudden traffic increases and adding proactive monitoring so we can detect and respond to this class of issue faster in future. We apologize for the disruption.

We are currently investigating this issue.

This incident has been resolved.