Adapty Outage History

Started Oct 02, 2026, 11:46 PM UTC· resolved Oct 03, 2026, 02:54 AM UTC

1. identified Oct 03, 2026, 01:57 AM UTC

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

2. identified Oct 03, 2026, 02:11 AM UTC

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

3. resolved Oct 03, 2026, 02:59 AM UTC

   This incident has been resolved.

4. postmortem Oct 03, 2026, 04:28 PM UTC

   Duration: October 2, 23:46 UTC to October 3, 02:54 UTC \(3 hours 8 minutes\) Affected: SDK API, server-side API and web API in the US region. The Adapty Dashboard and the EU region were not affected. We're sorry for the disruption this caused you and your users. We know how much you rely on Adapty, and we let you down. **What happened** At 23:46 UTC, a network switch at our hosting provider's data center had a disruption lasting about one second. Because of it, one of the servers in our US profile database briefly lost connection to the rest of the cluster and then reconnected. When a server rejoins like this, the database redistributes and re-syncs data across the whole cluster to make sure every copy is up to date. While that re-sync was running, one type of lookup failed: finding a profile by customer user ID or device. The SDK relies on this lookup to create new profiles and identify users. Until the re-sync finished at 02:54 UTC, about 30% of SDK requests returned errors, and many of the rest responded more slowly than usual. During the same window, about 90% of server-side API requests failed. Errors stopped once the re-sync completed. **How it affected apps** Profile creation failed when a customer user ID was used. New users opening an app often couldn't do it. Apps that wait for profile creation before showing a paywall were affected the most. For these apps, the paywall often didn't load, so some users couldn't make a purchase. Apps that let purchases go ahead without waiting for profile creation were much less affected. Purchases went through, but some profile data, such as attribution, may be missing for users affected during the incident. **What we're doing next** The lookup that failed should never have been able to take down critical SDK requests like these. We're working on a permanent fix that removes this dependency, so the main SDK paths, including profile creation and paywalls, keep working normally even while the database is re-syncing. Once again, we're truly sorry this happened.

Read the full incident report →

Started Sep 16, 2026, 05:32 PM UTC· resolved Sep 16, 2026, 05:56 PM UTC

1. identified Sep 16, 2026, 05:32 PM UTC

   We’re observing a drop of the rate in Google Play pub-sub notifications. You may notice delay in the delivery of events. We are investigating.

2. resolved Sep 16, 2026, 05:56 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Sep 15, 2026, 01:43 PM UTC· resolved Sep 15, 2026, 04:23 PM UTC

1. identified Sep 15, 2026, 01:43 PM UTC

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

2. identified Sep 15, 2026, 02:06 PM UTC

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

3. identified Sep 15, 2026, 02:23 PM UTC

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

4. identified Sep 15, 2026, 02:33 PM UTC

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

5. identified Sep 15, 2026, 02:43 PM UTC

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

6. monitoring Sep 15, 2026, 02:46 PM UTC

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

7. resolved Sep 15, 2026, 04:23 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Sep 10, 2026, 07:04 AM UTC· resolved Sep 10, 2026, 10:08 AM UTC

1. investigating Sep 10, 2026, 07:04 AM UTC

   We are currently investigating elevated error rates on the EU API endpoint (api-eu.adapty.io) caused by a hardware failure at our hosting provider. SDK requests to the EU region may fail or be retried. Data will be delivered once the service is restored. We will post an update within 30 minutes.

2. identified Sep 10, 2026, 07:53 AM UTC

   We have identified the cause: a hardware failure at our hosting provider affected the primary database server and several nodes in the EU region. SDK API requests to the EU endpoint (api-eu.adapty.io) are currently failing. Our team, together with the provider, is working on restoring the service by switching to the standby database. No purchase data is lost: SDK requests are retried automatically and events will be processed once the service is restored. Next update in 30 minutes.

3. monitoring Sep 10, 2026, 08:35 AM UTC

   The EU API (api-eu.adapty.io) has been fully operational since 08:16 UTC after we failed over to the standby database. Error rates have been at zero since 08:24 UTC. Background processing (events, integrations, analytics) is catching up on the backlog accumulated during the outage, so some events in the dashboard and integrations may appear with a delay. We are monitoring closely and will post a final update once processing is back to normal

4. resolved Sep 10, 2026, 10:08 AM UTC

   This incident has been resolved. All systems are operating normally.

Read the full incident report →

