67 incidentes de Sauce Labs registrados desde noviembre de 2024, con actualizaciones oficiales, componentes afectados, duración y detalles de resolución.
El 13 de octubre, entre las 05:10 UTC y las 05:45 UTC, experimentamos tasas de error elevadas para los servicios VDC, RDC, Sauce Connect e IPSec en el centro de datos US-West-1. La cuestión se ha resuelto. Todos los servicios están en pleno funcionamiento.
Traducido automáticamente desde la actualización oficial del incidente.
Estamos experimentando un problema con la UI de Sauce Labs en el centro de datos UE-Central-1. Estamos investigando.
Todavía estamos experimentando problemas con la UI de Sauce Labs en el centro de datos UE-Central-1. Continuamos investigando.
Hemos avanzado en la reducción de la causa de los problemas actuales de la UI de Sauce Labs en el centro de datos UE-Central-1. La investigación está en curso.
Trabajamos estrechamente con nuestros proveedores de terceros para resolver el problema en curso en el centro de datos UE-Central-1. La investigación está en curso.
Continuamos trabajando con nuestros socios y equipos pertinentes para investigar y resolver el problema en curso en el centro de datos UE-Central-1. Compartiremos nuevas actualizaciones a medida que se disponga de más información.
La causa raíz del problema que afecta a nuestro acceso de la UI en la UE-Central-1 está vinculada a un incidente continuo con uno de nuestros proveedores de infraestructura de terceros en el centro de datos. Mientras nuestro equipo mantiene este ticket de incidentes cerrado en nuestro extremo, estamos rastreando activamente la investigación en curso del proveedor y supervisaremos el rendimiento de cerca.
Traducido automáticamente desde la actualización oficial del incidente.
Estamos experimentando una degradación en la ingestión de errores para la presentación de informes de errores (Backtrace) usando el bloqueo en Android y Linux en todos los centros de datos. Actualmente estamos investigando.
Seguimos investigando esta cuestión.
Se ha identificado la causa raíz de la ingestión de errores para la presentación de informes de errores. Se ha aplicado la rehabilitación y estamos monitoreando activamente la situación.
Tras tomar medidas correctivas, se ha resuelto el problema de la ingestión de errores en la presentación de informes de errores (Backtrace). Todos los servicios están en pleno funcionamiento.
Traducido automáticamente desde la actualización oficial del incidente.
Actualmente estamos viendo tasas de error elevadas para pruebas de dispositivos reales en el centro de datos EU-Central-1. Estamos investigando.
Las tasas de error de prueba de dispositivo real han vuelto a la normalidad en el centro de datos UE-Central-1. Todos los servicios están en pleno funcionamiento.
#### **Dates:** Miércoles 30 de septiembre 2026, 09:04 UTC - 10:49 UTC. #### ** What happened: ** Real Device Automated Tests experimentó un fallo en el centro de datos de la UE Central, con tasas de error alcanzando hasta un 25%. #### ** Why it happened:** Un despliegue dio lugar a una mayor falta de caché y una carga elevada en la infraestructura subyacente. ¿Cómo lo arreglamos? El servicio se restauró volviendo a una versión anterior. #### ** Lo que estamos haciendo para evitar que vuelva a suceder. Se están considerando estrategias alternativas de caché para aumentar la eficacia del caché.
Traducido automáticamente desde la actualización oficial del incidente.
Actualmente estamos viendo tasas de error elevadas para pruebas automatizadas de dispositivos reales en el centro de datos US-West-1. Actualmente estamos investigando.
Se ha identificado la causa raíz de las tasas de error elevadas para las pruebas de dispositivo real en el centro de datos EE.UU.-Oeste-1. Se ha aplicado la rehabilitación y estamos monitoreando activamente la situación.
Después de tomar la acción correctiva, las tasas de error de prueba Real Device han regresado a la normalidad en el centro de datos EE.UU.-Oeste-1. Todos los servicios están en pleno funcionamiento.
#### **Dates:** Lunes, 28 de septiembre 2026, 14:19 UTC - 16:52 UTC. #### ** What happened: ** Pruebas reales del dispositivo en el oeste de Estados Unidos colgaron y no lograron producir artefactos de prueba debido a cargas lentas. #### ** Why it happened:** Un enlace de interconexión degradado sufrió una alta pérdida de paquetes de errores ópticos, pero BGP se mantuvo en pie, evitando la falla automática a caminos saludables. ¿Cómo lo arreglamos? Desactiva manualmente el puerto degradado en el router de bordes, forzando el tráfico a interconexiones alternas saludables. #### ** Lo que estamos haciendo para evitar que vuelva a suceder. Automatizar el drenaje de enlaces basado en umbrales de error de CRC, mejorar protocolos para aislar los enlaces de proveedores de acoplamiento y endurecer la resiliencia de la carga.
Traducido automáticamente desde la actualización oficial del incidente.
Entre 12:05 UTC y 12:35 UTC, experimentamos una alta tasa de error y tiempos de inicio de sesión más largos para pruebas de escritorio y dispositivos virtuales en el centro de datos US-West-1. La cuestión se ha resuelto. Todos los servicios están en pleno funcionamiento.
### **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.
Traducido automáticamente desde la actualización oficial del incidente.
Entre las 09:52 UTC y las 10:34 UTC, varios servicios de Sauce Labs en el centro de datos de EE.UU.-Oeste experimentaron un outage, causando fallas de autenticación y perturbaciones a las características de prueba. Todos los sistemas están en pleno funcionamiento.
#### **Dates:** Miércoles, 16 de septiembre 2026, 09:51 UTC - 10:35 UTC. #### ** What happened: ** La disponibilidad de servicios de Sauce Labs disminuyó gradualmente en el centro de datos EE.UU.-Oeste-1. Los servicios afectados incluían: * Authentication \(sign-in, SSO, sesiones existentes, y registro\) * Virtual Device Cloud \(VDC\) * Nube de dispositivo real \(RDC\) * Sauce Connect * REST API * Almacenamiento de aplicaciones * Insights * Sauce Visual * Compositor de pruebas * Gestión de usuarios y equipos * Planes de facturación y API de uso #### ** Why it happened:** Un despliegue del servicio de autenticación provocó un aumento inesperado en las conexiones de bases de datos, causando fallas de autenticación e interrumpiendo múltiples servicios de Sauce Labs. ¿Cómo lo arreglamos? Reinició el nodo de base de datos afectado. #### ** Lo que estamos haciendo para evitar que vuelva a suceder. Mejorar las estrategias de despliegue, la gestión del ciclo de vida de conexión, los mecanismos de falla y la capacidad de respuesta del control de salud.
Traducido automáticamente desde la actualización oficial del incidente.
Estamos viendo tasas de error elevadas para pruebas de dispositivos reales en el centro de datos EU-Central-1. Estamos investigando.
Se ha identificado la causa raíz de las elevadas tasas de error para las pruebas de dispositivo real en el centro de datos UE-Central-1. Se ha aplicado la rehabilitación y estamos monitoreando activamente la situación.
Después de tomar medidas correctivas, las tasas de error de prueba Real Device han vuelto a ser normales en el centro de datos EU-Central-1. Todos los servicios están en pleno funcionamiento.
**Fechas:** Miércoles, 2 de septiembre de 2026, 08:30 UTC - 11:15 UTC. #### ** What happened: ** Pruebas Automatizadas de Dispositivos Reales experimentaron fallos en el centro de datos de la UE Central, con tasas de error elevadas alcanzando casi el 100% durante períodos cortos de tiempo. #### ** Why it happened:** Un despliegue dio lugar a una mayor falta de caché y una carga elevada en la infraestructura subyacente. ¿Cómo lo arreglamos? El servicio se restableció restarando la aplicación. #### ** Lo que estamos haciendo para evitar que vuelva a suceder. Se asignaron recursos adicionales para reducir la probabilidad de recurrencia a corto plazo. A largo plazo, optimizaremos el rendimiento de las tareas intensivas de recursos e introduciremos el escalado dinámico.
Traducido automáticamente desde la actualización oficial del incidente.
Actualmente estamos viendo tasas de error elevadas para las pruebas de macOS e iOS en el centro de datos US-West-1. Actualmente estamos investigando.
Después de tomar acción correctiva, todas las pruebas de macOS e iOS se están ejecutando como se espera en el centro de datos EE.UU.-Oeste-1. Todos los servicios están en pleno funcionamiento.
#### **Dates:** Martes 25 de agosto 2026, 11:38 – 13:10 UTC #### ** What happened: ** Los clientes que realizan pruebas de macOS e iOS en nuestra región de EE.UU.-Oeste experimentaron un servicio degradado. Aproximadamente el 50% de la capacidad virtual de Mac en la región dejó de aceptar nuevas pruebas, por lo que las pruebas ya sea apagadas o no comenzaron. La capacidad restante se sometió a presión adicional a medida que el trabajo se desplazaba hacia él, que extendía los tiempos de inicio tanto para pruebas de escritorio como simulador. #### ** Why it happened:** Un certificado de seguridad interno utilizado por nuestros anfitriones Mac para alcanzar un servicio de nube de apoyo alcanzó su fecha de vencimiento. Una vez caducado, los anfitriones ya no podían establecer una conexión de confianza con ese servicio y dejar de suministrar nuevas máquinas de prueba. El certificado se había expedido manualmente y no tenía renovación automática ni alerta de vencimiento. ¿Cómo lo arreglamos? Publicamos y desplegamos un certificado de reemplazo, que restauró la conectividad y devolvió la capacidad de Mac a niveles normales. #### ** Lo que estamos haciendo para evitar que vuelva a suceder. Estamos moviendo estos certificados a la renovación automatizada y añadiendo alertas para que sean reemplazados bien antes de la expiración, junto con revisar la herramienta circundante para hacer el manejo de certificado más seguro.
Traducido automáticamente desde la actualización oficial del incidente.
Actualmente estamos viendo tasas de error elevadas para pruebas de escritorio virtuales en el centro de datos US-West-1. Actualmente estamos investigando.
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.
Traducido automáticamente desde la actualización oficial del incidente.
Entre el 16 de julio 13:03 UTC y el 16 de julio de 17:33 UTC, experimentamos una interrupción del servicio donde los archivos de símbolos que utilizan protocolos de carga multiparte no se procesan. Se ha resuelto el incidente y todos los servicios están en funcionamiento.
### **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.
Traducido automáticamente desde la actualización oficial del incidente.
Entre el 14 de julio 23:45 UTC y el 15 de julio 23:05 UTC, experimentamos un problema donde los archivos de símbolos suben a los proyectos Backtrace fallaron con errores HTTP 400. Se ha resuelto el incidente y todos los servicios están en funcionamiento.
### **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.
Traducido automáticamente desde la actualización oficial del incidente.
Estamos experimentando un problema en el centro de datos EU Central 1, donde las pruebas de aplicación iOS ARM Simulator fallan con errores de infraestructura. Estamos investigando.
Las descargas de aplicaciones están tomando más tiempo de lo esperado cuando se ven estos errores de infraestructura. Continuamos investigando.
Hemos implementado una solución para esta cuestión. Los exámenes deben realizarse como se espera en el centro de datos de la UE Central 1. Estamos monitoreando.
Continuamos monitoreando cualquier otro problema.
Después de tomar medidas correctivas y monitorear la situación, estamos viendo que las pruebas de aplicación iOS ARM se realizan según lo previsto en el Centro de Datos de la UE. Todos los servicios están en pleno funcionamiento.
#### **Dates:** Martes 14 de julio 2026, 09:00 - 18:28 UTC #### ** What happened: ** Las pruebas de iOS ARM que se ejecutan en nuestro centro de datos de la UE fallaron. #### ** Why it happened:** Un error ocurrió con nuestro proveedor de red principal en nuestro centro de datos de la UE. ¿Cómo lo arreglamos? Fallamos a un proveedor de red secundario de nuestro centro de datos de la UE. #### ** Lo que estamos haciendo para evitar que vuelva a suceder. Hemos mejorado nuestro monitoreo y alerta para atrapar problemas con proveedores de red de terceros.
Traducido automáticamente desde la actualización oficial del incidente.
El 1 de julio entre 17:02 UTC y 21:31 UTC, las pruebas de macOS 14 no se iniciaron en los centros de datos estadounidenses-occidentales y UE-Central. Esta cuestión se ha resuelto. Todos los servicios están en pleno funcionamiento.
### **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.
Traducido automáticamente desde la actualización oficial del incidente.
Estamos experimentando un problema con el acceso de Inspector de Apium en los centros de datos EE.UU.-Oeste-1, EU-Central-1 y US-Este-4. Estamos investigando.
Hemos identificado la causa raíz y hemos implementado una solución para esta cuestión. Todos los servicios están en pleno funcionamiento.
#### **Dates:** Miércoles 1 de julio de 2026, 09:37 – 12:46 UTC #### ** What happened: ** La función del Inspector de Apium, utilizada durante las sesiones de pruebas en vivo de dispositivos reales, no estuvo disponible después de un despliegue programado de la UI. Los usuarios que intentaron utilizar la característica durante una prueba en vivo fueron presentados con un error de 500, alterando su sesión de pruebas activas. Los oleoductos de prueba automatizados no se vieron afectados. #### ** Why it happened:** Una actualización rutinaria de una biblioteca de frontend central introdujo una incompatibilidad con la lógica de renderización del Inspector de Apio. La versión anterior de la biblioteca toleraba el patrón, pero la versión actualizada no. La cuestión no se vio atrapada antes del despliegue debido a la insuficiente cobertura de pruebas de extremo a extremo para esta característica específica. ¿Cómo lo arreglamos? Volvimos la interfaz de usuario a la última versión conocida de trabajo para restaurar la característica inmediatamente, y luego desplegó una solución específica para la incompatibilidad. #### ** Lo que estamos haciendo para evitar que vuelva a suceder. Estamos añadiendo cobertura de prueba de extremo a extremo para la función del Inspector de Appium para asegurar que se valide automáticamente antes de futuros despliegues.
Traducido automáticamente desde la actualización oficial del incidente.
El 24 de junio entre las 08:28 UTC y 15:32 UTC, experimentamos fallos de sesión de prueba de dispositivos reales que impactan Appium y Access API en los centros de datos de EE.UU. Este, Oeste y UE. Esta cuestión se ha resuelto. Todos los servicios están en pleno funcionamiento.
#### **Dates:** Miércoles, 24 de junio 2026, 09:42 UTC - 15:45 UTC. #### ** What happened: ** Las sesiones de prueba de dispositivos reales utilizando Appium y Access API experimentaron mayores tasas de error en los centros de datos de EE.UU. Este, Oeste de EE.UU. y UE. Las sesiones fueron sincronizadas después de aproximadamente 90 segundos o quedar atrapados en el estado de "Connecting", impidiéndoles ser cerrados. #### ** Why it happened:** Se introdujo un defecto de producto, lo que hizo que las sesiones de prueba del dispositivo real no empezaran y evitar que se cerraran las sesiones activas. ¿Cómo lo arreglamos? Regrese a una versión estable. #### ** Lo que estamos haciendo para evitar que vuelva a suceder. Mejorar la vigilancia " alertar y mejorar la validación del despliegue posterior.
Traducido automáticamente desde la actualización oficial del incidente.
Alrededor de las 3:51 AM UTC empezamos a experimentar menor disponibilidad de dispositivos iOS en el centro de datos UE-Central. Nuestro equipo está investigando activamente la causa raíz y trabajando hacia una resolución.
Hemos estado experimentando la falta de disponibilidad de dispositivos en nuestro centro de datos UE-Central-1 y hemos identificado la causa raíz. Hemos tomado medidas correctivas y estamos monitoreando.
Después de tomar medidas correctivas, ahora estamos viendo dispositivos reales disponibles para la prueba en el centro de datos UE-Central-1. Todos los servicios están en pleno funcionamiento.
#### **Dates:** Jueves 18 de junio 2026, 03:45 UTC - 06:45 UTC. #### ** What happened: ** Aproximadamente el 7% de los dispositivos iOS en nuestro centro de datos de la UE no estaban disponibles temporalmente para las sesiones de prueba del cliente después de una pérdida de energía para el rack que los albergaba. #### ** Why it happened:** El circuito de alimentación del rack afectado superó su capacidad, y un interruptor de protección tropezó para salvaguardar la línea - poder de corte a los dispositivos en ese rack hasta que el circuito fue restaurado. ¿Cómo lo arreglamos? El circuito afectado fue reiniciado y la potencia restaurada al rack, devolviendo los dispositivos al servicio al cliente. #### ** Lo que estamos haciendo para evitar que vuelva a suceder. Estamos redistribuyendo la carga de energía a través de los racks afectados, añadiendo monitoreo de capacidad con alertas de alerta temprana por delante de los límites de circuito, e introduciendo una revisión de la capacidad antes de que se implementen nuevos dispositivos a un rack.
Traducido automáticamente desde la actualización oficial del 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.
