67 Sauce Labs incidents · November 2024 — official updates, affected components, duration and resolution details.
Am 13. Oktober, zwischen 05:10 UTC und 05:45 UTC, verzeichneten wir erhöhte Fehlerraten für VDC, RDC, Sauce Connect und IPSec-Dienste im US-West-1-Rechenzentrum. Das Problem ist gelöst. Alle Dienste sind jetzt voll funktionsfähig.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir haben ein Problem mit der UI von Sauce Labs im Rechenzentrum EU-Central-1. Wir untersuchen.
Wir haben immer noch Probleme mit der UI von Sauce Labs im Rechenzentrum EU-Central-1. Wir untersuchen weiter.
Wir haben Fortschritte bei der Eingrenzung der Ursache für die laufenden UI-Probleme von Sauce Labs im Rechenzentrum EU-Central-1 gemacht. Die Untersuchung läuft noch.
Wir arbeiten eng mit unseren Drittanbietern zusammen, um das laufende Problem im Rechenzentrum EU-Central-1 zu lösen. Die Untersuchung läuft noch.
Wir arbeiten weiterhin mit unseren Partnern und relevanten Teams zusammen, um das laufende Problem im Rechenzentrum EU-Central-1 zu untersuchen und zu lösen. Wir werden weitere Updates teilen, sobald weitere Informationen verfügbar sind.
Die Ursache des Problems, das unseren UI-Zugang in der EU-Zentrale-1 betrifft, hängt mit einem anhaltenden Vorfall mit einem unserer Drittanbieter von Infrastruktur im Rechenzentrum zusammen. Während unser Team dieses Vorfallsticket an unserem Ende geschlossen hält, verfolgen wir aktiv die laufenden Untersuchungen des Anbieters und werden die Leistung genau überwachen.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir erleben eine Verschlechterung der Fehleraufnahme für Error Reporting (Backtrace) mit Crashpad unter Android und Linux in allen Rechenzentren. Wir untersuchen derzeit.
Wir werden dieses Problem weiter untersuchen.
Die Ursache für die Fehleraufnahme für Error Reporting (Backtrace) wurde identifiziert. Es wurde Abhilfe geschaffen, und wir beobachten die Situation aktiv.
Nachdem Abhilfemaßnahmen ergriffen wurden, wurde das Problem mit der Fehleraufnahme in der Fehlerberichterstattung (Backtrace) behoben. Alle Dienste sind voll funktionsfähig.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir sehen derzeit erhöhte Fehlerquoten für reale Gerätetests im Rechenzentrum EU-Central-1. Wir untersuchen.
Echte Gerätetestfehlerraten haben sich im Rechenzentrum EU-Central-1 wieder normalisiert. Alle Dienste sind voll funktionsfähig.
### **Datum:** Mittwoch, 30. September 2026, 09:04 UTC - 10:49 UTC. ### **Was passiert ist:** Real Device Automated Tests konnten im zentralen Rechenzentrum der EU nicht starten, wobei die Fehlerquoten bis zu 25% erreichten. ### **Warum es passiert ist:** Ein Einsatz führte zu erhöhten Cache-Ausfällen und einer erhöhten Belastung der zugrunde liegenden Infrastruktur. ### **Wie wir es repariert haben:** Der Service wurde wiederhergestellt, indem er auf eine frühere Version zurückgesetzt wurde. ### **Was wir tun, um zu verhindern, dass es wieder passiert: ** Alternative Caching-Strategien werden in Betracht gezogen, um die Effektivität des Cache zu erhöhen.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir sehen derzeit erhöhte Fehlerquoten für automatisierte reale Gerätetests im US-West-1-Rechenzentrum. Wir untersuchen derzeit.
Die Ursache für die erhöhten Fehlerraten bei Real Device Tests im US-West-1-Rechenzentrum wurde identifiziert. Es wurde Abhilfe geschaffen, und wir beobachten die Situation aktiv.
Nach Abhilfemaßnahmen haben sich die Testfehlerraten von Real Device im US-West-1-Rechenzentrum wieder normalisiert. Alle Dienste sind voll funktionsfähig.
### **Datum:** Montag, 28. September 2026, 14:19 UTC - 16:52 UTC. ### **Was passiert ist:** Echte Gerätetests in US West hingen und konnten aufgrund langsamer Uploads keine Testartefakte ausgeben. ### **Warum es passiert ist:** Eine degradierte Verbindungsverbindung erlitt einen hohen Paketverlust durch optische Fehler, aber BGP blieb auf und verhinderte ein automatisches Failover auf gesunde Pfade. ### **Wie wir es repariert haben:** Manuelle Deaktivierung des degradierten Ports am Edge-Router, wodurch der Datenverkehr auf gesunde alternative Verbindungen gezwungen wird. ### **Was wir tun, um zu verhindern, dass es wieder passiert: ** Automatisieren des Link-Drainings basierend auf CRC-Fehlerschwellen, Verbessern von Protokollen zum Isolieren von Flapping-Vendor-Links und Härten der Upload-Resilienz.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Zwischen 12:05 UTC und 12:35 UTC hatten wir eine hohe Fehlerrate und längere Sitzungsstartzeiten für Desktop- und Virtual-Device-Tests im US-West-1-Rechenzentrum. Das Problem ist gelöst. Alle Dienste sind voll funktionsfähig.
### **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.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Zwischen 09:52 UTC und 10:34 UTC erlebten mehrere Sauce Labs-Dienste im US-West-Rechenzentrum einen Ausfall, was zu Authentifizierungsfehlern und Störungen der Testfunktionen führte. Alle Systeme sind jetzt voll funktionsfähig.
### **Datum:** Mittwoch, 16. September 2026, 09:51 UTC - 10:35 UTC. ### **Was passiert ist:** Die Verfügbarkeit mehrerer Sauce Labs-Dienste im US-West-1-Rechenzentrum ging allmählich zurück. Die betroffenen Dienste umfassten: * Authentifizierung \(Anmelden, SSO, bestehende Sitzungen und Anmeldung\) * Virtual Device Cloud \(VDC\) * Real Device Cloud \(RDC\) * Sauce Connect * REST API * App Storage * Einblicke * Visuelle Sauce * Test Composer * Benutzer- und Teammanagement * Abrechnungspläne und Nutzungs-API ### **Warum es passiert ist:** Eine Bereitstellung des Authentifizierungsdienstes löste einen unerwarteten Anstieg der Datenbankverbindungen aus, was zu Authentifizierungsfehlern führte und mehrere Sauce Labs-Dienste unterbrach. ### **Wie wir es repariert haben:** Neustart des betroffenen Datenbankknotens. ### **Was wir tun, um zu verhindern, dass es wieder passiert: ** Verbesserung der Rollout-Strategien, des Verbindungslebenszyklusmanagements, der Failover-Mechanismen und der Reaktionsfähigkeit des Gesundheitschecks.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir sehen erhöhte Fehlerquoten für Real Device Tests im Rechenzentrum EU-Central-1. Wir untersuchen.
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.
Nach Abhilfemaßnahmen haben sich die Testfehlerraten von Real Device im Rechenzentrum EU-Central-1 wieder normalisiert. Alle Dienste sind voll funktionsfähig.
**Datum:** Mittwoch, 2. September 2026, 08:30 UTC - 11:15 UTC. ### **Was passiert ist:** Real Device Automated Tests konnten nicht im zentralen Rechenzentrum der EU starten, wobei erhöhte Fehlerquoten für kurze Zeit fast 100% erreichten. ### **Warum es passiert ist:** Ein Einsatz führte zu erhöhten Cache-Ausfällen und einer erhöhten Belastung der zugrunde liegenden Infrastruktur. ### **Wie wir es repariert haben:** Der Dienst wurde durch Neustart der Anwendung wiederhergestellt. ### **Was wir tun, um zu verhindern, dass es wieder passiert: ** Zusätzliche Mittel wurden bereitgestellt, um die Wahrscheinlichkeit eines erneuten Auftretens kurzfristig zu verringern. Langfristig werden wir die Performance ressourcenintensiver Aufgaben optimieren und eine dynamische Skalierung einführen.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir sehen derzeit erhöhte Fehlerraten für macOS- und iOS-Tests im US-West-1-Rechenzentrum. Wir untersuchen derzeit.
Nachdem alle macOS- und iOS-Tests nun wie erwartet im US-West-1-Rechenzentrum durchgeführt wurden. Alle Dienste sind voll funktionsfähig.
### **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.
Wir sehen derzeit erhöhte Fehlerraten für virtuelle Desktop-Tests im US-West-1-Rechenzentrum. Wir untersuchen derzeit.
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.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
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.
### **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.
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.
### **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.
Wir haben ein Problem im EU Central 1 Rechenzentrum, wo iOS ARM Simulator App Tests mit Infrastrukturfehlern fehlschlagen. Wir untersuchen.
App-Downloads dauern länger als erwartet, wenn diese Infrastrukturfehler auftreten. Wir untersuchen weiter.
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.
Wir werden weiterhin auf weitere Probleme achten.
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.
### **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.
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.
### **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.
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.
Wir haben die Ursache identifiziert und einen Fix für dieses Problem eingesetzt. Alle Dienste sind voll funktionsfähig.
### **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.
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.
### **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.
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.
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.
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.
### **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.
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.