Started Sep 01, 2026, 02:07 PM UTC· resolved Sep 01, 2026, 05:23 PM UTC

1. identified Sep 01, 2026, 02:07 PM UTC

   Our data processing infrastructure is running behind which is causing inaccuracies in the reporting tools. No data has been lost and the system should be caught up shortly.

2. monitoring Sep 01, 2026, 04:51 PM UTC

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

3. resolved Sep 01, 2026, 05:23 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jul 22, 2026, 08:46 AM UTC· resolved Jul 22, 2026, 08:55 AM UTC

1. investigating Jul 22, 2026, 09:06 AM UTC

   We are currently investigating this issue.

2. identified Jul 22, 2026, 09:07 AM UTC

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

3. monitoring Jul 22, 2026, 09:08 AM UTC

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

4. monitoring Jul 22, 2026, 09:08 AM UTC

   We are continuing to monitor for any further issues.

5. resolved Jul 22, 2026, 09:10 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 19, 2026, 01:30 PM UTC· resolved Jun 19, 2026, 01:55 PM UTC

1. identified Jun 19, 2026, 01:30 PM UTC

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

2. monitoring Jun 19, 2026, 01:46 PM UTC

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

3. resolved Jun 19, 2026, 01:55 PM UTC

   This incident has been resolved.

4. postmortem Jun 19, 2026, 03:21 PM UTC

   ## 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.

Read the full incident report →

Started Jun 17, 2026, 04:11 PM UTC· resolved Jun 17, 2026, 04:59 PM UTC

1. investigating Jun 17, 2026, 04:11 PM UTC

   We are currently investigating this issue.

2. investigating Jun 17, 2026, 04:13 PM UTC

   We are continuing to investigate this issue.

3. identified Jun 17, 2026, 04:25 PM UTC

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

4. monitoring Jun 17, 2026, 04:41 PM UTC

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

5. resolved Jun 17, 2026, 04:59 PM UTC

   This incident has been resolved.

6. postmortem Jun 17, 2026, 09:16 PM UTC

   ## Postmortem — Adapty SDK API elevated errors \(2026-06-17\) ### Summary On 2026-06-17 between 16:06 and 19:40 UTC, the Adapty SDK API returned elevated 5xx errors and increased latency for mobile apps, in two bursts \(around 16:06 and around 18:07 UTC\). A coordination service that the API relies on to serialize per-user updates reached its connection limit during a routine deployment, and requests that depend on it began to stall. This in turn exhausted the database connection pool, briefly cascading into errors across SDK endpoints and delaying some third-party integration deliveries. We mitigated by relieving load on the coordination service and raising its connection ceiling; the issue recurred about an hour later before being stabilized. ### Impact * **Duration:** Approximately 3h34m \(16:06 → 19:40 UTC\), with two acute windows: ~16:06–16:53 and ~18:07–18:34 UTC. * **Surfaces affected:** SDK endpoints \(profile updates, attribution, receipt/purchase validation for the App Store and Play Store\), third-party integration deliveries, and parts of the Dashboard. * **Visible signal:** Elevated 5xx rates and latency on SDK API requests; some integration deliveries were delayed. * **Recovery:** SDK clients that automatically retry recovered most requests on retry. Some integration deliveries and attribution events that do not retry may have been delayed and, in rare cases, may require replay. ### Timeline \(UTC\) | Time | Event | | --- | --- | | ~16:06 | Elevated SDK API latency and 5xx errors begin during a routine deployment. | | ~16:10 | A coordination service reaches its connection ceiling, causing dependent requests to fail. | | ~16:42 | First burst largely subsides after load is relieved. | | ~17:08 | Connection ceiling raised to add headroom. | | ~18:07 | A second, shorter burst occurs and is mitigated. | | 19:40 | Full recovery confirmed across affected services. | ### Root cause and contributing factors **Root cause:** A service used to coordinate per-user updates on high-traffic SDK endpoints reached its maximum connection limit during a deployment, when a surge of reconnecting clients combined with in-flight request backlog. Requests waiting on that coordination layer stalled, which then exhausted the database connection pool and produced cascading errors. **Contributing factors:** 1. The coordination service's connection limit was shared across all SDK request paths, and client connections were not bounded on the application side — so a reconnection surge could saturate it. 2. There was no early-warning alert below the service's terminal connection threshold; the first signal appeared only once the system was already near saturation. 3. Raising the connection ceiling added headroom but did not address the underlying surge behavior, which is why a second burst occurred. ### What went well * Protective limits behaved as designed and prevented data inconsistency under load. * Once identified, mitigations were applied quickly from a known recovery procedure. * Automatic SDK client retries recovered the majority of affected requests. ### What we will do **Prevent** — stop the same cause from recurring * Bound client connections to the coordination service on the application side so a reconnection surge cannot saturate it. * Distribute coordination load across multiple nodes to remove the single-node connection ceiling. **Detect** — catch the same cause faster next time * Add early-warning alerting on coordination-service connections and connection rate, well before saturation. * Add dedicated alerting on database connection-pool utilization. **Mitigate** — limit blast radius if the same cause recurs * Stagger deployment rollouts to avoid synchronized client reconnection surges. * Make the affected request path degrade gracefully instead of stalling when the coordination service is unavailable. 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-17 incident.

