Sauce Labs Outage History

Started Mar 10, 2026, 06:46 PM UTC· resolved Mar 10, 2026, 11:34 PM UTC

1. investigating Mar 10, 2026, 06:46 PM UTC

   We are experiencing device unavailability in the US West 1, EU Central 1, and US East 4 data centers and have found that the issue is caused by a 3rd party service disruption. We are investigating.

2. resolved Mar 10, 2026, 11:34 PM UTC

   This incident has been resolved.

3. postmortem Apr 09, 2026, 09:07 PM UTC

   ### **Dates:** Tuesday March 10th 2026, 17:52 - 23:34 UTC ### **What happened:** The majority of iOS devices across all regions became unavailable. ### **Why it happened:** Apple's [ppq.apple.com](http://ppq.apple.com) app verification endpoint was down, causing internal device monitoring checks to fail, bringing devices offline. ### **How we fixed it:** We temporarily disabled these device monitoring checks. ### **What we are doing to prevent it from happening again:** Improved external monitoring to catch outages of apple’s [ppq.apple.com](http://ppq.apple.com) endpoint, loosened device monitoring to not take down live iOS devices if [ppq.apple.com](http://ppq.apple.com) is down.

Read the full incident report →

Started Mar 06, 2026, 09:38 PM UTC· resolved Mar 06, 2026, 11:11 PM UTC

1. resolved Mar 06, 2026, 11:28 PM UTC

   Between 21:38 UTC and 23:11 UTC, our virtual iOS and MacOS live and automated device tests were failing to start in the EU Data Center. We executed a deployment rollback, which restored services. All systems are now fully operational.

2. postmortem Apr 10, 2026, 10:53 PM UTC

   ### **Dates:** Friday, March 6th 2026, 21:38 UTC - 23:11 UTC ### **What happened:** During the incident timeline, customers running virtual iOS simulator tests on ARM or macOS ARM desktop tests in the EU Data Center were unable to start new sessions for either live or automated. ### **Why it happened:** There was a sequencing issue on the release of the ARM side disk images in the EU. ### **How we fixed it:** The image reference for the ARM side disk was rolled back to the previous reference to restore service. ### **What we are doing to prevent it from happening again:** The tests that run to validate the image syncing have been completed in each region.

Read the full incident report →

Started Feb 27, 2026, 06:42 PM UTC· resolved Feb 27, 2026, 08:15 PM UTC

1. investigating Feb 27, 2026, 06:42 PM UTC

   Live and automated real device test results are not being displayed on the test results page in the US-West-1 data center. We are investigating.

2. resolved Feb 27, 2026, 08:15 PM UTC

   After taking remedial action, we are now seeing real device test results display in the US-West-1 data center. All services are fully operational.

3. postmortem Apr 15, 2026, 07:06 PM UTC

   ### **Dates:** Friday, February 27th 2026, 16:15 UTC - 19:50 UTC ### **What happened:** Requests made using API client authentication would return 500 errors. ### **Why it happened:** An internal data structure became corrupted due to a race condition. ### **How we fixed it:** The affected service was restarted, and a long-term fix was applied. ### **What we are doing to prevent it from happening again:** Thread locking has been applied to the affected service.

Read the full incident report →

Started Feb 23, 2026, 05:22 PM UTC· resolved Feb 23, 2026, 10:31 PM UTC

1. investigating Feb 23, 2026, 05:22 PM UTC

   We are seeing an increase in automated tests using Sauce Connect failing with “Misconfigured -- No active tunnel found for provided identifier” errors in the US-West-1 data center. We are actively investigating.

2. investigating Feb 23, 2026, 07:40 PM UTC

   We have identified the root cause and are working on implementing a fix. We are continuing to investigate.

3. resolved Feb 23, 2026, 10:31 PM UTC

   We have identified the root cause and deployed a fix for this issue. All services are fully operational.

