Historique des pannes de Sauce Labs

1. 2 septembre 2026 à 09:39 UTCinvestigating

   Nous voyons des taux d'erreur élevés pour les tests Real Device dans le centre de données EU-Central-1. Nous enquêtons.

2. 2 septembre 2026 à 11:30 UTCidentified

   La cause profonde des taux d'erreur élevés pour les tests de Real Device dans le centre de données EU-Central-1 a été identifiée. Des mesures correctives ont été appliquées et nous suivons activement la situation.

3. 2 septembre 2026 à 11:53 UTCresolved

   Après avoir pris des mesures correctives, les taux d'erreur de test de l'appareil réel sont revenus à la normale dans le centre de données EU-Central-1. Tous les services sont pleinement opérationnels.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 25 août 2026 à 12:33 UTCinvestigating

   Nous voyons actuellement des taux d'erreur élevés pour les tests macOS et iOS dans le centre de données US-West-1. Nous enquêtons actuellement.

2. 25 août 2026 à 13:19 UTCresolved

   Après avoir pris des mesures correctives, tous les tests macOS et iOS fonctionnent désormais comme prévu dans le centre de données US-West-1. Tous les services sont pleinement opérationnels.

3. 3 septembre 2026 à 20:23 UTCpostmortem

   Dates :** Mardi 25 août 2026, 11:38 – 13:10 UTC Qu'est-ce qui s'est passé ? Les clients effectuant des tests macOS et iOS dans notre région US-West ont connu un service dégradé. Environ 50% de la capacité de Mac virtuel dans la région a cessé d'accepter de nouveaux tests, de sorte que les tests soit en attente ou a échoué à démarrer. La capacité restante a été soumise à une pression supplémentaire au fur et à mesure que le travail s'est déplacé vers elle, ce qui a prolongé les temps de départ pour les essais de bureau et de simulateur. Pourquoi ça s'est passé ? Un certificat de sécurité interne utilisé par nos hôtes Mac pour atteindre un service cloud support a atteint sa date d'expiration. Une fois caduque, les hôtes ne pouvaient plus établir une connexion fiable à ce service et ont cessé de fournir de nouvelles machines d'essai. Le certificat avait été délivré manuellement et n'avait ni renouvellement automatisé ni alerte à l'expiration. ### ** Comment on l'a réparé :** Nous avons délivré et déployé un certificat de remplacement, qui a rétabli la connectivité et rendu la capacité Mac à des niveaux normaux. **Ce que nous faisons pour l'empêcher de se reproduire:** Nous déplaçons ces certificats sur le renouvellement automatisé et ajoutons des alertes afin qu'ils soient remplacés bien avant l'expiration, ainsi que l'examen des outils environnants pour rendre la manipulation des certificats plus sécuritaire.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 7 août 2026 à 12:08 UTCinvestigating

   Nous voyons actuellement des taux d'erreur élevés pour les tests virtuels de bureau dans le datacenter US-West-1. Nous enquêtons actuellement.

2. 7 août 2026 à 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 août 2026 à 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.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 16 juillet 2026 à 20:33 UTCresolved

   Entre le 16 juillet 13h03 UTC et le 16 juillet 17h33 UTC, nous avons connu une interruption de service où les archives de symboles utilisant des protocoles de téléchargement en plusieurs parties n'ont pas été traitées. L'incident a été résolu et tous les services sont opérationnels.

2. 14 août 2026 à 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.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 16 juillet 2026 à 20:30 UTCresolved

   Entre le 14 juillet 23h45 UTC et le 15 juillet 23h05 UTC, nous avons connu un problème où le téléchargement d'archive de symboles vers des projets Backtrace a échoué avec des erreurs HTTP 400. L'incident a été résolu et tous les services sont opérationnels.

2. 14 août 2026 à 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.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 14 juillet 2026 à 17:19 UTCinvestigating

   Nous sommes confrontés à un problème dans le centre de données EU Central 1, où les tests d'application iOS ARM Simulator échouent avec des erreurs d'infrastructure. Nous enquêtons.

2. 14 juillet 2026 à 18:05 UTCinvestigating

   Les téléchargements d'applications prennent plus de temps que prévu lorsque ces erreurs d'infrastructure sont constatées. Nous continuons d'enquêter.