Read the full incident report →

Started May 19, 2026, 04:38 PM UTC· resolved May 19, 2026, 04:47 PM UTC

1. investigating May 19, 2026, 04:38 PM UTC

   We are currently investigating this issue.

2. monitoring May 19, 2026, 04:47 PM UTC

   We have applied the fix. Storage nodes are in sync now. Response time and HTTP status codes are getting back to normal.

3. resolved May 19, 2026, 04:52 PM UTC

   All SDK HTTP API metrics have returned to normal. As part of our service security enhancement efforts, we accidentally blocked clock synchronization traffic. Clock synchronization is essential for our distributed storage.

4. postmortem May 19, 2026, 05:36 PM UTC

   ## Postmortem — SDK API & Dashboard 5xx errors \(2026-05-19\) ### Summary On 2026-05-19 between 16:21 and 16:55 UTC, the Adapty SDK API and Dashboard returned elevated 5xx errors for approximately 34 minutes. The primary key-value store in the SDK request path entered a protective "stop-writes" state after its cluster nodes' clocks drifted past the allowed skew threshold; the drift accumulated because outbound NTP traffic from the affected hosts had been blocked at the network firewall layer, leaving the nodes unable to synchronize with upstream time sources. A clock step-correction was applied, the database resumed accepting writes within one minute, and all customer-visible errors cleared by 16:55 UTC. ### Impact * **Duration:** Approximately 34 minutes \(16:21 → 16:55 UTC\); the most acute window was 16:21 → 16:46 UTC. * **Surfaces affected:** SDK endpoints \(profile updates, attribution, receipt validation, App Store / Play Store / Stripe / Paddle webhook deliveries\), the Dashboard, and 3rd-party integration deliveries. * **Visible signal:** Elevated 5xx rates at the edge for SDK endpoints; the mobile-API readiness probe briefly reported DOWN between 16:43 and 16:45 UTC. * **Recovery:** SDK clients that automatically retry recovered most requests on retry. Some webhook deliveries and attribution events that do not retry may require backfill or replay. ### Timeline \(UTC\) | Time | Event | | --- | --- | | ~16:00 | Database cluster clock skew crosses the configured stop-writes threshold; the protective alert enters its evaluation delay window. | | 16:21 | Stop-writes condition activates; the database begins rejecting writes; SDK 5xx errors begin at the edge. | | 16:22–16:32 | 5xx error rate climbs across SDK endpoints. | | 16:43 | NTP step-correction applied to the affected hosts; cluster clock skew drops from ~38 seconds to under 1 second within ~1 minute. | | 16:46 | The database resumes accepting writes; SDK 5xx rates begin returning to baseline. | | 16:55 | All customer-visible errors cleared; incident fully resolved. | ### Root cause and contributing factors **Root cause:** The SDK request path depends on a clustered key-value store that protects data consistency by halting writes when cluster nodes' clocks disagree by more than a configured threshold. On 2026-05-19, the nodes' clocks had been drifting for an extended period and crossed that threshold around 16:00 UTC, which caused the cluster to halt writes and the SDK API to return 5xx. **Contributing factors:** 1. **Outbound NTP egress was blocked** at the network firewall layer for the affected hosts, so the time daemon on each node could not reach upstream NTP servers. The block accumulated drift silently over many hours. 2. **No early-warning alert on clock drift.** The only alert in place fired at the protective stop-writes threshold — when the incident was already in progress, not while it was approaching. There was no graduated alert at a lower skew value that would have provided hours of lead time. 3. **No direct NTP-synchronization health check** at the host level. Time-sync failure was only observable as a downstream effect on cluster skew, not as a primary signal. 4. **Protective stop-writes worked as designed.** The database correctly refused potentially-inconsistent writes, which is preferred over silent data corruption; however, this surfaces to customers as 5xx rather than as a graceful degradation. ### What went well * The protective stop-writes mechanism behaved as intended and prevented data inconsistency in the affected database. * Once identified, the fix was surgical and fast: a single clock step-correction returned cluster skew from ~38 seconds to under 1 second in ~1 minute, and the database recovered immediately afterward. ### What we will do **Prevent** — stop the same cause from recurring * Audit firewall egress rules on every host in the affected tier; confirm outbound NTP \(UDP/123\) is explicitly allowed to documented upstream time sources; add an active probe that verifies egress and alerts if it regresses. * Document the time-synchronization topology for the affected database tier and remove ambiguity about expected behavior. **Detect** — catch the same cause faster next time * Add an early-warning alert on cluster clock skew at a fraction of the protective threshold, with a multi-minute evaluation window, so drift is visible hours before it can cause stop-writes. * Add a direct NTP-synchronization health alert \(time-daemon offset, stratum, last-sync-age\) on every host in the affected tier, independent of the cluster skew metric. **Mitigate** — limit blast radius if the same cause recurs * Review whether the affected SDK endpoints can degrade more gracefully when the database is in stop-writes mode \(read-only path, cached fallback, queue-and-retry\), rather than returning immediate 5xx. 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-05-19 incident.