4. postmortem Apr 15, 2026, 06:58 PM UTC

   ### **Dates:** Monday, February 23rd 2026, 17:22 UTC - 22:31 UTC ### **What happened:** WDIO-based tests run by customers using Sauce Connect 4 could not be started. ### **Why it happened:** Misconfiguration caused failing health checks in some cases, causing customer tunnels to shut down. ### **How we fixed it:** Misconfiguration was corrected. ### **What we are doing to prevent it from happening again:** Evaluation of the underlying software stack. Customers who are still using SC4 that can migrate to SC5 should do so at their earliest convenience.

Read the full incident report →

Started Jan 29, 2026, 05:30 PM UTC· resolved Jan 29, 2026, 09:45 PM UTC

1. resolved Jan 30, 2026, 12:51 AM UTC

   Application uploads and automated tests on our virtual and real device platforms in the US West Datacenter experienced intermittent errors today between 5:43 pm (UTC) and 9:45 pm (UTC). These issues were caused by an underlying infrastructure error within our storage services. We took remedial action to stabilize the environment, and the problem has been resolved.

2. postmortem Mar 06, 2026, 01:44 PM UTC

   ### **Dates:** Thursday, January 29th 2026, 19:30 UTC - 22:25 UTC. ### **What happened:** Application uploads and automated tests in the US-West-1 data center experienced intermittent errors between 5:43 pm \(UTC\) and 9:45 pm \(UTC\) ### **Why it happened:** Due to a high number of concurrent uploads and a temporary change to the network topology schema, the App Storage Service experienced increased connection latency and delays in acquiring connections to the backend. ### **How we fixed it:** App Storage Service network topology schema was restored to its original state. ### **What we are doing to prevent it from happening again:** We are improving monitoring, alerting and validations for the App Storage Service backend connectivity. We are working to implement processes to handle periods of increased load and proactively detect performance degradation to implement automated remediation and self-healing capabilities.

Read the full incident report →

Started Jan 29, 2026, 07:04 AM UTC· resolved Jan 29, 2026, 08:46 AM UTC

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

   Between 8:00 CET - 9:45 CET, We were seeing elevated error rates and intermittent issues with test assets not being retained for tests on iOS and Mac virtual devices in our US-West-1 data center. The issue has now been resolved but some customers might see missing test assets.

2. postmortem Feb 03, 2026, 02:01 PM UTC

   ### **Dates:** Thursday, January 29th 2026, 07:04 - 08:46 UTC. ### **What happened:** Between 07:04 UTC and 08:46 UTC on January 29, 2026, customers using our US-West-1 region experienced instability with Mac resources. Specifically: * Approximately 20% of iOS simulator jobs failed to start due to infrastructure errors. * 10% of Virtual MacOS/iOS jobs failed to upload assets to S3. As a result, logs, videos, and screenshots for these specific jobs were lost and remain unavailable for download. ### **Why it happened:** Scheduled maintenance on a primary network circuit coincided with high traffic volume, which led to congestion on the backup circuit. ### **How we fixed it:** Full connectivity was restored when traffic was routed back to the primary circuit following the completion of maintenance. ### **What we are doing to prevent it from happening again:** Review network redundancy strategies and consider upgrading backup circuit capacity to ensure it can support peak traffic loads.

Read the full incident report →

Started Jan 13, 2026, 10:43 AM UTC· resolved Jan 13, 2026, 10:50 AM UTC

1. investigating Jan 13, 2026, 10:43 AM UTC

   We are currently experiencing issues with our app storage service in the US-West-1 Data Center. We are investigating the issue.

2. resolved Jan 13, 2026, 10:50 AM UTC

   After taking remedial action, the app storage service has been restored in the US-West-1 Data Center. All services are fully operational.

3. postmortem Feb 03, 2026, 01:56 PM UTC

   ### **Dates:** Tuesday, January 13th 2025, 9:10 UTC - 10:37 UTC. ### **What happened:** The App Storage Service experienced high response times in the US-West-1 datacenter. ### **Why it happened:** Due to a high number of concurrent uploads, the App Storage Service experienced increased connection latency and delays in acquiring connections to the backend. ### **How we fixed it:** Service was restored by restarting the application. ### **What we are doing to prevent it from happening again:** We are improving monitoring, alerting and validations for the App Storage Service to backend connectivity. We are also evaluating how to handle periods of increased load and proactively detect performance degradation to implement automated remediation and self-healing capabilities.

