Störungsverlauf von Sauce Labs

1. 2. September 2026 um 09:39 UTCinvestigating

   Wir sehen erhöhte Fehlerquoten für Real Device Tests im Rechenzentrum EU-Central-1. Wir untersuchen.

2. 2. September 2026 um 11:30 UTCidentified

   Die Ursache für die erhöhten Fehlerraten bei Real Device Tests im Rechenzentrum EU-Central-1 wurde identifiziert. Es wurde Abhilfe geschaffen, und wir beobachten die Situation aktiv.

3. 2. September 2026 um 11:53 UTCresolved

   Nach Abhilfemaßnahmen haben sich die Testfehlerraten von Real Device im Rechenzentrum EU-Central-1 wieder normalisiert. Alle Dienste sind voll funktionsfähig.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 25. August 2026 um 12:33 UTCinvestigating

   Wir sehen derzeit erhöhte Fehlerraten für macOS- und iOS-Tests im US-West-1-Rechenzentrum. Wir untersuchen derzeit.

2. 25. August 2026 um 13:19 UTCresolved

   Nachdem alle macOS- und iOS-Tests nun wie erwartet im US-West-1-Rechenzentrum durchgeführt wurden. Alle Dienste sind voll funktionsfähig.

3. 3. September 2026 um 20:23 UTCpostmortem

   ### **Datum:** Dienstag, 25. August 2026, 11:38 – 13:10 UTC ### **Was passiert ist:** Kunden, die macOS- und iOS-Tests in unserer Region USA-West durchführen, erlebten einen eingeschränkten Service. Etwa 50% der virtuellen Mac-Kapazität in der Region haben die Annahme neuer Tests eingestellt, so dass die Tests entweder in die Warteschlange gestellt wurden oder nicht gestartet wurden. Die verbleibende Kapazität geriet unter zusätzlichen Druck, da sich die Arbeit darauf verlagerte, was die Startzeiten für Desktop- und Simulatortests verlängerte. ### **Warum es passiert ist:** Ein internes Sicherheitszertifikat, das von unseren Mac-Hosts verwendet wird, um einen unterstützenden Cloud-Dienst zu erreichen, hat sein Ablaufdatum erreicht. Sobald es abgelaufen war, konnten die Hosts keine vertrauenswürdige Verbindung mehr zu diesem Dienst herstellen und stellten die Bereitstellung neuer Testmaschinen ein. Die Bescheinigung war manuell ausgestellt worden und hatte weder eine automatisierte Verlängerung noch eine Ablaufwarnung. ### **Wie wir es repariert haben:** Wir haben ein Ersatzzertifikat ausgestellt und bereitgestellt, mit dem die Konnektivität wiederhergestellt und die Mac-Kapazität auf ein normales Niveau gebracht wurde. ### **Was wir tun, um zu verhindern, dass es wieder passiert: ** Wir verschieben diese Zertifikate auf die automatisierte Erneuerung und fügen Alarmierung hinzu, so dass sie weit vor dem Ablauf ersetzt werden, zusammen mit der Überprüfung der umgebenden Werkzeuge, um die Zertifikatsbehandlung sicherer zu machen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 7. August 2026 um 12:08 UTCinvestigating

   Wir sehen derzeit erhöhte Fehlerraten für virtuelle Desktop-Tests im US-West-1-Rechenzentrum. Wir untersuchen derzeit.

2. 7. August 2026 um 13:06 UTCresolved

   After taking remedial action, Virtual Desktop tests are starting successfully in the US-West-1 Data center. All services are fully operational. We are closely monitoring the situation

