Is Adapty down?

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.

We are continuing to monitor for any further issues.

This incident has been resolved.

We're currently experiencing issues processing a subset of incoming SDK events, which may cause some events to be delayed or rejected. Our team has identified the cause and is working on a fix.

This incident has been resolved. Event processing has fully recovered, and all SDK events are being ingested normally

We're experiencing an increased response time for the SDK API requests and are currently looking into the issue

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

This incident has been resolved.

We're experiencing an elevated level of API errors and are currently looking into the issue.

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

This incident has been resolved.

## Postmortem — SDK API errors & elevated latency \(2026-06-19\) ### Summary On 2026-06-19 between 13:27 and 13:50 UTC, the Adapty SDK API \([api.adapty.io](http://api.adapty.io)\) experienced elevated latency and HTTP 504 errors for approximately 23 minutes. A surge in request volume saturated an internal coordination store that the request path depends on, causing SDK requests to queue and time out. The affected components recovered automatically as the surge subsided. ### Impact * **Duration:** Approximately 23 minutes \(13:27 → 13:50 UTC\). * **Surfaces affected:** SDK endpoints \(profile updates, attribution, receipt/purchase validation\) on [api.adapty.io](http://api.adapty.io), including the China edge. Delivery of third-party integration events \(analytics and attribution destinations\) was also reduced during the window. * **Visible signal:** HTTP 504 errors reached roughly half of SDK traffic at peak, with request latency well above normal. * **Recovery:** SDK clients that automatically retry recovered most requests on retry. Some third-party integration events that do not retry may be missing for this window and could require backfill — if your integration is missing data, see the note below. ### Timeline \(UTC\) | Time | Event | | --- | --- | | ~13:23 | An internal coordination store the request path depends on begins approaching its connection limit under rising load. | | 13:27 | SDK API latency crosses alerting thresholds; impact begins. | | 13:34 | HTTP 504 error rate peaks at roughly half of SDK traffic. | | 13:40 | Reduced delivery of third-party integration events observed. | | 13:42–13:50 | Errors clear, latency returns to normal, and integration delivery recovers. | ### Root cause and contributing factors **Root cause:** A burst in SDK request volume drove an internal coordination store to its connection limit. When that store could no longer accept new connections, dependent SDK requests stalled and timed out, which in turn put memory pressure on the affected service instances and amplified the impact until the burst subsided. **Contributing factors:** 1. The request path could open an effectively unbounded number of connections to the coordination store, so a request surge translated directly into hitting the store's connection ceiling. 2. The coordination workload concentrated on a single store with no sharding to spread load. 3. There was no early-warning alert on the underlying connection metric — the first signal was already a customer-facing error rate. ### What went well * Automated monitoring detected the problem within seconds of the threshold being crossed. * The system recovered on its own once the surge passed, without prolonged manual intervention. * Built-in connection limits kept the store's behavior bounded rather than failing unpredictably. ### What we will do **Prevent** * Bound the number of connections the request path can open to the coordination store, so a traffic surge cannot exhaust it. * Spread coordination load across multiple stores rather than a single one. **Detect** * Add early-warning alerts on the coordination store's connection usage and wait time, well before customer-facing thresholds are reached. **Mitigate** * Increase memory headroom and add graceful load-shedding to the affected SDK service so a surge degrades gracefully instead of restarting instances. We apologize for the disruption to your applications during this window. If your integration is missing data from this period, please reach out to your usual Adapty contact and reference the 2026-06-19 incident.

We're experiencing an elevated level of API errors and are currently looking into the issue.

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

We are continuing to monitor for any further issues.

This incident has been resolved.

## Postmortem — Adapty SDK API and Dashboard errors \(2026-06-18\) ### Summary On 2026-06-18 between 06:20 and 08:34 UTC, the Adapty SDK API and Dashboard returned elevated 5xx errors for approximately two hours. The cause was a change to an internal coordination service \(used to safely serialize concurrent operations\) that could not handle production load and began rejecting connections. Requests that depend on this service failed until the change was reverted, after which traffic recovered. ### Impact * **Duration:** Approximately 2 hours \(06:20 → 08:34 UTC\); the most acute window was ~07:10 → 08:17 UTC. * **Surfaces affected:** SDK endpoints \(purchase and receipt validation for the App Store, Play Store, and Paddle\), the Dashboard \(publishing Flows\), and some third-party integration deliveries. * **Visible signal:** Elevated 5xx error rates and increased latency on SDK endpoints; Dashboard Flow publishing returned errors. * **Recovery:** SDK clients that automatically retry recovered most requests. Some integration deliveries or operations that do not retry may need to be re-run; if you believe data from this window is missing, contact your Adapty representative. ### Timeline \(UTC\) | Time | Event | | --- | --- | | ~06:20 | Automated monitoring begins reporting elevated SDK latency and 5xx errors. | | ~07:11 | Impact on Dashboard Flow publishing confirmed; investigation underway. | | ~07:21 | Root cause identified; remediation begins. | | ~08:00 | Change reverted; error rates begin falling. | | ~08:17 | Traffic stabilized. | | ~08:34 | Recovery confirmed; incident closed. | ### Root cause and contributing factors **Root cause:** An internal coordination service that serializes concurrent operations was switched to a new backing store that was not provisioned for production load. Under real traffic it exhausted its connection and memory limits and began resetting connections, so any request needing to coordinate an operation failed. **Contributing factors:** 1. The change reached full production traffic without a gradual/canary rollout or an instant rollback control to bound its blast radius. 2. The new backing store was under-provisioned for production load. 3. A failure in this coordination service caused requests to fail outright rather than falling back gracefully, so a single dependency issue affected many surfaces at once. ### What went well * Once engaged, the team identified the root cause within minutes. * The fix was straightforward and fast to apply \(revert the change\). * The coordination service failed safely — there is no evidence of inconsistent or duplicated data. * SDK clients with automatic retry recovered most requests. ### What we will do **Prevent** * Roll out changes to shared coordination infrastructure gradually \(canary\), with an instant rollback control. * Require a kill-switch for any change exercised against shared production infrastructure. **Detect** * Add targeted early-warning alerts on the coordination service's saturation \(connections/memory\) so issues are caught before they affect customer requests. **Mitigate** * Make the coordination service fail gracefully \(fall back / degrade\) instead of failing requests outright. * Right-size the new backing store before any further production exposure. We apologize for the disruption to your applications during this window. If your integration is missing data from this period, please reach out to your usual Adapty contact and reference the 2026-06-18 incident.