Read the full incident report →

Started Jan 05, 2026, 09:15 PM UTC· resolved Jan 05, 2026, 10:24 PM UTC

1. monitoring Jan 05, 2026, 09:15 PM UTC

   We have been experiencing device unavailability in our private device cloud in the US data center and have identified the root cause. We have deployed a fix and we are monitoring.

2. resolved Jan 05, 2026, 10:24 PM UTC

   We were experiencing device unavailability in our private device cloud in the US data center and we have deployed a fix. This issue has been resolved. All services are fully operational.

3. postmortem Feb 20, 2026, 11:03 AM UTC

   ### **Dates:** Monday, January 5th 2026, 20:40 UTC - 21:04 UTC. ### **What happened:** There was a decrease in Real Device availability in the US-West-1 datacenter. ### **Why it happened:** During a planned traffic flow migration, a network policy applied to the new traffic path was more restrictive than intended and this resulted in a subset of Real Devices \(~40%\) failing to maintain required connectivity. Although the change followed standard change management and peer review processes, the issue was not identified prior to activation. ### **How we fixed it:** The network policy was corrected and affected services recovered. ### **What we are doing to prevent it from happening again:** We are reviewing our network change processes to provide earlier detection of unintended behaviour during planned changes.

Read the full incident report →

Started Dec 18, 2025, 05:30 AM UTC· resolved Dec 18, 2025, 07:09 AM UTC

1. resolved Dec 18, 2025, 08:16 AM UTC

   Between 5:40 UTC and 7:20 UTC, we experienced a high job error rate of all tests (Manual and Automated, Real Devices and Virtual Devices) in the US-West-1 data center. This issue has been resolved. All services are fully operational.

2. postmortem Feb 20, 2026, 10:15 AM UTC

   ### **Dates:** Thursday, December 18th 2025, 5:32 UTC - 7:09 UTC. ### **What happened:** The App Storage Service experienced high response times in the US-West-1 datacenter. ### **Why it happened:** Due to a high number of concurrent uploads, the App Storage Service experienced increased connection latency and delays in acquiring connections to the backend. ### **How we fixed it:** The service was restored by restarting the application. ### **What we are doing to prevent it from happening again:** We are implementing improved monitoring, alerting and validations for App Storage Service backend connectivity. We will also look to enhance processes to handle periods of increased load and detect performance degradation proactively, in order to implement automated remediation and self-healing capabilities.

Read the full incident report →

Started Dec 17, 2025, 10:30 AM UTC· resolved Dec 17, 2025, 11:59 AM UTC

1. resolved Dec 18, 2025, 03:52 PM UTC

   Between 10:37 UTC December 17th and 11:59 UTC December 18th, we were experiencing issues downloading applications via Mobile App Distribution. This issue has been resolved. All services are fully operational.

2. postmortem Jan 05, 2026, 04:04 PM UTC

   ### **When it happened:** Wednesday, December 17th 2025, 10:37 UTC - Thursday, December 18th 2025, 11:59 UTC ### **What happened:** Applications were unable to be downloaded via Mobile App Distribution for a subset of customers. ### **Why it happened:** A product change combined with an increased and sustained load resulted in higher resource usage than anticipated, exceeding established limits for certain clients. ### **How we fixed it:** The service was rolled back to a stable version. ### **What we are doing to prevent it from happening again:** There are multiple improvements planned. 1. Improved monitoring & alerting, 2. Enhanced post-deployment validation 3. Capacity planning forecasting 4. More advanced communication where possible ahead of major changes 5. Adding canary to the roll out process

Read the full incident report →

Started Nov 19, 2025, 06:54 PM UTC· resolved Nov 19, 2025, 10:17 PM UTC

1. investigating Nov 19, 2025, 06:54 PM UTC

   We are currently receiving reports indicating that customers are unable to log in to App Distribution using Single Sign-On (SSO). Our team is actively investigating the root cause and working toward a resolution.

2. identified Nov 19, 2025, 07:36 PM UTC

   We identified the root cause and are now working to restore the service.