Read the full incident report →

Started May 13, 2026, 07:22 PM UTC· resolved May 13, 2026, 09:27 PM UTC

1. monitoring May 13, 2026, 09:22 PM UTC

   We have deployed a fix for an issue that prevented approximately 160 accounts from signing in to the dashboard. SDK and event processing have been operating normally throughout the incident — only dashboard sign-in for the affected accounts was impacted. We are now monitoring application logs to confirm the fix is fully resolving the issue, and will post another update shortly.

2. resolved May 13, 2026, 09:27 PM UTC

   Monitoring has confirmed that the errors are no longer occurring. All previously affected accounts are able to sign in to the dashboard normally. SDK and event processing were unaffected throughout the incident. Marking this incident as resolved. Thank you for your patience.

Read the full incident report →

Started May 11, 2026, 11:55 AM UTC· resolved May 11, 2026, 12:37 PM UTC

1. investigating May 11, 2026, 11:55 AM UTC

   We’re currently experiencing delays in event processing, which may affect third-party integrations, as well as transaction processing for Paddle and Stripe. No data has been lost, and all events will be delivered. We apologize for the inconvenience and appreciate your patience.

2. resolved May 11, 2026, 12:37 PM UTC

   Root cause has been identified and fix was deployed

Read the full incident report →

Started Apr 09, 2026, 02:57 PM UTC· resolved Apr 09, 2026, 03:01 PM UTC

1. identified Apr 09, 2026, 02:57 PM UTC

   We are currently experiencing issues with push notification delivery through our OneSignal integration. This is caused by an ongoing incident on OneSignal's side affecting their Dashboard/UI and API & SDK Endpoints. OneSignal has identified the root cause and is working towards a resolution. You can track their incident status at https://status.onesignal.com/

2. resolved Apr 09, 2026, 03:01 PM UTC

   The issue with push notification delivery via OneSignal has been resolved. Event processing is operating normally. The root cause was an outage on OneSignal's side affecting their Dashboard and API endpoints. which has now been fixed by their team. No action is required on your end. If you notice any remaining delays, please contact our support team.

Read the full incident report →

Started Mar 26, 2026, 10:01 AM UTC· resolved Mar 26, 2026, 10:01 AM UTC

1. resolved Mar 26, 2026, 10:01 AM UTC

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

Read the full incident report →

Started Mar 10, 2026, 10:30 AM UTC· resolved Mar 10, 2026, 10:36 AM UTC

1. identified Mar 10, 2026, 10:30 AM UTC

   Our data processing infrastructure is running behind which is causing inaccuracies in the reporting tools. No data has been lost and the system should be caught up shortly.

2. monitoring Mar 10, 2026, 10:33 AM UTC

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

3. resolved Mar 10, 2026, 10:36 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 05, 2026, 04:56 PM UTC· resolved Mar 05, 2026, 05:16 PM UTC

