67 Sauce Labs incidents · novembre 2024 — official updates, affected components, duration and resolution details.
Il 13 ottobre, tra 05:10 UTC e 05:45 UTC, abbiamo sperimentato elevati tassi di errore per i servizi VDC, RDC, Sauce Connect e IPSec nel data center US-West-1. Il problema è stato risolto. Tutti i servizi sono ora pienamente operativi.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Stiamo vivendo un problema con l'UI Sauce Labs nel centro dati EU-Central-1. Stiamo indagando.
Stiamo ancora vivendo problemi con l'UI di Sauce Labs nel centro dati EU-Central-1. Stiamo continuando a indagare.
Abbiamo fatto progressi nel restringere la causa dei problemi in corso di Sauce Labs UI nel data center EU-Central-1. L'indagine è in corso.
Lavoriamo a stretto contatto con i nostri fornitori di terze parti per risolvere il problema in corso nel data center EU-Central-1. L'indagine è in corso.
Stiamo continuando a lavorare con i nostri partner e i team rilevanti per indagare e risolvere il problema in corso nel data center EU-Central-1. Condivideremo ulteriori aggiornamenti in quanto ulteriori informazioni saranno disponibili.
La causa principale del problema che riguarda il nostro accesso all'interfaccia utente nell'UE-Central-1 è legata ad un incidente in corso con uno dei nostri fornitori di infrastrutture di terze parti nel data center. Mentre il nostro team sta mantenendo questo biglietto incidente chiuso alla nostra fine, stiamo monitorando attivamente l'indagine in corso del fornitore e monitoreremo le prestazioni da vicino.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Stiamo sperimentando un degrado nell'ingestione degli errori per il Reporting degli errori (Backtrace) utilizzando crashpad su Android e Linux attraverso tutti i Data Center. Stiamo indagando.
Stiamo continuando a indagare su questo problema.
È stata identificata la causa principale dell'ingestione degli errori per il Reporting degli errori (Backtrace). La bonifica è stata applicata e stiamo monitorando attivamente la situazione.
Dopo aver preso l'azione correttiva, è stato risolto il problema di ingestione di errore nel Reporting degli errori (Backtrace). Tutti i servizi sono completamente operativi.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Attualmente stiamo vedendo elevati tassi di errore per i test reali dei dispositivi nel data center EU-Central-1. Stiamo indagando.
I tassi di errore del test del dispositivo reale sono tornati alla normalità nel centro dati EU-Central-1. Tutti i servizi sono completamente operativi.
#### **Dates:** mercoledì 30 settembre 2026, 09:04 UTC - 10:49 UTC. # Che e' successo? # Real Device Test automatizzati hanno sperimentato il mancato avvio nel centro dati EU Central, con tassi di errore fino al 25%. # Perche' e' successo # Una distribuzione ha portato ad aumentare la cache manca e un carico elevato sull'infrastruttura sottostante. #### **Come l'abbiamo riparato? Il servizio è stato ripristinato tornando a una versione precedente. #### **Quello che stiamo facendo per impedire che accada di nuovo # Si stanno prendendo in considerazione strategie di cache alternative per aumentare l'efficacia della cache.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Attualmente stiamo vedendo elevati tassi di errore per test di dispositivo reale automatizzati nel data center US-West-1. Stiamo indagando.
La causa principale dei tassi di errore elevati per i test del dispositivo reale nel data center US-West-1 è stata identificata. La bonifica è stata applicata e stiamo monitorando attivamente la situazione.
Dopo aver preso l'azione correttiva, i tassi di errore di prova del dispositivo reale sono tornati alla normalità nel data center US-West-1. Tutti i servizi sono completamente operativi.
#### **Dates:** lunedì 28 settembre 2026, 14:19 UTC - 16:52 UTC. # Che e' successo? # Test reali del dispositivo in US West appeso e non riuscito a produrre artefatti di prova a causa di carichi lenti. # Perche' e' successo # Un collegamento interconnesso degradato ha subito un'elevata perdita di pacchetti da errori ottici, ma BGP è rimasto in piedi, impedendo il failover automatico a percorsi sani. #### **Come l'abbiamo riparato? Disabilita manualmente la porta degradata sul router bordo, costringendo il traffico a interconnessioni alternative sane. #### **Quello che stiamo facendo per impedire che accada di nuovo # Automatizzazione dello scarico del collegamento in base alle soglie di errore CRC, miglioramento dei protocolli per l'isolamento dei link del fornitore di pattinaggio e l'indurimento della resilienza di upload.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Tra 12:05 UTC e 12:35 UTC, abbiamo sperimentato un alto tasso di errore e tempi di avvio di sessione più lunghi per i test del desktop e del dispositivo virtuale nel data center US-West-1. Il problema è stato risolto. Tutti i servizi sono completamente operativi.
### **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.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Tra le 09:52 UTC e 10:34 UTC, più servizi di Sauce Labs nel data center USA-Ovest hanno sperimentato un outage, causando guasti di autenticazione e interruzioni alle funzioni di test. Tutti i sistemi sono ora pienamente operativi.
#### **Dates:** mercoledì 16 settembre 2026, 09:51 UTC - 10:35 UTC. # Che e' successo? # La disponibilità dei servizi di Sauce Labs multipli è diminuita gradualmente nel data center US-West-1. I servizi interessati inclusi: * Autenticazione \(sign-in, SSO, sessioni esistenti, e sign-up\) * Virtual Device Cloud \(VDC\) * Real Device Cloud \(RDC\) * Collegamento di salsa * API REST * Deposito dell'app * Insights * Salsa visiva * Composer di prova * Gestione utente e team * Piani di fatturazione e API di utilizzo # Perche' e' successo # Una distribuzione del servizio di autenticazione ha innescato un imprevisto aumento delle connessioni del database, causando guasti di autenticazione e interrompendo più servizi Sauce Labs. #### **Come l'abbiamo riparato? Riavviare il nodo del database interessato. #### **Quello che stiamo facendo per impedire che accada di nuovo # Migliorare le strategie di rollout, la gestione del ciclo di vita di connessione, i meccanismi di failover e la reattività di controllo della salute.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Stiamo vedendo elevati tassi di errore per i test del dispositivo reale nel centro dati EU-Central-1. Stiamo indagando.
È stata identificata la causa principale dei tassi di errore elevati per i test dei dispositivi reali nel centro dati EU-Central-1. La bonifica è stata applicata e stiamo monitorando attivamente la situazione.
Dopo aver preso l'azione correttiva, i tassi di errore di prova del dispositivo reale sono tornati alla normalità nel data center EU-Central-1. Tutti i servizi sono completamente operativi.
**Date:** Mercoledì 2 settembre 2026, 08:30 UTC - 11:15 UTC. # Che e' successo? # Real Device Test automatizzati hanno sperimentato il mancato avvio nel centro dati EU Central, con elevati tassi di errore che raggiungono quasi il 100% per brevi periodi di tempo. # Perche' e' successo # Una distribuzione ha portato ad aumentare la cache manca e un carico elevato sull'infrastruttura sottostante. #### **Come l'abbiamo riparato? Il servizio è stato ripristinato riavviando l'applicazione. #### **Quello che stiamo facendo per impedire che accada di nuovo # Sono state assegnate ulteriori risorse per ridurre la probabilità di una ricorrenza a breve termine. A lungo termine, ottimizzaremo le prestazioni dei compiti intensivi delle risorse e introdurremo lo scaling dinamico.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Attualmente stiamo vedendo elevati tassi di errore per i test macOS e iOS nel data center US-West-1. Stiamo indagando.
Dopo aver preso l'azione correttiva, tutti i test macOS e iOS stanno ora eseguendo come previsto nel centro dati US-West-1. Tutti i servizi sono completamente operativi.
#### **Dates:** martedì 25 agosto 2026, 11:38 – 13:10 UTC # Che e' successo? # I clienti che eseguono test macOS e iOS nella nostra regione US-West hanno sperimentato il servizio degradato. Circa il 50% della capacità virtuale del Mac nella regione ha smesso di accettare nuovi test, quindi test in coda o non è riuscito a iniziare. La capacità rimanente è venuta sotto pressione aggiuntiva mentre il lavoro si è spostato su di esso, che ha prolungato i tempi di inizio sia per i test desktop che simulatore. # Perche' e' successo # Un certificato di sicurezza interno utilizzato dai nostri host Mac per raggiungere un servizio cloud di supporto raggiunto la data di scadenza. Una volta scaduto, i padroni di casa non potevano più stabilire una connessione affidabile a quel servizio e smettere di fornire nuove macchine di prova. Il certificato era stato rilasciato manualmente e non aveva né rinnovo automatizzato né avviso di scadenza. #### **Come l'abbiamo riparato? Abbiamo rilasciato e distribuito un certificato di sostituzione, che ha ripristinato la connettività e ha restituito la capacità Mac a livelli normali. #### **Quello che stiamo facendo per impedire che accada di nuovo # Stiamo spostando questi certificati sul rinnovo automatico e aggiungendo avvisi in modo che siano sostituiti ben prima della scadenza, insieme a rivedere gli strumenti circostanti per rendere la gestione del certificato più sicuro.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
We are currently seeing elevated error rates for virtual desktop tests in the US-West-1 datacenter. We are currently investigating.
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.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Tra il 16 luglio 13:03 UTC e il 16 luglio 17:33 UTC, abbiamo sperimentato una disgregazione di servizio in cui gli archivi dei simboli che utilizzano i protocolli di upload multi-part non sono riusciti a elaborare. L'incidente è stato risolto e tutti i servizi sono operativi.
### **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.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Tra il 14 luglio 23:45 UTC e il 15 luglio 23:05 UTC, abbiamo sperimentato un problema in cui l'archivio dei simboli carica su progetti Backtrace non è riuscito con errori HTTP 400. L'incidente è stato risolto e tutti i servizi sono operativi.
### **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.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Stiamo riscontrando un problema nel centro dati EU Central 1, dove i test dell'app iOS ARM Simulator non funzionano con errori di infrastruttura. Stiamo indagando.
I download delle applicazioni stanno prendendo più tempo del previsto quando questi errori di infrastruttura sono visti. Stiamo continuando a indagare.
Abbiamo implementato una soluzione per questo problema. I test dovrebbero ora essere eseguiti come previsto nel centro dati EU Central 1. Stiamo monitorando.
Stiamo continuando a monitorare eventuali ulteriori problemi.
Dopo aver preso l'azione correttiva e il monitoraggio della situazione, stiamo vedendo test applicativi iOS ARM eseguire come previsto nel Data Center UE. Tutti i servizi sono completamente operativi.
#### **Dates:** martedì 14 luglio 2026, 09:00 - 18:28 UTC # Che e' successo? # I test iOS ARM in esecuzione nel nostro data center UE non sono riusciti. # Perche' e' successo # Un difetto è avvenuto con il nostro principale fornitore di rete nel nostro centro dati UE. #### **Come l'abbiamo riparato? Non abbiamo superato un fornitore di rete secondaria dal nostro data center UE. #### **Quello che stiamo facendo per impedire che accada di nuovo # Abbiamo migliorato il nostro monitoraggio e l'avviso di prendere problemi con i fornitori di rete di terze parti.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Il 1 ° luglio tra 17:02 UTC e 21:31 UTC, macOS 14 test non sono stati in grado di iniziare nei data center US-West e EU-Central. Questo problema è stato risolto. Tutti i servizi sono completamente operativi.
### **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.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Stiamo vivendo un problema con l'accesso di Appium Inspector negli Stati Uniti-Ovest-1, EU-Central-1, e US-East-4 data center. Stiamo indagando.
Abbiamo identificato la causa principale e abbiamo implementato una correzione per questo problema. Tutti i servizi sono completamente operativi.
#### **Dates:** mercoledì 1 luglio 2026, 09:37 – 12:46 UTC # Che e' successo? # La funzione Appium Inspector, utilizzata durante le sessioni di test live del dispositivo reale, non è stata disponibile dopo una distribuzione UI programmata. Gli utenti che hanno tentato di utilizzare la funzione durante un test live sono stati presentati con un errore di 500, interrompendo la loro sessione di test attiva. I condotti di prova automatizzati non sono stati influenzati. # Perche' e' successo # Un aggiornamento di routine di una libreria core frontend ha introdotto un'incompatibilità con la logica di rendering dell'Appium Inspector. La versione precedente della libreria tollerava il modello, ma la versione aggiornata non lo ha fatto. Il problema non è stato catturato prima dell'implementazione a causa di insufficiente copertura di test end-to-end per questa funzione specifica. #### **Come l'abbiamo riparato? Abbiamo rirottato l'interfaccia utente all'ultima versione di lavoro nota per ripristinare immediatamente la funzionalità, e poi implementato una correzione mirata per l'incompatibilità. #### **Quello che stiamo facendo per impedire che accada di nuovo # Stiamo aggiungendo la copertura di test end-to-end per la funzione Appium Inspector per garantire che venga convalidata automaticamente prima delle implementazioni future.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Il 24 giugno tra le 08:28 UTC e le 15:32 UTC, abbiamo sperimentato guasti di sessione di test del dispositivo reale che influenzano Appium e Access API negli Stati Uniti Est, Stati Uniti Ovest e EU data center. Questo problema è stato risolto. Tutti i servizi sono completamente operativi.
#### **Dates:** mercoledì 24 giugno 2026, 09:42 UTC - 15:45 UTC. # Che e' successo? # Le sessioni di test dei dispositivi reali utilizzando Appium e Access API hanno registrato un aumento dei tassi di errore nei data center US East, US West e EU. Le sessioni erano tempistiche fuori dopo circa 90 secondi o rimanere bloccato nello stato "Connecting", impedendo loro di essere chiuso. # Perche' e' successo # È stato introdotto un difetto del prodotto, causando sessioni di test del dispositivo reale per non avviare e prevenire la chiusura delle sessioni attive. #### **Come l'abbiamo riparato? Rollback a una versione stabile. #### **Quello che stiamo facendo per impedire che accada di nuovo # Migliorare il monitoraggio e l'avviso e migliorare la convalida della distribuzione post.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Circa 3:51 AM UTC abbiamo iniziato a sperimentare la disponibilità del dispositivo iOS inferiore nel centro dati EU-Central. Il nostro team sta attivamente indagando sulla causa principale e lavorando verso una risoluzione.
Abbiamo sperimentato l'assenza di dispositivo nel nostro centro dati EU-Central-1 e abbiamo identificato la causa principale. Abbiamo preso un'azione correttiva e stiamo monitorando.
Dopo l'azione correttiva, stiamo ora vedendo dispositivi reali disponibili per il test nel centro dati EU-Central-1. Tutti i servizi sono completamente operativi.
#### **Dates:** giovedì 18 giugno 2026, 03:45 UTC - 06:45 UTC. # Che e' successo? # Circa il 7% dei dispositivi iOS nel nostro data center UE non era temporaneamente disponibile per le sessioni di test del cliente dopo una perdita di potenza per il rack che li ospita. # Perche' e' successo # Il circuito di alimentazione del rack interessato ha superato la sua capacità, e un interruttore di protezione triplicato per salvaguardare la linea - potenza di taglio ai dispositivi su quel rack fino a quando il circuito è stato ripristinato. #### **Come l'abbiamo riparato? Il circuito interessato è stato resettato e la potenza ripristinata al rack, riportando i dispositivi al servizio clienti. #### **Quello che stiamo facendo per impedire che accada di nuovo # Stiamo ridistribuendo il carico di potenza attraverso i rack interessati, aggiungendo il monitoraggio della capacità con avvisi di allarme anticipati prima dei limiti del circuito, e introducendo una revisione della capacità prima che i nuovi dispositivi vengano implementati su un rack.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
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.