3. resolved Nov 19, 2025, 10:17 PM UTC

   Earlier today, customers were unable to log in to App Distribution via SSO. After taking remedial action, users are now able to login successfully. This incident is resolved.

4. postmortem Jan 05, 2026, 05:25 PM UTC

   ### **Dates:** Wednesday, November 19th 2025, 09:00 UTC – Thursday, November 20th 2025, 21:00 UTC ### **What happened:** Following a scheduled maintenance deployment, a subset of customers utilising Single Sign-On \(SSO\) were unable to log in to the platform. While the application remained up and running, authentication requests for these specific accounts were rejected, preventing access to the application. ### **Why it happened:** A major backend infrastructure upgrade aimed at improving performance and security, inadvertently caused the incident. The new authentication system's default settings were incompatible with existing customer SSO configurations, leading to valid login attempts being incorrectly rejected. ### **How we fixed it:** To restore immediate access, we reverted the authentication processing logic to its previous state, ensuring full compatibility with all existing customer configurations. ### **What we are doing to prevent it from happening again:** We are adding enhanced monitoring for authentication success rates and updating pre-deployment testing to cover more legacy SSO configurations for seamless compatibility.

Read the full incident report →

Started Nov 04, 2025, 08:02 AM UTC· resolved Nov 04, 2025, 11:10 AM UTC

1. investigating Nov 04, 2025, 08:02 AM UTC

   We are currently seeing issues accessing the Sauce Home, Insights, Test Results, API in EU-Central-1. We are investigating.

2. resolved Nov 04, 2025, 11:10 AM UTC

   The access to Sauce Labs Home, Test Results, Insights, API has been restored. All services are fully operational.

3. postmortem Jan 06, 2026, 02:40 PM UTC

   ### **Dates:** Monday November 4 2025, 04:35 UTC - 08:20 UTC. ### **What happened:** The web UI for Insights and Test Results was intermittently unresponsive. ### **Why it happened:** A data store of components of the UI experienced unexpectedly high load, resulting in an unresponsive service. ### **How we fixed it:** The issue was resolved without human intervention. ### **What we are doing to prevent it from happening again:** We have improved support for the 3rd party vendor's logging and metrics tools.

Read the full incident report →

Started Nov 03, 2025, 12:40 PM UTC· resolved Nov 03, 2025, 02:25 PM UTC

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

   Access to test results was interrupted in our EU Data Center from 12:40 UTC to 14:25 UTC. The issue has been identified and resolved.

2. postmortem Dec 11, 2025, 05:16 PM UTC

   ### **Dates:** Monday November 3 2025, 12:40 UTC - 14:25 UTC. ### **What happened:** The Sauce Labs dashboard for Insights and Test Results was unresponsive, causing issues showing test results and related information. ### **Why it happened:** A data store for some components of the dashboard experienced unusually high load, resulting in an unresponsive service. ### **How we fixed it:** The issue was resolved by increasing the resources for the affected data store service. ### **What we are doing to prevent it from happening again:** Support for the 3rd party vendor's logging and metrics tools has been improved.

Read the full incident report →

Started Oct 29, 2025, 09:27 AM UTC· resolved Oct 29, 2025, 10:47 AM UTC

1. investigating Oct 29, 2025, 09:27 AM UTC

   We are currently experiencing issues with live test execution on Real Devices for IOS and Android in the US-West-1 datacenter. We are investigating.

2. resolved Oct 29, 2025, 10:47 AM UTC

   After taking remedial action, live tests on Real Devices are now running normally in the US-West-1 Data Center. All services are fully operational.

3. postmortem Dec 11, 2025, 04:51 PM UTC

   ### **Dates:** Monday, October 27th 2025, 15:27 UTC - Wednesday, October 29th 2025, 11:34 UTC. ### **What happened:** Real Device Live Testing availability gradually decreased in the US-West-1 data center. ### **Why it happened:** A product defect was introduced which caused Live Testing sessions on Real Devices to fail to start. ### **How we fixed it:** We performed a rollback to the previous working release. ### **What we are doing to prevent it from happening again:** We have improved monitoring & alerting and enhanced our post-deployment validation processes.