1. monitoring Mar 05, 2026, 04:56 PM UTC

   Since March 5 at 2:00 PM GMT, Facebook's API for handling mobile app events has been timing out. This is affecting their Ads Creation and Editing API; Meta has acknowledged the outage on their status page - https://metastatus.com/marketing-api . The good news: things are recovering. Successful requests are climbing back up, and all your events will come through — just a bit later than usual. We'll keep an eye on it. Thanks for your patience! — Adapty Infrastructure Team

2. resolved Mar 05, 2026, 05:16 PM UTC

   Events processing returned to normal.

Read the full incident report →

Started Feb 18, 2026, 12:30 AM UTC· resolved Feb 18, 2026, 12:55 AM UTC

1. investigating Feb 18, 2026, 12:30 AM UTC

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

2. identified Feb 18, 2026, 12:54 AM UTC

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

3. monitoring Feb 18, 2026, 12:54 AM UTC

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

4. resolved Feb 18, 2026, 12:55 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Feb 16, 2026, 02:30 AM UTC· resolved Feb 16, 2026, 02:45 PM UTC

1. resolved Feb 16, 2026, 03:07 PM UTC

   As a result of the release, Adapty’s subscription plan assignment was impacted. A small portion of customers could not receive their updated plan and also experienced issues accessing the Dashboard

Read the full incident report →

Started Feb 12, 2026, 05:59 AM UTC· resolved Feb 12, 2026, 06:55 AM UTC

1. investigating Feb 12, 2026, 05:59 AM UTC

   We are currently experiencing a partial service degradation affecting the Dashboard. Users may encounter intermittent latency or incomplete data rendering. Our engineering team is investigating the root cause and working towards a resolution.

2. resolved Feb 12, 2026, 06:55 AM UTC

   This incident has been resolved.

3. postmortem Feb 16, 2026, 01:50 PM UTC

   ## **Summary** Between 2026-02-11 14:30 and 2026-02-12 07:00 UTC we experienced intermittent Dashboard / SDK API degradation and delays in event delivery to integrations \(incl. custom webhook\). The incident was caused by an unintended network configuration change during planned maintenance, which led to unstable network interfaces on a subset of our infrastructure. ## **Timeline \(UTC\)** * 14:30 — network instability begins on a limited subset of infrastructure; * 15:10 — event sending latency begins increasing; * 16:20 — service instances in the affected area begin restarting; 5xx errors increase for part of Dashboard traffic; * 17:31 — peak impact: SDK downtime begins; we place temporary restrictions to stabilize the platform and reduce cascading failures; * 17:51 — SDK recovers; * 18:00 — event processing resumes, but with elevated delay; * 19:00 — Dashboard recovers; * 20:00 — event delivery returns to normal levels; * 20:40–22:10 — intermittent Dashboard degradation; * 05:30–06:30 — second wave: broad latency spike caused by a wider propagation of the same triggering change; * 06:40 — triggering change fully reverted; services stabilize. ## **Customer impact** Event delivery to integrations * 2026-02-11 15:10–17:31 UTC — events were delivered with ~5–10 min delay; * 2026-02-11 17:31–18:00 UTC — event delivery paused; * 2026-02-11 18:00–20:00 UTC — events were delivered with ~15–20 min delay, then returned to normal. Dashboard API * 2026-02-11 14:30–16:20 UTC — high latency for a portion of traffic; * 2026-02-11 16:20–17:31 UTC — elevated 5xx errors for a portion of traffic; * 2026-02-11 17:31–19:00 UTC — Dashboard was unavailable; * 2026-02-11 19:00–22:10 UTC — intermittent latency, then stabilized; * 2026-02-12 05:30–06:30 UTC — high latency affecting a larger share of traffic. SDK API * 2026-02-11 17:31–17:51 UTC — full downtime; * 2026-02-12 05:30–06:30 UTC — high latency. ## Root cause During planned maintenance, a DevOps engineer executed a bash script intended to add a host route and restart the network interface. The script contained a bug that caused it to run in an infinite loop, sequentially restarting network interfaces across nodes. These repeated interface restarts introduced intermittent network disruption and latency in communication between internal services. This had a particularly strong impact on our Postgres connection pool: * network restarts repeatedly dropped existing database connections, forcing the service to open new ones; * the old connections were not immediately removed on the Postgres side \(they had a 20-minute lifetime/timeout\); * as a result, dead/stale connections accumulated quickly and eventually exhausted the Postgres connection limit \(max\_connections\); * once the limit was reached, service could not open new connections, which caused errors and degraded availability.

