67 Sauce Labs incidents · november 2024 — official updates, affected components, duration and resolution details.
Den 13. oktober, mellem 05: 10 UTC og 05: 45 UTC, oplevede vi forhøjede fejlrater for VDC, RDC, Sauce Connect, og IPSec tjenester i US- West-1 datacenter. Spørgsmålet er løst. Alle tjenester er nu fuldt operationelle.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi oplever et problem med Sauce Labs UI i EU- Central-1 datacenter. Vi efterforsker det.
Vi oplever stadig problemer med Sauce Labs UI i EU-Central-1 datacenter. Vi fortsætter med at undersøge sagen.
Vi har gjort fremskridt med at indsnævre årsagen til de igangværende Sauce Labs UI-spørgsmål i EU-Central-1 datacenter. Undersøgelsen er i gang.
Vi arbejder tæt sammen med vores tredjepartsudbydere for at løse det aktuelle problem i EU-Central-1 datacentret. Undersøgelsen er i gang.
Vi fortsætter med at arbejde sammen med vores partnere og relevante hold for at undersøge og løse det igangværende problem i EU-Central-1 datacenter. Vi vil dele yderligere opdateringer, efterhånden som flere oplysninger bliver tilgængelige.
Den grundlæggende årsag til problemer, der påvirker vores UI-adgang i EU- Central-1 er bundet til en igangværende hændelse med en af vores tredjeparts infrastrukturudbydere i datacentret. Mens vores team holder denne hændelse billet lukket på vores ende, er vi aktivt spore udbyderens igangværende undersøgelse og vil overvåge ydeevne tæt.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi oplever en forringelse i forkert indtagelse for fejlrapportering (Backtrace) ved hjælp af crashpad på Android og Linux på tværs af alle Data Centers. Vi er ved at undersøge sagen.
Vi fortsætter med at undersøge dette spørgsmål.
Den egentlige årsag til fejlindtagelse for fejlrapportering (Backtrace) er blevet identificeret. Der er foretaget en sanering, og vi overvåger aktivt situationen.
Efter at have truffet afhjælpende foranstaltninger, er problemet med fejlindtagelse i fejlrapportering (Backtrace) blevet løst. Alle tjenester er fuldt operationelle.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi ser i øjeblikket forhøjede fejlrater for reelle enhedstests i EU- Central-1 datacenter. Vi efterforsker det.
Realenhed test fejlrater er vendt tilbage til normal i EU-Central-1 datacentret. Alle tjenester er fuldt operationelle.
# # * * Datoer: * * Onsdag den 30. september 2026, 09: 04 UTC - 10: 49 UTC. Hvad skete der? Real Device Automated Tests oplevede ikke at starte i EU 's centrale datacenter, med fejlrater på op til 25%. Hvorfor skete det? En implementering førte til øget cache savner og forhøjet belastning på den underliggende infrastruktur. Hvordan vi ordnede det: Tjenesten blev genoprettet ved at rulle tilbage til en tidligere version. Hvad vi gør for at forhindre det i at ske igen: Alternative caching strategier overvejes at øge effektiviteten af cache.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi ser i øjeblikket forhøjede fejlrater for automatiserede real enhed tests i US- West-1 datacenter. Vi er ved at undersøge sagen.
Den grundlæggende årsag til de forhøjede fejlrater for Real Device tests i US- West-1 datacentret er blevet identificeret. Der er foretaget en sanering, og vi overvåger aktivt situationen.
Efter at have taget afhjælpende foranstaltninger, er Real Device test fejlrater vendt tilbage til normal i US- West-1 datacentret. Alle tjenester er fuldt operationelle.
# # * * Datoer: * * Mandag den 28. september 2026, 14: 19 UTC - 16: 52 UTC. Hvad skete der? Real enhed tests i US West hang og undlod at udskrive test artefakter på grund af langsom uploads. Hvorfor skete det? En nedbrudt forbindelse led stort pakketab fra optiske fejl, men BGP forblev oppe og forhindrede automatisk svigt i sunde stier. Hvordan vi ordnede det: Manuel deaktiveret den nedbrudte port på kant router, tvinger trafik til sunde alternative forbindelser. Hvad vi gør for at forhindre det i at ske igen: Automatisering link dræning baseret på CRC fejltærskler, forbedre protokoller til isolering flapping leverandør links, og hærder upload modstandsdygtighed.
Automatisk oversat fra den officielle hændelsesopdatering.
Mellem 12: 05 UTC og 12: 35 UTC oplevede vi en høj fejlfrekvens og længere sessionstider for Desktop og Virtual Device test i US- West-1 datacentret. Spørgsmålet er løst. Alle tjenester er fuldt operationelle.
### **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.
Automatisk oversat fra den officielle hændelsesopdatering.
Mellem 09: 52 UTC og 10: 34 UTC, flere Sauce Labs tjenester i US- West datacenter oplevede en afbrydelse, forårsager autentificering fejl og forstyrrelser til testfunktioner. Alle systemer er nu fuldt funktionsdygtige.
# # * * Datoer: * * Onsdag den 16. september 2026, 09: 51 UTC - 10: 35 UTC. Hvad skete der? Flere Sauce Labs tjenester tilgængelighed gradvist faldt i US- West-1 datacenter. De berørte tjenester omfattede: * Authentication\ (sign-in, SSO, eksisterende sessioner, og sign-up\) * Virtuel enhed Cloud\ (VDC\) * Real Device Cloud\ (RDC\) * Sauce Connect * REST API * App Storage * Insights * Sauce Visual * Test komponist * Bruger- og teamhåndtering * faktureringsplaner og brug API Hvorfor skete det? En implementering af Authentication service udløste en uventet bølge af databaseforbindelser, forårsager autentificering fejl og forstyrre flere Sauce Labs tjenester. Hvordan vi ordnede det: Genstartet den berørte databaseknude. Hvad vi gør for at forhindre det i at ske igen: Forbedre udrulningsstrategier, forbindelse livscyklusstyring, failover mekanismer, og sundhedstjek lydhørhed.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi ser forhøjede fejlrater for Real Device tests i EU- Central-1 datacenter. Vi efterforsker det.
Den grundlæggende årsag til de forhøjede fejlrater for Real Device test i EU- Central-1 datacenter er blevet identificeret. Der er foretaget en sanering, og vi overvåger aktivt situationen.
Efter at have taget afhjælpende foranstaltninger, Real Device test fejlrater er vendt tilbage til normal i EU-Central-1 datacenter. Alle tjenester er fuldt operationelle.
* * Datoer: * * Onsdag den 2. september 2026, 08: 30 UTC - 11: 15 UTC. Hvad skete der? Real Device Automated Tests oplevede manglende start i EU 's centrale datacenter, hvor de forhøjede fejlrater nåede op på næsten 100% i korte perioder. Hvorfor skete det? En implementering førte til øget cache savner og forhøjet belastning på den underliggende infrastruktur. Hvordan vi ordnede det: Tjenesten blev genoprettet ved at genstarte programmet. Hvad vi gør for at forhindre det i at ske igen: Der blev afsat yderligere ressourcer til at mindske sandsynligheden for en gentagelse på kort sigt. På lang sigt vil vi optimere ressourceintensive opgavers ydeevne og indføre dynamisk skalering.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi ser i øjeblikket forhøjede fejlrater for macOS og iOS tests i US- West-1 datacenter. Vi er ved at undersøge sagen.
Efter at have taget afhjælpende foranstaltninger, er alle macOS og iOS test nu udføres som forventet i US- West-1 Data center. Alle tjenester er fuldt operationelle.
# # * * Datoer: * * Tirsdag den 25. august 2026, 11: 38 - 13: 10 UTC Hvad skete der? Kunder, der kører macOS og iOS tests i vores US- West region oplevet forringet service. Omkring 50% af den virtuelle Mac kapacitet i regionen stoppede acceptere nye tests, så test enten i kø eller undladt at starte. Resterende kapacitet kom under yderligere pres, da arbejdet skiftede til det, som udvidede starttider for både desktop og simulator test. Hvorfor skete det? En intern sikkerhed certifikat, der anvendes af vores Mac værter til at nå en understøttende cloud-service nåede sin udløbsdato. Når det er udløbet, værterne kunne ikke længere etablere en betroet forbindelse til denne tjeneste og stoppede levering af nye testmaskiner. Certifikatet var blevet udstedt manuelt og havde hverken automatiseret fornyelse eller udløbsvarsling. Hvordan vi ordnede det: Vi har udstedt og indsat en erstatning certifikat, som genoprettet forbindelse og returneret Mac kapacitet til normale niveauer. Hvad vi gør for at forhindre det i at ske igen: Vi flytter disse certifikater til automatiseret fornyelse og tilføjer alarmering, så de er erstattet godt før udløb, sammen med gennemgang af det omgivende værktøj til at gøre certifikathåndtering sikrere.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi ser i øjeblikket forhøjede fejlrater for virtuelle desktop tests i US- West-1 datacenter. Vi er ved at undersøge sagen.
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.
Automatisk oversat fra den officielle hændelsesopdatering.
Mellem 16. juli 13: 03 UTC og 16. juli 17: 33 UTC oplevede vi en afbrydelse af tjenesten, hvor symbolarkiver, der benytter flerdelte uploadprotokoller, ikke kunne behandles. Hændelsen er blevet løst, og alle tjenester er operationelle.
### **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.
Automatisk oversat fra den officielle hændelsesopdatering.
Mellem 14. juli 23: 45 UTC og 15. juli 23: 05 UTC, oplevede vi et problem, hvor symbol arkiv uploads til Backtrace projekter mislykkedes med HTTP 400 fejl. Hændelsen er blevet løst, og alle tjenester er operationelle.
### **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.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi oplever et problem i EU Central 1 datacenter, hvor iOS ARM Simulator app tests mislykkes med infrastrukturfejl. Vi efterforsker det.
App downloads tager længere tid end forventet, når disse infrastrukturfejl ses. Vi fortsætter med at undersøge.
Vi har udsendt et fix for dette spørgsmål. Test bør nu udføres som forventet i EU 's centrale datacenter. Vi overvåger.
Vi fortsætter med at overvåge for yderligere spørgsmål.
Efter at have truffet afhjælpende foranstaltninger og overvåget situationen, vi ser iOS ARM applikationstest udføre som forventet i EU Data Center. Alle tjenester er fuldt operationelle.
# # * * Datoer: * * Tirsdag den 14. juli 2026, 09: 00 - 18: 28 UTC Hvad skete der? iOS ARM test kører i vores EU datacenter mislykkedes. Hvorfor skete det? Der opstod en fejl hos vores primære netværksudbyder i vores EU-datacenter. Hvordan vi ordnede det: Vi fejlede over til en sekundær netværksudbyder fra vores EU datacenter. Hvad vi gør for at forhindre det i at ske igen: Vi har forbedret vores overvågning og alarmering for at fange problemer med tredjeparts netværksudbydere.
Automatisk oversat fra den officielle hændelsesopdatering.
Den 1. juli mellem 17: 02 UTC og 21: 31 UTC, macOS 14 test var ikke at starte i US- West og EU-Central datacentre. Dette spørgsmål er blevet løst. Alle tjenester er fuldt operationelle.
# # * * Datoer: * * Onsdag den 1. juli 2026, 17: 02 UTC - 21: 31 UTC Hvad skete der? MacOS 14 tests i USA West og EU Central datacentre var ude af stand til at starte. Hvorfor skete det? En intern database var ikke tilgængelig på grund af en manglende konfiguration indgang. Hvordan vi ordnede det: Den manglende post blev erstattet. Hvad vi gør for at forhindre det i at ske igen: Der er blevet indført beskyttelsesforanstaltninger for at forhindre, at de anvendte data fjernes fra konfigurationen.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi oplever et problem med adgang til Appium Inspector i US- West-1, EU- Central-1, og US- East-4 datacentre. Vi efterforsker det.
Vi har identificeret den grundlæggende årsag og har indsat en rettelse til dette spørgsmål. Alle tjenester er fuldt operationelle.
# # * * Datoer: * * Onsdag den 1. juli 2026, 09: 37 - 12: 46 UTC Hvad skete der? Funktionen Appium Inspector, der blev brugt under virkelige live-testsessioner, blev ikke tilgængelig efter en planlagt UI implementering. Brugere, der forsøgte at bruge funktionen under en live test blev præsenteret for en 500 fejl, forstyrre deres aktive test session. Automatiske testrørledninger blev ikke påvirket. Hvorfor skete det? En rutinemæssig opgradering af en kerne frontend bibliotek indført en uforenelighed med Appium inspektørs rendering logik. Den tidligere biblioteksversion tolererede mønsteret, men den opdaterede version gjorde det ikke. Spørgsmålet blev ikke fanget før ibrugtagning på grund af utilstrækkelig end-to-end test dækning for denne specifikke funktion. Hvordan vi ordnede det: Vi rullede tilbage UI til den sidst kendte arbejdsversion for at gendanne funktionen straks, og derefter indsat en målrettet fix for uforenelighed. Hvad vi gør for at forhindre det i at ske igen: Vi tilføjer end- to- end test dækning for Appium Inspector funktion for at sikre, at det valideres automatisk før fremtidige installationer.
Automatisk oversat fra den officielle hændelsesopdatering.
Den 24. juni mellem 08: 28 UTC og 15: 32 UTC, oplevede vi Real Device test session fejl påvirker Appium og Access API i USA East, US West og EU datacentre. Dette spørgsmål er blevet løst. Alle tjenester er fuldt operationelle.
# # * * Datoer: * * Onsdag den 24. juni 2026, 09: 42 UTC - 15: 45 UTC. Hvad skete der? Real Device test sessioner med Appium og Access API oplevede øgede fejlrater i USA øst, USA vest og EU datacentre. Sessioner var timing ud efter ca. 90 sekunder eller at blive hængende i "Connecting" tilstand, forhindrer dem i at blive lukket. Hvorfor skete det? En produktdefekt blev indført, hvilket får Real Device testsessioner til ikke at starte og forhindre aktive sessioner i at blive lukket. Hvordan vi ordnede det: Rollback til en stabil version. Hvad vi gør for at forhindre det i at ske igen: Forbedre overvågning og alarmering og forbedre validering efter ibrugtagning.
Automatisk oversat fra den officielle hændelsesopdatering.
Omkring 3: 51 UTC begyndte vi at opleve lavere iOS-enhed tilgængelighed i EU-Central datacenter. Vores team undersøger aktivt årsagen og arbejder hen imod en løsning.
Vi har oplevet enhedens manglende tilgængelighed i vores EU- Central-1 datacenter og har identificeret årsagen hertil. Vi har truffet afhjælpende foranstaltninger og overvåger i øjeblikket.
Efter at have taget afhjælpende foranstaltninger, er vi nu se reelle enheder til rådighed til test i EU-Central-1 datacenter. Alle tjenester er fuldt operationelle.
# # * * Datoer: * * Torsdag den 18. juni 2026, 03: 45 UTC - 06: 45 UTC. Hvad skete der? Omkring 7% af iOS-enheder i vores EU datacenter var midlertidigt ikke tilgængelige for kundetest sessioner efter et tab af strøm til rack hosting dem. Hvorfor skete det? Strømkredsløbet fodring den berørte rack overskredet sin kapacitet, og en beskyttende breaker tripped for at beskytte linjen - skære magt til de enheder på rack indtil kredsløbet blev genoprettet. Hvordan vi ordnede det: Det berørte kredsløb blev nulstillet og strøm genoprettet til rack, returnere enheder til kundeservice. Hvad vi gør for at forhindre det i at ske igen: Vi omfordeler strømbelastningen på tværs af berørte stativer, tilføjer kapacitetskontrol med tidlige advarsler forud for kredsløbsgrænser, og indfører en kapacitetskontrol, før nye enheder sættes på en rack.
Automatisk oversat fra den officielle hændelsesopdatering.
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.