3. 14. August 2026 um 16:43 UTCpostmortem

   ### **Dates:** Friday, August 7th 2026, 11:00 UTC - 13:04 UTC. ### **What happened:** Windows and Intel Mac jobs in `us-west1` failed to start due to virtual machine \(VM\) allocation starvation. ### **Why it happened:** A service crash loop left VMs in an allocated but unclaimed state, while a cleanup bug prevented the system from releasing the orphaned capacity to boot new VMs. ### **How we fixed it:** Restored service stability and cleared stale allocations to resume VM provisioning and clear queued jobs. ### **What we are doing to prevent it from happening again:** Fixing allocator cleanup logic, strengthening deployment health checks, and improving capacity accounting for stale allocations.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. Juli 2026 um 20:33 UTCresolved

   Zwischen dem 16. Juli 13:03 UTC und dem 16. Juli 17:33 UTC erlebten wir eine Serviceunterbrechung, bei der Symbolarchive, die mehrteilige Upload-Protokolle verwendeten, nicht verarbeitet wurden. Der Vorfall wurde behoben und alle Dienste sind in Betrieb.

2. 14. August 2026 um 16:48 UTCpostmortem

   ### **Dates:** Thursday July 16th 2026, 13:03 – 17:33 UTC ### **What happened:** Symbol archives uploaded in multiple parts failed to process. All regions were affected. ### **Why it happened:** Our symbol processing service sent an upload-verification field that our cloud storage provider's API does not accept for multi-part uploads, so those uploads were rejected. A fix for this had already been developed, but it had not yet been included in a released build and the service was not configured to use it. As in the first incident, rejected uploads were retried and accumulated on local disk. ### **How we fixed it:** We deployed a build containing the fix and corrected the service configuration on the affected workers. A large backlog of uploads then processed, which briefly re-filled the disks before draining completely. ### **What we are doing to prevent it from happening again:** We are releasing the fix formally through our build pipeline and persisting the corrected configuration in our configuration management, so it can't be lost. The disk-utilization alerting added after the first incident also covers the disk-exhaustion pattern common to both.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. Juli 2026 um 20:30 UTCresolved

   Zwischen dem 14. Juli 23:45 UTC und dem 15. Juli 23:05 UTC gab es ein Problem, bei dem Symbolarchiv-Uploads in Backtrace-Projekte mit HTTP 400-Fehlern fehlschlugen. Der Vorfall wurde behoben und alle Dienste sind in Betrieb.

2. 14. August 2026 um 16:47 UTCpostmortem

   ### **Dates:** Tuesday July 14th 2026, 23:45 UTC – Wednesday July 15th 2026, 23:05 UTC ### **What happened:** Symbol archive uploads to Error Reporting \(Backtrace\) projects failed with HTTP 400 errors. All regions were affected. ### **Why it happened:** The credentials our symbol processing service used to write to cloud storage were no longer valid, so uploads could not be stored. Failed uploads were retried repeatedly and accumulated on local disk until the service ran out of space, at which point it also began rejecting new uploads. ### **How we fixed it:** We reissued the storage credentials, increased disk capacity on the affected workers, and restarted the service. The queued uploads then processed successfully, and we confirmed recovery with affected customers. ### **What we are doing to prevent it from happening again:** We've added disk-utilization monitoring and alerting to this service so we detect the condition ourselves before it affects uploads, rather than relying on customer reports.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 14. Juli 2026 um 17:19 UTCinvestigating

   Wir haben ein Problem im EU Central 1 Rechenzentrum, wo iOS ARM Simulator App Tests mit Infrastrukturfehlern fehlschlagen. Wir untersuchen.

2. 14. Juli 2026 um 18:05 UTCinvestigating

   App-Downloads dauern länger als erwartet, wenn diese Infrastrukturfehler auftreten. Wir untersuchen weiter.

3. 14. Juli 2026 um 18:56 UTCmonitoring

   Wir haben für dieses Problem eine Lösung gefunden. Die Tests sollten nun wie erwartet im EU Central 1 Rechenzentrum durchgeführt werden. Wir beobachten.

4. 14. Juli 2026 um 19:11 UTCmonitoring

   Wir werden weiterhin auf weitere Probleme achten.

5. 14. Juli 2026 um 20:23 UTCresolved

   Nachdem wir Abhilfemaßnahmen ergriffen und die Situation überwacht haben, sehen wir, dass iOS ARM-Anwendungstests wie erwartet im EU Data Center durchgeführt werden. Alle Dienste sind voll funktionsfähig.