3. 14 juillet 2026 à 18:56 UTCmonitoring

   Nous avons déployé une solution pour ce problème. Les tests devraient maintenant se dérouler comme prévu dans le centre de données 1 de l'UE. Nous surveillons.

4. 14 juillet 2026 à 19:11 UTCmonitoring

   Nous restons à l'affût de tout autre problème.

5. 14 juillet 2026 à 20:23 UTCresolved

   Après avoir pris des mesures correctives et suivi la situation, nous voyons les tests d'application iOS ARM fonctionner comme prévu dans le Centre de données de l'UE. Tous les services sont pleinement opérationnels.

6. 29 juillet 2026 à 17:40 UTCpostmortem

   Dates :** Mardi 14 juillet 2026, 09:00 - 18:28 UTC Qu'est-ce qui s'est passé ? Les tests ARM iOS en cours dans notre centre de données de l'UE ont échoué. Pourquoi ça s'est passé ? Un défaut est survenu avec notre fournisseur de réseau principal dans notre centre de données de l'UE. ### ** Comment on l'a réparé :** Nous avons échoué à un fournisseur de réseau secondaire de notre centre de données de l'UE. **Ce que nous faisons pour l'empêcher de se reproduire:** Nous avons amélioré notre surveillance et l'alerte pour attraper des problèmes avec des fournisseurs de réseaux tiers.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 1 juillet 2026 à 21:37 UTCresolved

   Le 1er juillet entre 17h02 UTC et 21h31 UTC, les tests macOS 14 n'ont pas démarré dans les centres de données US-Ouest et EU-Central. Cette question a été résolue. Tous les services sont pleinement opérationnels.

2. 11 août 2026 à 20:37 UTCpostmortem

   Dates :** Mercredi 1er juillet 2026, 17:02 UTC - 21:31 UTC Qu'est-ce qui s'est passé ? Les tests macOS 14 dans les centres de données de l'Ouest et de l'UE n'ont pas pu démarrer. Pourquoi ça s'est passé ? Une source de données interne n'était pas disponible en raison d'une entrée de configuration manquante. ### ** Comment on l'a réparé :** L'entrée manquante a été remplacée. **Ce que nous faisons pour l'empêcher de se reproduire:** Des garanties ont été mises en place pour empêcher la suppression de la source de données en cours d'utilisation de la configuration.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 1 juillet 2026 à 12:12 UTCinvestigating

   Nous avons un problème avec l'accès à l'inspecteur Appium dans les centres de données US-West-1, EU-Central-1 et US-East-4. Nous enquêtons.

2. 1 juillet 2026 à 12:58 UTCresolved

   Nous avons identifié la cause profonde et avons déployé une solution pour cette question. Tous les services sont pleinement opérationnels.

3. 20 juillet 2026 à 20:34 UTCpostmortem

   Dates :** Mercredi 1er juillet 2026, 09:37 – 12:46 UTC Qu'est-ce qui s'est passé ? La fonctionnalité Appium Inspector, utilisée lors des séances de test réel, est devenue indisponible après un déploiement prévu de l'interface utilisateur. Les utilisateurs qui ont tenté d'utiliser la fonction lors d'un test en direct ont été présentés avec une erreur de 500, ce qui a perturbé leur session active de test. Les pipelines d'essai automatisés n'ont pas été touchés. Pourquoi ça s'est passé ? Une mise à niveau de routine d'une bibliothèque principale de frontend a introduit une incompatibilité avec la logique de rendu de l'inspecteur Appium. La version précédente de la bibliothèque a toléré le modèle, mais la version mise à jour ne l'a pas. La question n'a pas été réglée avant le déploiement en raison d'une couverture d'essai de bout en bout insuffisante pour cette caractéristique spécifique. ### ** Comment on l'a réparé :** Nous avons retourné l'interface utilisateur à la dernière version de travail connue pour restaurer la fonctionnalité immédiatement, puis déployé une correction ciblée pour l'incompatibilité. **Ce que nous faisons pour l'empêcher de se reproduire:** Nous ajoutons une couverture de test de bout en bout pour la fonctionnalité de l'inspecteur Appium afin de s'assurer qu'elle est validée automatiquement avant les déploiements futurs.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 24 juin 2026 à 16:39 UTCresolved

   Le 24 juin, entre 08:28 UTC et 15:32 UTC, nous avons connu des pannes de session de test Real Device impactant l'API Appium et Access aux centres de données US East, US West et EU. Cette question a été résolue. Tous les services sont pleinement opérationnels.