Read the full incident report →

Started Oct 28, 2025, 02:07 PM UTC· resolved Oct 28, 2025, 04:13 PM UTC

1. resolved Oct 28, 2025, 04:13 PM UTC

   Between 14:07 UTC and 15:25 UTC, we experienced a high error rate for automated and manual Real Device tests in the US-West, US-East, and EU data centers. This issue has been resolved. All services are fully operational.

2. postmortem Dec 11, 2025, 04:24 PM UTC

   ### **Dates:** Tuesday, October 28th 2025, 14:03 UTC - 15:18 UTC \(primary incident\) Tuesday, October 28th 2025, 15:18 UTC - Thursday, October 30th 2025, 8:25 UTC \(~1% of devices impacted window\) ### **What happened:** Test executions using the 'stable' Appium version gradually decreased in the US-West-1, US-East-4, and EU-Central-1 data centers. ### **Why it happened:** A product defect was introduced which caused tests using the stable Appium version to fail immediately upon creation. ### **How we fixed it:** We preformed a rollback to a previous version on the majority of devices on Tuesday, October 28th 2025, 15:18 UTC, With a full service restoration across all devices completed on Thursday, October 30th 2025, 8:25 UTC. ### **What we are doing to prevent it from happening again:** We have improved monitoring & alerting and enhanced our post-deployment validation processes.

Read the full incident report →

Started Oct 28, 2025, 12:53 PM UTC· resolved Oct 28, 2025, 02:22 PM UTC

1. investigating Oct 28, 2025, 12:53 PM UTC

   We are currently seeing elevated error rates for browser tests running on Windows 8 & 10 in the EU-Central-1, we are currently investigating.

2. resolved Oct 28, 2025, 02:22 PM UTC

   After taking remedial action, Windows browser tests are now running normally, this incident is resolved.

3. postmortem Nov 06, 2025, 04:00 PM UTC

   ### **Dates:** Tuesday, October 28th 2025, 11:40 UTC - 14:05 UTC. ### **What happened:** Windows based tests in the EU data center were failing on startup which led to a decrease in availability of Windows-based Virtual Machines. ### **Why it happened:** A product defect was introduced which caused an issue with starting Windows-based VMs. ### **How we fixed it:** The deployment was rolled back to a stable version. ### **What we are doing to prevent it from happening again:** We have improved monitoring & alerting and enhanced our post-deployment validation.

Read the full incident report →

Started Oct 28, 2025, 10:28 AM UTC· resolved Oct 28, 2025, 11:34 AM UTC

1. resolved Oct 28, 2025, 05:20 PM UTC

   Between 11:20 UTC and 12:10 UTC, we experienced a high error rate of virtual Android tests in the US-West-1 data center. This issue has been resolved. All services are fully operational.

2. postmortem Dec 11, 2025, 04:33 PM UTC

   ### **Dates:** Thursday, October 9th 2025, 10:28 UTC - Tuesday, November 11th 2025, 11:34 UTC. ### **What happened:** Virtual Android testing availability gradually decreased in the US-West-1 data center, this led to increased error rates in starting sessions, The error rates remained high between November 4th and November 11th. ### **Why it happened:** An increased and sustained load on our service led to reduced availability of Android virtual VMs, increasing wait times to start sessions, which in turn led to an elevated number of failed sessions. ### **How we fixed it:** This was resolved by increasing infrastructure capacity and optimizing resource utilization. ### **What we are doing to prevent it from happening again:** We have improved monitoring & alerting, enhanced post-deployment validation and improved capacity planning.

Read the full incident report →

Started Oct 01, 2025, 01:00 AM UTC· resolved Oct 01, 2025, 10:22 PM UTC

1. resolved Oct 07, 2025, 08:19 AM UTC

   Between 13:54 UTC on October 1, 2025, and 10:22 UTC on October 2, 2025, some automated Android Emulator tests failed intermittently in our US West and EU Central data centers. This was caused by a screen resolution change. We fixed the issue and all services are now fully operational.