6. 29. Juli 2026 um 17:40 UTCpostmortem

   ### **Datum:** Dienstag, 14. Juli 2026, 09:00 - 18:28 UTC ### **Was passiert ist:** iOS ARM-Tests, die in unserem EU-Rechenzentrum ausgeführt werden, sind fehlgeschlagen. ### **Warum es passiert ist:** Ein Fehler ist bei unserem primären Netzwerkanbieter in unserem EU-Rechenzentrum aufgetreten. ### **Wie wir es repariert haben:** Wir sind aus unserem EU-Rechenzentrum an einen sekundären Netzwerkanbieter gescheitert. ### **Was wir tun, um zu verhindern, dass es wieder passiert: ** Wir haben unsere Überwachung und Alarmierung verbessert, um Probleme mit Drittanbietern zu erkennen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 1. Juli 2026 um 21:37 UTCresolved

   Am 1. Juli zwischen 17:02 UTC und 21:31 UTC konnten die macOS 14-Tests in den US-West- und EU-zentralen Rechenzentren nicht starten. Dieses Problem ist gelöst. Alle Dienste sind voll funktionsfähig.

2. 11. August 2026 um 20:37 UTCpostmortem

   ### **Dates:** Wednesday July 1st 2026, 17:02 UTC - 21:31 UTC ### **What happened:** macOS 14 tests in the US West and EU Central data centers were unable to start. ### **Why it happened:** An internal datasource was unavailable due to a missing configuration entry. ### **How we fixed it:** The missing entry was replaced. ### **What we are doing to prevent it from happening again:** Safeguards have been put in place to prevent in-use datasource removal from configuration.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 1. Juli 2026 um 12:12 UTCinvestigating

   Wir haben ein Problem mit dem Zugriff auf Appium Inspector in den Rechenzentren US-West-1, EU-Central-1 und US-East-4. Wir untersuchen.

2. 1. Juli 2026 um 12:58 UTCresolved

   Wir haben die Ursache identifiziert und einen Fix für dieses Problem eingesetzt. Alle Dienste sind voll funktionsfähig.

3. 20. Juli 2026 um 20:34 UTCpostmortem

   ### **Datum:** Mittwoch, 1. Juli 2026, 09:37 – 12:46 UTC ### **Was passiert ist:** Die Appium Inspector-Funktion, die während realer Live-Tests verwendet wurde, wurde nach einer geplanten Benutzeroberflächenbereitstellung nicht mehr verfügbar. Benutzern, die versuchten, die Funktion während eines Live-Tests zu verwenden, wurde ein 500-Fehler angezeigt, der ihre aktive Testsitzung unterbrach. Automatisierte Testpipelines waren nicht betroffen. ### **Warum es passiert ist:** Ein routinemäßiges Upgrade einer Core-Frontend-Bibliothek führte zu einer Inkompatibilität mit der Rendering-Logik des Appium Inspectors. Die vorherige Bibliotheksversion tolerierte das Muster, die aktualisierte Version jedoch nicht. Das Problem wurde vor dem Einsatz aufgrund unzureichender End-to-End-Testabdeckung für dieses spezielle Feature nicht erkannt. ### **Wie wir es repariert haben:** Wir haben die Benutzeroberfläche auf die letzte bekannte Arbeitsversion zurückgesetzt, um die Funktion sofort wiederherzustellen, und dann eine gezielte Korrektur für die Inkompatibilität bereitgestellt. ### **Was wir tun, um zu verhindern, dass es wieder passiert: ** Wir fügen eine End-to-End-Testabdeckung für die Appium Inspector-Funktion hinzu, um sicherzustellen, dass sie vor zukünftigen Bereitstellungen automatisch validiert wird.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 24. Juni 2026 um 16:39 UTCresolved

   Am 24. Juni, zwischen 08:28 UTC und 15:32 UTC, erlebten wir echte Geräte-Testsitzungsfehler, die Appium und Access API in den US-Ost-, US-West- und EU-Rechenzentren betrafen. Dieses Problem ist gelöst. Alle Dienste sind voll funktionsfähig.