Read the full incident report →

Started Feb 11, 2026, 04:29 PM UTC· resolved Feb 11, 2026, 07:57 PM UTC

1. identified Feb 11, 2026, 04:29 PM UTC

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

2. identified Feb 11, 2026, 05:34 PM UTC

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

3. identified Feb 11, 2026, 05:45 PM UTC

   SDK API affected and failing to handle majority of the requests

4. identified Feb 11, 2026, 05:46 PM UTC

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

5. monitoring Feb 11, 2026, 05:58 PM UTC

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

6. monitoring Feb 11, 2026, 05:58 PM UTC

   We are continuing to monitor for any further issues.

7. monitoring Feb 11, 2026, 07:10 PM UTC

   Both SDK and Dashboard API are back to normal. We're waiting for the event queue to empty.

8. resolved Feb 11, 2026, 07:57 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Feb 10, 2026, 09:07 AM UTC· resolved Feb 10, 2026, 11:47 AM UTC

1. investigating Feb 10, 2026, 09:07 AM UTC

   We are currently experiencing issues sending profile events exports to AWS S3 and Google Cloud. We expect to restore normal operation within the next two hours. After that, we will run all scheduled export jobs that were missed during the incident. This issue does not affect the normal operation of the service or data collection—only the delivery of exports is delayed.

2. resolved Feb 10, 2026, 11:47 AM UTC

   Profile events exports to AWS S3 and Google Cloud are back to normal, and all pending export jobs have been processed. All event exports have been delivered to customers.

Read the full incident report →

Started Feb 04, 2026, 12:14 PM UTC· resolved Feb 04, 2026, 02:13 PM UTC

1. investigating Feb 04, 2026, 12:14 PM UTC

   We are currently experiencing an issue with webhook delivery. Some webhook events are being delayed or not delivered as expected. As a result, customers may observe a reduced number of webhook events, including subscription and access level updates. This may impact subscription approvals and credit processing. Our engineering team is actively investigating the root cause and working to restore normal delivery.

2. monitoring Feb 04, 2026, 12:27 PM UTC

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

3. resolved Feb 04, 2026, 02:13 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jan 12, 2026, 06:20 AM UTC· resolved Jan 12, 2026, 07:00 AM UTC

1. resolved Jan 12, 2026, 11:12 AM UTC

   From 06:20 to 07:00 UTC, subscription purchase events WEB hooks haven't been sent to subscribers. During the next 3h, right after the incident ended, all delayed events were delivered successfully.

Read the full incident report →

Started Dec 24, 2025, 10:06 AM UTC· resolved Dec 24, 2025, 10:27 AM UTC

1. investigating Dec 24, 2025, 10:06 AM UTC

   We are currently investigating this issue.

2. monitoring Dec 24, 2025, 10:15 AM UTC

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

3. resolved Dec 24, 2025, 10:27 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Dec 03, 2025, 09:20 PM UTC· resolved Dec 03, 2025, 09:49 PM UTC

1. investigating Dec 03, 2025, 09:20 PM UTC

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

2. investigating Dec 03, 2025, 09:37 PM UTC

   We are currently seeing elevated errors and degraded performance for requests routed through Cloudflare in the UK region. Our team is investigating the issue. Cloudflare has acknowledged related network problems on their status page, and we are monitoring their updates while continuing to assess the impact on our services.

3. resolved Dec 03, 2025, 09:49 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Nov 06, 2025, 12:05 PM UTC· resolved Nov 06, 2025, 03:09 PM UTC

1. resolved Nov 07, 2025, 04:03 PM UTC

   From 12:05 UTC to 15:09 UTC on November 6, Adapty experienced intermittent network issues that resulted in approximately 7% of requests being retried. Unfortunately, this event was not automatically surfaced by our internal monitoring, and our external monitoring did not trigger an alert because it only reports after two consecutive failures. As a result, we did not notify customers in a timely manner. The underlying issue has been mitigated, and systems are operating normally. We are currently implementing an additional monitoring layer to collect status codes directly from the CDN providers we use, ensuring faster and more accurate detection in the future. We’re sorry for the disruption and for not alerting you sooner. We are taking steps to ensure better visibility and responsiveness going forward.

Read the full incident report →