2. postmortem Dec 11, 2025, 04:16 PM UTC

   ### **Dates:** Wednesday, October 1st 2025, 10:34 UTC - Thursday, October 2nd 2025, 22:22 UTC ### **What happened:** Virtual Android and Visual tests using the “Android GoogleAPI Emulator” were failing if they contained conditioned that required the exact app dimensions. ### **Why it happened:** A new default emulator was released including a setting that did not account for customer defined virtual screen resolutions. ### **How we fixed it:** The issue was resolved by rolling back the deployment. ### **What we are doing to prevent it from happening again:** A new release was scheduled with an update to accommodate tests with customer defined screen resolution.

Read the full incident report →

Started Sep 19, 2025, 05:30 AM UTC· resolved Sep 19, 2025, 08:35 AM UTC

1. resolved Sep 19, 2025, 08:54 AM UTC

   Between 06:30 and 08:35 UTC we were seeing errors when selecting and starting Live and Automated Android Emulator tests in US-West-1 & EU-Central-1 Data Centers. This has now been resolved.

Read the full incident report →

Started Sep 03, 2025, 04:34 PM UTC· resolved Sep 03, 2025, 05:10 PM UTC

1. investigating Sep 03, 2025, 04:34 PM UTC

   We are currently seeing app storage upload issues in the EU datacenter. We are investigating.

2. resolved Sep 03, 2025, 05:10 PM UTC

   After taking remedial action, the app storage service has been restored in the EU Data Center. All services are fully operational.

3. postmortem Dec 11, 2025, 04:00 PM UTC

   ### **Dates:** Wednesday September 5th 2025, 13:50 UTC - 16:31 UTC ### **What happened:** The App Storage Service in the EU Central 1 data center experienced elevated response times, leading to timeout errors with uploading applications. ### **Why it happened:** The App Storage Service experienced connection issues with the backend. ### **How we fixed it:** The connection issues were resolved by restarting the affected application. ### **What we are doing to prevent it from happening again:** We have improved observability signals for the App Storage Service and implemented regular scheduled restarts of the application.

Read the full incident report →

Started Aug 19, 2025, 04:20 PM UTC· resolved Aug 19, 2025, 04:55 PM UTC

1. resolved Aug 19, 2025, 07:15 PM UTC

   Between 16:15 -16:55 UTC, automated Android Real Device tests were intermittently failing to start in our US West Data Center. We took remedial action and the problem was resolved. All services are fully operational.

2. postmortem Sep 10, 2025, 02:45 PM UTC

   ### **Dates:** Friday August 19th 2025, 16:20 UTC - 16:55 UTC. ### **What happened:** During the times stated, automated Android real device tests were failing to start intermittently in the US-West-1 datacenter. ### **Why it happened:** A defect was introduced by a deployment which impacted Appium tests. ### **How we fixed it:** The deployment was rolled back. ### **What we are doing to prevent it from happening again:** We have improved our internal test cases to detect the conditions in which the defect occurred.

Read the full incident report →

Started Jul 22, 2025, 08:50 AM UTC· resolved Jul 22, 2025, 01:19 PM UTC

1. investigating Jul 22, 2025, 08:50 AM UTC

   We are currently seeing intermittent errors accessing the US-West-1 Sauce Labs dashboard. We are investigating.

2. investigating Jul 22, 2025, 09:53 AM UTC

   We are continuing to investigate this issue.

3. monitoring Jul 22, 2025, 12:07 PM UTC

   We have been seeing intermittent errors accessing the US-West-1 Sauce Labs dashboard. We have identified a solution and have deployed a fix for this issue. We are monitoring.

4. resolved Jul 22, 2025, 01:19 PM UTC

   After taking remedial action, the Sauce Labs dashboard is now stable and available. This incident is resolved.

5. postmortem Aug 20, 2025, 10:02 AM UTC

   ### **Dates:** Tuesday July 22d 2025, 07:28 UTC - 15:07 UTC. ### **What happened:** The Sauce Labs dashboard for our US-West-1 datacenter was unavailable intermittently during the incident timeline. ### **Why it happened:** This issue was caused by Cache poisoning via a specific header. ### **How we fixed it:** The header settings were reviewed and fixed in our proxies. ### **What we are doing to prevent it from happening again:** We have added stricter rules to prevent further cache poisoning attempts.