2. 22. Juli 2026 um 20:49 UTCpostmortem

   ### **Datum:** Mittwoch, 24. Juni 2026, 09:42 UTC - 15:45 UTC. ### **Was passiert ist:** Echte Gerätetestsitzungen mit Appium und Access API verzeichneten erhöhte Fehlerquoten in den US-Rechenzentren East, West und EU. Die Sitzungen wurden nach etwa 90 Sekunden ablaufen oder im Zustand "Verbindung" stecken bleiben, so dass sie nicht geschlossen werden. ### **Warum es passiert ist:** Es wurde ein Produktfehler eingeführt, der dazu führte, dass Real Device-Testsitzungen nicht gestartet wurden und aktive Sitzungen nicht geschlossen werden konnten. ### **Wie wir es repariert haben:** Rollback auf eine stabile Version. ### **Was wir tun, um zu verhindern, dass es wieder passiert: ** Verbesserung der Überwachung und Alarmierung und Verbesserung der Validierung nach dem Einsatz.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 18. Juni 2026 um 05:30 UTCinvestigating

   Gegen 3:51 Uhr UTC begannen wir mit einer geringeren Verfügbarkeit von iOS-Geräten im EU-zentralen Rechenzentrum. Unser Team untersucht aktiv die Ursache und arbeitet an einer Lösung.

2. 18. Juni 2026 um 06:12 UTCmonitoring

   Wir haben erlebt, dass Geräte in unserem EU-Central-1-Rechenzentrum nicht verfügbar sind, und haben die Ursache identifiziert. Wir haben Abhilfemaßnahmen ergriffen und überwachen derzeit.

3. 18. Juni 2026 um 06:59 UTCresolved

   Nachdem wir Abhilfemaßnahmen ergriffen haben, stehen nun echte Geräte zum Testen im Rechenzentrum EU-Central-1 zur Verfügung. Alle Dienste sind voll funktionsfähig.

4. 6. Juli 2026 um 17:17 UTCpostmortem

   ### **Datum:** Donnerstag, 18. Juni 2026, 03:45 UTC - 06:45 UTC. ### **Was passiert ist:** Etwa 7% der iOS-Geräte in unserem EU-Rechenzentrum waren vorübergehend nicht für Kundentestsitzungen verfügbar, nachdem das Rack, in dem sie untergebracht waren, keinen Strom mehr hatte. ### **Warum es passiert ist:** Der Stromkreis, der das betroffene Rack speist, übertraf seine Kapazität, und ein Schutzschalter löste aus, um die Leitung zu schützen - die Stromversorgung der Geräte auf diesem Rack zu schneiden, bis der Stromkreis wiederhergestellt wurde. ### **Wie wir es repariert haben:** Der betroffene Stromkreis wurde zurückgesetzt und die Stromversorgung des Racks wiederhergestellt, wodurch die Geräte zum Kundendienst zurückkehrten. ### **Was wir tun, um zu verhindern, dass es wieder passiert: ** Wir verteilen die Stromlast auf die betroffenen Racks um, fügen Kapazitätsüberwachung mit Frühwarnmeldungen vor Schaltungsgrenzen hinzu und führen eine Kapazitätsprüfung ein, bevor neue Geräte in ein Rack eingesetzt werden.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 1. Juni 2026 um 14:02 UTCinvestigating

   We are experiencing an issue where the US-EAST data center is currently unavailable. We are investigating.

2. 1. Juni 2026 um 14:55 UTCinvestigating

   We are continuing to investigate this issue.

3. 1. Juni 2026 um 15:30 UTCinvestigating

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

4. 1. Juni 2026 um 16:02 UTCmonitoring

   Access has been restored to the US-EAST data center. We are monitoring.

