67 incidente Sauce Labs înregistrate începând din noiembrie 2024, cu actualizări oficiale, componente afectate, durată și informații despre rezolvare.
La 13 octombrie, între 05:10 UTC și 05:45 UTC, am experimentat rate ridicate de eroare pentru serviciile VDC, RDC, Sauce Connect și IPSec în centrul de date US-Vest-1. Problema a fost rezolvată. Toate serviciile sunt acum pe deplin operaționale.
Traducere automată din actualizarea oficială a incidentului.
Ne confruntăm cu o problemă cu IU-ul de la Sauce Labs în centrul de date UE-Central-1. Investigăm.
Încă ne confruntăm cu probleme legate de IU-ul Sauce Labs în centrul de date UE-Central-1. Continuăm să investigăm.
Am făcut progrese în ceea ce privește restrângerea cauzei problemelor actuale legate de IU-urile de la Sauce Labs în centrul de date UE-Central-1. Ancheta este în curs de desfășurare.
Lucrăm îndeaproape cu furnizorii noștri terți pentru a rezolva problema actuală din centrul de date UE-Central-1. Ancheta este în curs de desfășurare.
Continuăm să colaborăm cu partenerii noștri și cu echipele relevante pentru a investiga și rezolva problema actuală din centrul de date UE-Central-1. Vom împărtăși actualizări suplimentare pe măsură ce mai multe informații devin disponibile.
Cauza principală a problemei care afectează accesul nostru la UI în UE-Central-1 este legată de un incident continuu cu unul dintre furnizorii noștri de infrastructură terți din centrul de date. În timp ce echipa noastră ține acest bilet incident închis la sfârșitul nostru, urmărim activ investigația în curs a furnizorului și va monitoriza îndeaproape performanța.
Traducere automată din actualizarea oficială a incidentului.
Ne confruntăm cu o degradare a ingestiei de erori pentru raportarea erorilor (Backtrace) folosind shriffpad pe Android și Linux pe toate centrele de date. În prezent investigăm.
Continuăm să investigăm această problemă.
Cauza principală a ingestiei de erori pentru raportarea erorilor (Backtrace) a fost identificată. Remediarea a fost aplicată și monitorizăm în mod activ situația.
După luarea de măsuri de remediere, problema ingestiei de erori în raportarea erorilor (Backtrace) a fost rezolvată. Toate serviciile sunt pe deplin operaționale.
Traducere automată din actualizarea oficială a incidentului.
În prezent vedem rate ridicate de eroare pentru testele reale ale dispozitivelor în centrul de date UE-Central-1. Investigăm.
Ratele de eroare reale de încercare a dispozitivului au revenit la normal în centrul de date UE-Central-1. Toate serviciile sunt pe deplin operaționale.
Traducerea şi adaptarea: Miercuri, 30 septembrie 2026, 09:04 UTC - 10:49 UTC. Ce s-a întâmplat? Testele automate cu dispozitive reale au eșuat la pornirea în centrul central de date al UE, ratele de eroare ajungând până la 25%. De ce s-a întâmplat: O desfăşurare a condus la rate mari de cache şi la sarcini ridicate pe infrastructura de bază. Cum am reparat-o: Serviciul a fost restaurat prin rularea înapoi la o versiune anterioară. Ce facem pentru a preveni să se întâmple din nou: Se consideră că strategiile alternative de cache cresc eficacitatea cache-ului.
Traducere automată din actualizarea oficială a incidentului.
În prezent vedem rate ridicate de eroare pentru testele automate de dispozitiv real în centrul de date US-West-1. În prezent investigăm.
Cauza principală a ratelor ridicate de eroare pentru testele Real Device în centrul de date US-West-1 a fost identificată. Remediarea a fost aplicată și monitorizăm în mod activ situația.
După ce au luat măsuri de remediere, ratele de eroare de încercare Real Device au revenit la normal în centrul de date US-West-1. Toate serviciile sunt pe deplin operaționale.
Traducerea şi adaptarea: Luni, 28 septembrie 2026, 14:19 UTC - 16:52 UTC. Ce s-a întâmplat? Teste reale de dispozitiv în US West atârnat și nu a reușit să de ieșire artefacte de testare din cauza încărcări lente. De ce s-a întâmplat: O legătură de interconectare degradată a suferit pierderi mari de pachete din cauza erorilor optice, dar BBP a rămas treaz, prevenind eșecul automat către căi sănătoase. Cum am reparat-o: A dezactivat manual portul degradat de pe router-ul margine, forțând traficul pe interconectări alternative sănătoase. Ce facem pentru a preveni să se întâmple din nou: Veriga automata se scurge pe baza pragurilor de eroare CRC, imbunatatirea protocoalelor pentru izolarea linkurilor de vanzator, si intarirea rezistentei la incarcare.
Traducere automată din actualizarea oficială a incidentului.
Între 12:05 UTC și 12:35 UTC, am experimentat o rată de eroare ridicată și perioade mai lungi de începere a sesiunii pentru testele Desktop și Virtual Device în centrul de date US-West-1. Problema a fost rezolvată. Toate serviciile sunt pe deplin operaționale.
### **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.
Traducere automată din actualizarea oficială a incidentului.
Între 09:52 UTC și 10:34 UTC, mai multe servicii de Sauce Labs în centrul de date SUA-Vest a experimentat o pană de curent, cauzând defecțiuni de autentificare și întreruperi ale caracteristicilor de testare. Toate sistemele sunt acum complet operaţionale.
Traducerea şi adaptarea: Miercuri, 16 septembrie 2026, 09:51 UTC - 10:35 UTC. Ce s-a întâmplat? Disponibilitatea mai multor sos Labs servicii a scăzut treptat în centrul de date US-West-1. Serviciile afectate includ: * Autentificare \ [semnat-in, SSO, sesiuni existente, și sign-up\) * Virtual Device Cloud \ (VDC\) * Real Device Cloud \ (RDC\) * Sos Connect * REST API * App Storage * Insights * Sauce Visual * Test Compozitor * User and Team Management * Billing Plans and Usage API De ce s-a întâmplat: O implementare a serviciului de autentificare a declanșat o creștere neașteptată a conexiunilor de baze de date, cauzând eșecuri de autentificare și perturbarea mai multor servicii de Laboratoare de Sauce. Cum am reparat-o: Am repornit nodul de bază afectat. Ce facem pentru a preveni să se întâmple din nou: Îmbunătățește strategiile de implementare, gestionarea ciclului de viață de conectare, mecanismele de eșuare și capacitatea de reacție a controalelor de sănătate.
Traducere automată din actualizarea oficială a incidentului.
Vedem rate ridicate de eroare pentru testele Real Device în centrul de date UE-Central-1. Investigăm.
Cauza principală a ratelor ridicate de eroare pentru testele Real Device în centrul de date UE-Central-1 a fost identificată. Remediarea a fost aplicată și monitorizăm în mod activ situația.
După ce au luat măsuri de remediere, ratele de eroare de încercare Real Device au revenit la normal în centrul de date UE-Central-1. Toate serviciile sunt pe deplin operaționale.
**Dates:** Miercuri, 2 septembrie 2026, 08:30 UTC - 11:15 UTC. Ce s-a întâmplat? Testele automate cu dispozitive reale s-au confruntat cu eșecul de a începe în centrul de date central al UE, ratele ridicate de eroare atingând aproape 100% pentru perioade scurte de timp. De ce s-a întâmplat: O desfăşurare a condus la rate mari de cache şi la sarcini ridicate pe infrastructura de bază. Cum am reparat-o: Serviciul a fost restaurat prin repornirea aplicației. Ce facem pentru a preveni să se întâmple din nou: Au fost alocate resurse suplimentare pentru a reduce probabilitatea reapariției pe termen scurt. Pe termen lung, vom optimiza performanța sarcinilor intensive de resurse și vom introduce scalarea dinamică.
Traducere automată din actualizarea oficială a incidentului.
În prezent vedem rate ridicate de eroare pentru testele MacOS și iOS în centrul de date US-West-1. În prezent investigăm.
După ce au luat măsuri de remediere, toate testele MacOS şi iOS sunt acum efectuate conform aşteptărilor în centrul de date US-West-1. Toate serviciile sunt pe deplin operaționale.
Traducerea şi adaptarea: Marţi, 25 august 2026, 11:38, 13:10 Ce s-a întâmplat? Clienţii care efectuează teste MacOS şi iOS în regiunea noastră SUA-Vest au avut servicii degradate. Aproximativ 50% din capacitatea virtuală Mac în regiune a încetat să mai accepte noi teste, astfel încât testele fie coadă sau nu a reușit să înceapă. Capacitatea rămasă a fost supusă unei presiuni suplimentare pe măsură ce munca a trecut pe ea, ceea ce a prelungit timpul de pornire atât pentru testele de birou cât și pentru simulatoare. De ce s-a întâmplat: Un certificat intern de securitate folosit de gazdele noastre Mac pentru a ajunge la un serviciu de sprijin cloud a ajuns la data de expirare. Odată ce a expirat, gazdele nu mai puteau stabili o legătură de încredere cu acest serviciu și nu mai puteau furniza noi mașini de testare. Certificatul a fost eliberat manual și nu a avut nici reînnoire automată și nici alertă de expirare. Cum am reparat-o: Am emis și implementat un certificat de înlocuire, care a restaurat conectivitatea și a returnat capacitatea Mac la niveluri normale. Ce facem pentru a preveni să se întâmple din nou: Mutăm aceste certificate în reînnoirea automată și adăugăm alertarea astfel încât acestea să fie înlocuite cu mult înainte de expirare, împreună cu revizuirea instrumentelor din jur pentru a asigura siguranța manipulării certificatelor.
Traducere automată din actualizarea oficială a incidentului.
Vedem în prezent rate ridicate de eroare pentru testele virtuale desktop în US-West-1 datacenter. În prezent investigăm.
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.
Traducere automată din actualizarea oficială a incidentului.
Între 16 iulie 13:03 UTC și 16 iulie 17:33 UTC, am experimentat o perturbare a serviciilor în care arhivele cu simboluri care utilizau protocoale de încărcare cu mai multe părți nu au reușit să proceseze. Incidentul a fost rezolvat și toate serviciile sunt operaționale.
### **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.
Traducere automată din actualizarea oficială a incidentului.
Între 14 iulie 23:45 UTC şi 15 iulie 23:05 UTC, am avut o problemă în care arhiva de simboluri se încarcă la proiectele Backtrace a eşuat cu erori HTTP 400. Incidentul a fost rezolvat și toate serviciile sunt operaționale.
### **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.
Traducere automată din actualizarea oficială a incidentului.
Ne confruntăm cu o problemă în centrul de date central al UE 1, unde testele de aplicații iOS ARM Simulator nu reușesc să facă față erorilor de infrastructură. Investigăm.
Descărcările de aplicații durează mai mult decât se preconizează atunci când se observă aceste erori de infrastructură. Continuăm să investigăm.
Am implementat o soluţie pentru această problemă. Testele ar trebui să aibă loc acum, după cum se prevede în centrul de date central al UE 1. Suntem de monitorizare.
Continuăm să monitorizăm orice alte probleme.
După ce am luat măsuri de remediere şi am monitorizat situaţia, vedem că testele de aplicaţie iOS ARM se desfăşoară conform aşteptărilor din cadrul Centrului de Date al UE. Toate serviciile sunt pe deplin operaționale.
Traducerea şi adaptarea: Marţi, 14 iulie 2026, 09:00 - 18:28 UTC Ce s-a întâmplat? Testele IOS ARM efectuate în centrul nostru de date UE au eșuat. De ce s-a întâmplat: S-a produs o eroare în ceea ce privește furnizorul principal de rețele din centrul nostru de date din UE. Cum am reparat-o: Am eşuat în faţa unui furnizor secundar de reţea de la centrul nostru de date din UE. Ce facem pentru a preveni să se întâmple din nou: Ne-am îmbunătăţit monitorizarea şi alertarea cu privire la problemele de captură cu furnizorii de reţea terţi.
Traducere automată din actualizarea oficială a incidentului.
La 1 iulie între orele 17:02 UTC şi 21:31 UTC, testele MacOS 14 nu au început în centrele de date US-Vest şi UE-Central. Această problemă a fost rezolvată. Toate serviciile sunt pe deplin operaționale.
### **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.
Traducere automată din actualizarea oficială a incidentului.
Avem o problemă cu accesarea Inspectorului Appium în centrele de date US-Vest-1, UE-Central-1, și SUA-Est-4. Investigăm.
Am identificat cauza principală şi am implementat o soluţie pentru această problemă. Toate serviciile sunt pe deplin operaționale.
Traducerea şi adaptarea: Miercuri, 1 iulie 2026, 09:37, 12:46 Ce s-a întâmplat? Funcţia Inspectorului Appium, folosită în timpul sesiunilor de testare în direct a dispozitivului real, a devenit indisponibilă după o desfăşurare programată a UI. Utilizatorii care au încercat să folosească funcția în timpul unui test live au fost prezentați cu o eroare de 500, perturbăndu-și sesiunea de testare activă. Conductele automate de testare nu au fost afectate. De ce s-a întâmplat: O actualizare de rutină a unei biblioteci de bază a introdus o incompatibilitate cu logica de redare a inspectorului Appium. Versiunea anterioară a bibliotecii tolera modelul, dar versiunea actualizată nu. Problema nu a fost abordată înainte de desfășurare din cauza acoperirii insuficiente a testelor la sfârșit pentru această caracteristică specifică. Cum am reparat-o: Ne-am rostogolit înapoi UI la ultima versiune de lucru cunoscut pentru a restabili funcția imediat, și apoi a implementat un fix vizat pentru incompatibilitate. Ce facem pentru a preveni să se întâmple din nou: Adăugăm o acoperire de testare de la un capăt la altul pentru caracteristica Inspectorului Appium pentru a se asigura că aceasta este validată automat înainte de implementarea viitoare.
Traducere automată din actualizarea oficială a incidentului.
Pe 24 iunie, între 08:28 UTC şi 15:32 UTC, am experimentat eşecuri la sesiunea de testare Real Device care au afectat Appium şi Access API în centrele de date din estul SUA, vestul SUA şi UE. Această problemă a fost rezolvată. Toate serviciile sunt pe deplin operaționale.
Traducerea şi adaptarea: Miercuri, 24 iunie 2026, 09:42 UTC - 15:45 UTC. Ce s-a întâmplat? Sesiuni de testare Real Device folosind Appium and Access API au înregistrat rate de eroare crescute în centrele de date din Estul SUA, Vestul SUA și UE. Sesiunile s-au sincronizat după aproximativ 90 de secunde sau au rămas blocate în starea "Conectare," împiedicându-le să fie închise. De ce s-a întâmplat: A fost introdus un defect al produsului, ceea ce a făcut ca sesiunile de testare Real Device să nu înceapă și să împiedice închiderea sesiunilor active. Cum am reparat-o: Întoarce-te la o versiune stabilă. Ce facem pentru a preveni să se întâmple din nou: Să îmbunătățească monitorizarea și alertarea și să îmbunătățească validarea post-punere în aplicare.
Traducere automată din actualizarea oficială a incidentului.
În jur de 3:51 AM UTC am început să experimentăm o disponibilitate mai scăzută a dispozitivelor iOS în centrul de date central UE. Echipa noastră investighează în mod activ cauza fundamentală și lucrează spre o rezoluție.
Ne-am confruntat cu indisponibilitatea dispozitivelor în centrul nostru de date UE-Central-1 și am identificat cauza principală. Am luat măsuri de remediere și în prezent monitorizăm.
După ce luăm măsuri de remediere, vedem acum dispozitive reale disponibile pentru testare în centrul de date UE-Central-1. Toate serviciile sunt pe deplin operaționale.
Traducerea şi adaptarea: Joi, 18 iunie 2026, 03:45 UTC - 06:45 UTC. Ce s-a întâmplat? Aproximativ 7% din dispozitivele iOS din centrul nostru de date din UE nu au fost disponibile temporar pentru sesiunile de testare a clienților, după o pierdere de putere la raftul care le găzduiește. De ce s-a întâmplat: Circuitul de alimentare cu energie al raftului afectat i - a depăşit capacitatea, iar un întrerupător de protecţie s - a împiedicat pentru a proteja puterea de tăiere a liniei de dispozitivele de pe acel raft până când circuitul a fost restabilit. Cum am reparat-o: Circuitul afectat a fost resetat, iar alimentarea a fost repusă în rack, returnând dispozitivele serviciului clienţilor. Ce facem pentru a preveni să se întâmple din nou: Redistribuim sarcina electrică pe rafturile afectate, adăugând monitorizarea capacității cu alerte de avertizare timpurie înaintea limitelor de circuit și introducând o revizuire a capacității înainte ca noile dispozitive să fie instalate pe un suport.
Traducere automată din actualizarea oficială a incidentului.
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.