Read the full incident report →

Started Jul 02, 2025, 10:11 AM UTC· resolved Jul 02, 2025, 08:11 PM UTC

1. investigating Jul 02, 2025, 10:11 AM UTC

   We are currently experiencing reduced availability of Real Devices in our EU-Central-1 datacenter. We are investigating.

2. investigating Jul 02, 2025, 11:12 AM UTC

   We are continuing to see reduced availability of Real Devices in our EU-Central-1 datacenter. We are continuing to investigate.

3. investigating Jul 02, 2025, 11:50 AM UTC

   We have identified a networking issue in the EU-Central-1 datacenter, resulting in a high error rate in EU Real Device tests. We are continuing to investigate.

4. investigating Jul 02, 2025, 04:19 PM UTC

   We are actively working on a solution to resolve the networking issues being seen in the EU datacenter, which involves replacing failed hardware. A high error rate will continue to be seen with EU Real Device tests in the meantime.

5. resolved Jul 02, 2025, 08:11 PM UTC

   Our Android devices are now fully operational in EU-Central Data Center. We are currently experiencing a slight reduction in available public and private iOS devices in the EU-Central Data Center, which is leading to degraded availability for our iOS user base. We have identified the root cause and implementing a final fix. We expect to restore full availability for all iOS users by tomorrow, Thursday, July 3, 2025, end of day

6. postmortem Jul 16, 2025, 10:45 AM UTC

   ### **Dates:** Wednesday July 2nd 2025, 09:74 UTC - 17:19 UTC. ### **What happened:** Approximately half of our real devices in the EU-Central-1 datacenter became unavailable for testing. ### **Why it happened:** There was a critical failure with a device within our network infrastructure. ### **How we fixed it:** The issue was resolved by replacing the failed device. ### **What we are doing to prevent it from happening again:** We are reviewing the current network infrastructure strategy to improve resiliency.

Read the full incident report →

Started Jun 18, 2025, 11:53 AM UTC· resolved Jun 18, 2025, 12:54 PM UTC

1. investigating Jun 18, 2025, 11:53 AM UTC

   We are currently experiencing issues with our app storage service in the EU Data Center. We are investigating.

2. resolved Jun 18, 2025, 12:54 PM UTC

   After taking remedial action, the app storage service has been restored in the EU Data Center. All services are fully operational.

3. postmortem Jul 07, 2025, 08:56 AM UTC

   ### **Dates:** Wednesday June 18th 2025, 11:04 UTC - 12:23 UTC ### **What happened:** The service responsible for App storage and retrieval experienced long response times. ### **Why it happened:** The App storage service was experiencing connectivity issues. ### **How we fixed it:** The connectivity issues disappeared before any remediation actions could be taken.. ### **What we are doing to prevent it from happening again:** We have added tracing validations for the app storage service connectivity to give earlier visibility of any future occurrences.

Read the full incident report →

Started Jun 16, 2025, 12:49 PM UTC· resolved Jun 16, 2025, 01:29 PM UTC

1. investigating Jun 16, 2025, 12:49 PM UTC

   We are currently experiencing reduced availability of Real Devices in our EU-Central-1 datacenter. We are investigating.

2. resolved Jun 16, 2025, 01:29 PM UTC

   After taking remedial action, we are seeing normal availability levels of Real Devices in our EU-Central-1 datacenter. This incident is resolved.

3. postmortem Jun 20, 2025, 08:17 AM UTC

   ### **Dates:** Monday June 16th 2025, 12:25 UTC - 13:20 UTC ### **What happened:** Approximately 50% of RDC devices in the EU-Central-1 datacenter were unavailable. ### **Why it happened:** Maintenance on the datacenter power supply led to devices being shut down. ### **How we fixed it:** The affected devices were restarted. ### **What we are doing to prevent it from happening again:** We are looking to add more power redundancy and create established maintenance windows.

Read the full incident report →