5. 1. Juni 2026 um 18:24 UTCresolved

   After taking remedial action, access to the US-EAST data center is fully restored. This incident is resolved.

6. 15. Juni 2026 um 23:32 UTCpostmortem

   ### **Dates:** Monday, June 1st 2026, 13:06 UTC -  15:42 UTC. ### **What happened:** Customers served by the US-EAST-4 region were unable to authenticate or start new test sessions because an incomplete TLS certificate chain was deployed to the core directory services.  ### **Why it happened:** A certificate extraction script defect silently truncated the certificate chain after the certificate authority transitioned to a longer hierarchy.  ### **How we fixed it:** Reverted the certificate rotation and re-applied the previous known ,good certificate to restore authentication services. ### **What we are doing to prevent it from happening again:** Implementing pre-deployment certificate chain validation, adding active monitoring, and fixing the script's chain-length limitations.

1. 21. Mai 2026 um 14:53 UTCresolved

   Between May 13th 18:47 UTC and May 15th 9:23 UTC, we experienced test details not appearing in the dashboard of the US-East Data Center. This issue has been resolved. All services are fully operational.

2. 26. Mai 2026 um 15:07 UTCpostmortem

   ### **Dates:** Wednesday, May 13th 2026, 18:47 UTC - Friday, May 15th 2026, 09:23 UTC. ### **What happened:** Customers were unable to access test run summaries for Real Device Cloud \(RDC\) jobs because events stopped publishing to the jobs Kafka topic in US-EAST. ### **Why it happened:** An authentication key used by the message producer unexpectedly lost its permissions during an account cleanup. ### **How we fixed it:** Manually restored the required permissions to re-establish the connection and resume service. ### **What we are doing to prevent it from happening again:** Migrating to a permanent service account, implementing a Dead Letter Queue \(DLQ\) for the jobs Kafka topic, and replaying the missing events to restore customer data.

1. 24. April 2026 um 16:33 UTCresolved

   Between April 23rd 22:44 and April 24th 15:25 UTC, there was a technical issue that affected video recordings for tests running on macOS 15 and iOS within our EU and US-West Data Center. We identified the issue and deployed a fix. All systems are now fully operational.

2. 13. Mai 2026 um 15:05 UTCpostmortem

   ### **Dates:** Thursday, April 23rd 2026, 22:43 UTC - Friday, April 24th 2026, 15:29 UTC ### **What happened:** Video assets were missing for virtual iOS simulator tests on ARM and macOS ARM desktop tests in the US-West and EU data centers. ### **Why it happened:** A product defect was introduced resulting in a screen capture failure. ### **How we fixed it:** We performed a rollback to a stable version. ### **What we are doing to prevent it from happening again:** We are improving monitoring & alerting to enhance our post deployment validation.

1. 16. April 2026 um 10:10 UTCresolved

   Between 02:00 and 11:15 CEST, live and automated tests on iOS 17.0 simulators were failing to start in the EU and US-West Data Center. We executed a deployment rollback, which restored services. All systems are now fully operational.

2. 8. Mai 2026 um 18:42 UTCpostmortem

   ### **Dates:** Thursday, April 16th 2026, 00:00 UTC – 09:15 UTC ### **What happened:** Live and automated tests on iOS 17.0 simulators failed to start in both the EU and US-West data centers. Customers running tests on iOS 17.0 Intel-based simulators were unable to execute their tests for approximately 9 hours. ### **Why it happened:** A deployment introduced an incompatibility affecting iOS 17.0 on Intel-based infrastructure. The issue was not caught prior to release due to insufficient post-deployment test coverage for that specific simulator configuration. ### **How we fixed it:** We performed a rollback to the previous deployment, which restored full iOS 17.0 simulator functionality. ### **What we are doing to prevent it from happening again:** We are reviving and expanding automated post-deployment tests to cover a broader range of simulator configurations, including legacy Intel-based iOS versions, to catch incompatibilities before they reach production.