2. 22 juillet 2026 à 20:49 UTCpostmortem

   Dates :** Mercredi 24 juin 2026, 09:42 UTC - 15:45 UTC. Qu'est-ce qui s'est passé ? Sessions de test de l'appareil réel utilisant l'API Appium et Access ont connu des taux d'erreur accrus dans les centres de données US East, US West et EU. Les séances se déroulait après environ 90 secondes ou devenaient coincées dans l'état de « connexion », les empêchant d'être fermées. Pourquoi ça s'est passé ? Un défaut de produit a été introduit, ce qui a fait que les séances d'essai de l'appareil réel ne démarrent pas et empêche les séances actives d'être fermées. ### ** Comment on l'a réparé :** Retour à une version stable. **Ce que nous faisons pour l'empêcher de se reproduire:** Améliorer la surveillance et l'alerte et améliorer la validation après déploiement.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 18 juin 2026 à 05:30 UTCinvestigating

   Vers 15h51 UTC, nous avons commencé à vivre une diminution de la disponibilité des appareils iOS dans le centre de données EU-Central. Notre équipe enquête activement sur la cause fondamentale et travaille à une résolution.

2. 18 juin 2026 à 06:12 UTCmonitoring

   Nous avons constaté l'absence d'appareil dans notre centre de données EU-Central-1 et avons identifié la cause profonde. Nous avons pris des mesures correctives et nous sommes en train de surveiller.

3. 18 juin 2026 à 06:59 UTCresolved

   Après avoir pris des mesures correctives, nous voyons maintenant des appareils réels disponibles pour les tests dans le centre de données EU-Central-1. Tous les services sont pleinement opérationnels.

4. 6 juillet 2026 à 17:17 UTCpostmortem

   Dates :** Jeudi 18 juin 2026, 03:45 UTC - 06:45 UTC. Qu'est-ce qui s'est passé ? Environ 7% des appareils iOS de notre centre de données de l'UE étaient temporairement indisponibles pour les sessions de test client après une perte de puissance pour le rack les hébergeant. Pourquoi ça s'est passé ? Le circuit électrique alimentant le rack touché a dépassé sa capacité, et un disjoncteur protecteur a trébuché pour sauvegarder la puissance de coupe de la ligne aux appareils sur ce rack jusqu'à ce que le circuit soit rétabli. ### ** Comment on l'a réparé :** Le circuit touché a été réinitialisé et l'alimentation a été rétablie au rack, retournant les appareils au service à la clientèle. **Ce que nous faisons pour l'empêcher de se reproduire:** Nous redistribuons la charge de puissance entre les racks touchés, en ajoutant une surveillance de la capacité avec des alertes d'alerte précoce avant les limites de circuit, et en introduisant un examen de la capacité avant le déploiement de nouveaux appareils sur un rack.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 1 juin 2026 à 14:02 UTCinvestigating

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

2. 1 juin 2026 à 14:55 UTCinvestigating

   We are continuing to investigate this issue.

3. 1 juin 2026 à 15:30 UTCinvestigating

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

4. 1 juin 2026 à 16:02 UTCmonitoring

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

5. 1 juin 2026 à 18:24 UTCresolved

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

6. 15 juin 2026 à 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 à 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 à 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 avril 2026 à 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 à 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 avril 2026 à 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 à 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 avril 2026 à 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 avril 2026 à 16:13 UTCresolved

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

3. 10 avril 2026 à 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 mars 2026 à 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 avril 2026 à 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 mars 2026 à 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 mars 2026 à 10:54 UTCresolved

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

3. 10 avril 2026 à 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 mars 2026 à 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 avril 2026 à 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 mars 2026 à 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 mars 2026 à 23:34 UTCresolved

   This incident has been resolved.

3. 9 avril 2026 à 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 mars 2026 à 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 avril 2026 à 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.