67 Sauce Labs incidents · novembre 2024 — official updates, affected components, duration and resolution details.
Le 13 octobre, entre 05:10 UTC et 05:45 UTC, nous avons connu des taux d'erreur élevés pour les services VDC, RDC, Sauce Connect et IPSec dans le centre de données US-West-1. La question a été réglée. Tous les services sont maintenant pleinement opérationnels.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Nous avons un problème avec l'interface utilisateur Sauce Labs dans le centre de données EU-Central-1. Nous enquêtons.
Nous avons encore des problèmes avec l'interface utilisateur Sauce Labs dans le centre de données EU-Central-1. Nous continuons d'enquêter.
Nous avons fait des progrès dans la réduction de la cause des problèmes d'assurance-chômage de Sauce Labs dans le centre de données EU-Central-1. L'enquête est en cours.
Nous travaillons en étroite collaboration avec nos fournisseurs tiers pour résoudre le problème actuel dans le centre de données EU-Central-1. L'enquête est en cours.
Nous continuons à travailler avec nos partenaires et les équipes compétentes pour étudier et résoudre la question en cours dans le centre de données UE-Central-1. Nous partagerons d'autres mises à jour à mesure que de plus amples renseignements seront disponibles.
La cause profonde du problème qui affecte notre accès à l'interface utilisateur dans l'EU-Central-1 est liée à un incident en cours avec un de nos fournisseurs d'infrastructure tiers dans le centre de données. Alors que notre équipe maintient ce ticket d'incident fermé à notre fin, nous suivons activement l'enquête en cours du fournisseur et surveillerons de près le rendement.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Nous rencontrons une dégradation dans l'ingestion d'erreurs pour la déclaration d'erreurs (Backtrace) en utilisant le crashpad sur Android et Linux dans tous les centres de données. Nous enquêtons actuellement.
Nous continuons d'enquêter sur cette question.
La cause profonde de l'ingestion d'erreurs pour la déclaration d'erreurs (Backtrace) a été identifiée. Des mesures correctives ont été appliquées et nous suivons activement la situation.
Après avoir pris des mesures correctives, le problème de l'ingestion d'erreurs dans la déclaration d'erreurs (Backtrace) a été résolu. Tous les services sont pleinement opérationnels.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Nous observons actuellement des taux d'erreur élevés pour les tests d'appareils réels dans le centre de données EU-Central-1. Nous enquêtons.
Les taux d'erreur de test des appareils réels sont revenus à la normale dans le centre de données EU-Central-1. Tous les services sont pleinement opérationnels.
Dates :** Mercredi 30 septembre 2026, 09:04 UTC - 10:49 UTC. Qu'est-ce qui s'est passé ? Real Device Automated Tests n'a pas réussi à démarrer dans le centre de données de l'UE, les taux d'erreur atteignant jusqu'à 25%. Pourquoi ça s'est passé ? Un déploiement a entraîné une augmentation des pannes de cache et une charge élevée sur l'infrastructure sous-jacente. ### ** Comment on l'a réparé :** Le service a été restauré en retournant à une version précédente. **Ce que nous faisons pour l'empêcher de se reproduire:** D'autres stratégies de cache sont envisagées pour accroître l'efficacité du cache.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Nous voyons actuellement des taux d'erreur élevés pour les tests automatisés de vrais appareils dans le centre de données US-West-1. Nous enquêtons actuellement.
La cause fondamentale des taux d'erreur élevés pour les tests de Real Device dans le centre de données US-West-1 a été identifiée. Des mesures correctives ont été appliquées et nous suivons activement la situation.
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 US-West-1. Tous les services sont pleinement opérationnels.
Dates :** Lundi 28 septembre 2026, 14:19 UTC - 16:52 UTC. Qu'est-ce qui s'est passé ? Les vrais tests d'appareil à US West ont accroché et n'ont pas réussi à produire des artefacts d'essai en raison de chargements lents. Pourquoi ça s'est passé ? Un lien d'interconnexion dégradé a subi une forte perte de paquets à cause d'erreurs optiques, mais BGP est resté en place, empêchant l'échec automatique à des chemins sains. ### ** Comment on l'a réparé :** Désactive manuellement le port dégradé sur le routeur de bord, forçant le trafic sur des interconnexions saines. **Ce que nous faisons pour l'empêcher de se reproduire:** Automatiser le drainage des liens en fonction des seuils d'erreur CRC, améliorer les protocoles d'isolement des liens des fournisseurs et durcir la résilience du téléchargement.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Entre 12h05 UTC et 12h35 UTC, nous avons connu un taux d'erreur élevé et des temps de début de session plus longs pour les tests de bureau et de périphérique virtuel dans le centre de données US-West-1. La question a été réglée. Tous les services sont pleinement opérationnels.
### **Dates:** Wednesday, September 23rd 2026, 12:05 UTC - 12:35 UTC. ### **What happened:** Virtual Device Cloud testing availability gradually decreased in the US-West-1 data center. ### **Why it happened:** A product defect was introduced causing Virtual Device Cloud testing sessions to fail to start. ### **How we fixed it:** Rollback to a stable version. ### **What we are doing to prevent it from happening again:** Strengthen pre-deployment validation and reassess configuration rollout strategies.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Entre 09:52 UTC et 10:34 UTC, plusieurs services de Sauce Labs dans le centre de données US-West ont connu une panne, causant des défaillances d'authentification et des perturbations aux fonctionnalités de test. Tous les systèmes sont maintenant pleinement opérationnels.
Dates :** Mercredi 16 septembre 2026, 09:51 UTC - 10:35 UTC. Qu'est-ce qui s'est passé ? La disponibilité des services de Sauce Labs a progressivement diminué dans le centre de données US-West-1. Les services concernés comprenaient : * Authentification \(sign-in, SSO, sessions existantes et inscription\) * Nuage de périphérique virtuel \(VDC\) * Real Device Cloud \(RDC\) * Connexion de sauce * API REST * Stockage des applications * Perspectives * Sauce visuelle * Compositeur d'essai * Gestion des utilisateurs et des équipes * Plans de facturation et API d'utilisation Pourquoi ça s'est passé ? Un déploiement du service Authentification a déclenché une augmentation inattendue des connexions à la base de données, causant des défaillances d'authentification et perturbant plusieurs services Sauce Labs. ### ** Comment on l'a réparé :** Redémarrer le nœud de base de données touché. **Ce que nous faisons pour l'empêcher de se reproduire:** Améliorer les stratégies de déploiement, la gestion du cycle de vie des connexions, les mécanismes de basculement et la réactivité aux contrôles de santé.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
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.
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.
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.
**Dates:** Mercredi 2 septembre 2026, 08:30 UTC - 11:15 UTC. Qu'est-ce qui s'est passé ? Real Device Automated Tests n'a pas réussi à démarrer dans le centre de données de l'UE, avec des taux d'erreur élevés atteignant presque 100% pendant de courtes périodes. Pourquoi ça s'est passé ? Un déploiement a entraîné une augmentation des pannes de cache et une charge élevée sur l'infrastructure sous-jacente. ### ** Comment on l'a réparé :** Le service a été rétabli en redémarrant l'application. **Ce que nous faisons pour l'empêcher de se reproduire:** Des ressources supplémentaires ont été allouées pour réduire la probabilité de récidive à court terme. À long terme, nous optimiserons la performance des tâches exigeantes en ressources et introduirons une échelle dynamique.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
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.
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.
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.
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.
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
### **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.
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.
### **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.
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.
### **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.
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.
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.
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.
Nous restons à l'affût de tout autre problème.
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.
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.
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.
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.
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.
Nous avons identifié la cause profonde et avons déployé une solution pour cette question. Tous les services sont pleinement opérationnels.
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.
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.
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.
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.
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.
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.
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.
We are experiencing an issue where the US-EAST data center is currently unavailable. We are investigating.
We are continuing to investigate this issue.
We have identified the root cause and are working on implementing a fix.
Access has been restored to the US-EAST data center. We are monitoring.
After taking remedial action, access to the US-EAST data center is fully restored. This incident is resolved.
### **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.
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.
### **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.
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.
### **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.