1. 7. April 2026 um 15:02 UTCinvestigating

   We are currently investigating reports of test failures affecting users running tests using SauceCtl in our US-West-1 and EU-Central-1 Data Center. We are investigating.

2. 7. April 2026 um 16:13 UTCresolved

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

3. 10. April 2026 um 21:56 UTCpostmortem

   ### **Dates:** Monday April 7th 2026, ~11:00 – 15:55 UTC ### **What happened:** Some customers experienced 503 errors when running tests via saucectl. The test-composer service was intermittently unavailable, preventing framework-based test execution. ### **Why it happened:** A stale Docker image was deployed to the test-composer service due to a packaging issue that arose during an internal container registry migration. This caused service pods to crash. ### **How we fixed it:** We identified the stale image and redeployed the correct version, restoring the service. ### **What we are doing to prevent it from happening again:** We are hardening our image deployment pipeline and adding validation checks to ensure container registry migrations do not result in stale or incorrect images being deployed to production.

1. 24. März 2026 um 17:36 UTCresolved

   Between 09:32 and 15:13 UTC, we identified a technical issue affecting iOS tests when running with network capture enabled. We've resolved the underlying cause and tests are working as expected. All services are fully operational.

2. 10. April 2026 um 23:06 UTCpostmortem

   ### **Dates:** Tuesday, March 24th 2026, 09:32 UTC – 15:13 UTC ### **What happened:** Network calls failed on iOS devices during Real Device Cloud sessions where network capture was enabled. Approximately 12-13% of iOS sessions were affected. Android was not impacted. ### **Why it happened:** A deployment introduced a DNS resolution change that was incompatible with the iOS platform, causing network capture to break. ### **How we fixed it:** Rolled back the deployment to restore service. ### **What we are doing to prevent it from happening again:** Adding synthetic tests to catch network capture regressions before production, and implementing monitoring alerts for faster detection after deployments.

1. 19. März 2026 um 09:51 UTCinvestigating

   Around 4:45 AM UTC we started experiencing lower iOS device availability in the US-West data center. Our team is actively investigating the root cause and working toward a resolution.

2. 19. März 2026 um 10:54 UTCresolved

   This incident has been resolved and our services are fully operational.

3. 10. April 2026 um 22:59 UTCpostmortem

   ### **Dates:** Wednesday, March 19 2026, 04:45 UTC - 10:47 UTC. ### **What happened:** Approximately 15% of iOS devices in our US-West data center were temporarily unavailable for customer test sessions due to failed internet connectivity checks. ### **Why it happened:** An automated wireless network optimization feature adjusted transmit power levels on access points serving the affected devices, degrading wireless connectivity and causing devices to fail their availability checks. ### **How we fixed it:** The affected access points were identified and restarted, restoring normal wireless connectivity. ### **What we are doing to prevent it from happening again:** Evaluation of the automated optimization tools and a monitoring improvement.

1. 18. März 2026 um 17:15 UTCresolved

   Between 14:43 and 15:11 UTC on March 13, a small subset of Real Devices (iOS and Android) became unavailable across all our data centers. After taking remedial action, the issue was identified and resolved. All services are fully operational.

2. 10. April 2026 um 22:57 UTCpostmortem

   ### **Dates:** Friday, March 13th 2026, 14:43 UTC - 15:11 UTC. ### **What happened:** Real Devices \(iOS and Android\) availability gradually decreased across all data centers. ### **Why it happened:** A product defect was introduced resulting in a small subset of Real Devices \(~10%\) failing to maintain required connectivity. ### **How we fixed it:** Rollback to a stable version. ### **What we are doing to prevent it from happening again:** Improve monitoring & alerting, enhance post deployment validation.

1. 10. März 2026 um 18:46 UTCinvestigating

   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. 10. März 2026 um 23:34 UTCresolved

   This incident has been resolved.

3. 9. April 2026 um 21:07 UTCpostmortem

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

1. 6. März 2026 um 23:28 UTCresolved

   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. 10. April 2026 um 22:53 UTCpostmortem

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