67 Sauce Labs incidents · Du 2024 — official updates, affected components, duration and resolution details.
No dia 13 de outubro, entre 05:10 UTC e 05:45 UTC, experimentamos elevadas taxas de erro para os serviços VDC, RDC, Sauce Connect e IPSec no data center US-West-1. A questão foi resolvida. Todos os serviços estão agora totalmente operacionais.
Traduzido automaticamente da atualização oficial do incidente.
Estamos experimentando um problema com o Sauce Labs UI no centro de dados EU-Central-1. Estamos a investigar.
Ainda estamos tendo problemas com a interface de laboratório de molho no centro de dados EU-Central-1. Continuamos a investigar.
Fizemos progressos na redução da causa das atuais questões de UI dos laboratórios de molho no centro de dados EU-Central-1. A investigação está em curso.
Estamos a trabalhar em estreita colaboração com os nossos terceiros fornecedores para resolver o problema em curso no centro de dados EU-Central-1. A investigação está em curso.
Continuamos a trabalhar com os nossos parceiros e equipas relevantes para investigar e resolver a questão em curso no centro de dados UE-Centro-1. Iremos partilhar mais actualizações à medida que mais informações estiverem disponíveis.
A principal causa de problema que afeta nosso acesso à IU na EU-Central-1 está ligada a um incidente contínuo com um de nossos provedores de infraestrutura de terceiros no data center. Enquanto nossa equipe mantém esse ticket de incidente fechado do nosso lado, estamos monitorando ativamente a investigação contínua do provedor e monitoraremos de perto o desempenho.
Traduzido automaticamente da atualização oficial do incidente.
Estamos passando por uma degradação na ingestão de erro para o Erro Reportando (Backtrace) usando o crashpad no Android e Linux em todos os Data Centers. Estamos a investigar.
Continuamos a investigar esta questão.
A causa raiz da ingestão de erro para o relatório de erro (Backtrace) foi identificada. Foi aplicada uma reparação e estamos a acompanhar activamente a situação.
Depois de tomar medidas corretivas, o problema da ingestão de erros no relatório de erros (Backtrace) foi resolvido. Todos os serviços estão totalmente operacionais.
Traduzido automaticamente da atualização oficial do incidente.
Estamos vendo taxas de erro elevadas para testes de dispositivos reais no centro de dados EU-Central-1. Estamos a investigar.
As taxas de erro de teste do dispositivo real retornaram ao normal no centro de dados EU-Central-1. Todos os serviços estão totalmente operacionais.
Datas: Quarta-feira, 30 de Setembro de 2026, 09:04 UTC - 10:49 UTC. O que aconteceu? Os Testes Automatizados de Dispositivo Real não tiveram início no centro de dados da EU Central, com taxas de erro chegando a 25%. Porque aconteceu Uma implantação levou ao aumento de falhas de cache e carga elevada na infraestrutura subjacente. Como o consertamos O serviço foi restaurado voltando para uma versão anterior. O que estamos a fazer para evitar que volte a acontecer Estratégias alternativas de cache estão sendo consideradas para aumentar a eficácia do cache.
Traduzido automaticamente da atualização oficial do incidente.
Atualmente estamos vendo taxas de erro elevadas para testes de dispositivos reais automatizados no centro de dados US-West-1. Estamos a investigar.
A causa raiz das taxas de erro elevadas para os testes Real Device no centro de dados US-West-1 foi identificada. Foi aplicada uma reparação e estamos a acompanhar activamente a situação.
Após tomar medidas corretivas, as taxas de erro de teste Real Device retornaram ao normal no data center US-West-1. Todos os serviços estão totalmente operacionais.
Datas: Segunda-feira, 28 de Setembro de 2026, 14:19 UTC - 16:52 UTC. O que aconteceu? Testes reais de dispositivos em US West penduraram e não conseguiram produzir artefatos de teste devido a uploads lentos. Porque aconteceu Um link de conexão degradado sofreu alta perda de pacotes por erros ópticos, mas o BGP permaneceu acima, impedindo failover automático para caminhos saudáveis. Como o consertamos Desactiva manualmente a porta degradada no roteador de bordas, forçando o tráfego a interconexões alternativas saudáveis. O que estamos a fazer para evitar que volte a acontecer Automatizando drenagem de link baseado em limiares de erro CRC, melhorando protocolos para isolar links de fornecedores de flapping e endurecendo a resiliência do upload.
Traduzido automaticamente da atualização oficial do incidente.
Entre 12:05 UTC e 12:35 UTC, experimentamos uma alta taxa de erro e tempos de início de sessão mais longos para testes de Desktop e dispositivos virtuais no centro de dados US-West-1. A questão foi resolvida. Todos os serviços estão totalmente operacionais.
### **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.
Traduzido automaticamente da atualização oficial do incidente.
Entre 09:52 UTC e 10:34 UTC, vários serviços do Sauce Labs no centro de dados US-West experimentaram uma falha, causando falhas de autenticação e interrupções nos recursos de teste. Todos os sistemas estão operacionais.
Datas: Quarta-feira, 16 de Setembro de 2026, 09:51 UTC - 10:35 UTC. O que aconteceu? A disponibilidade de serviços de laboratórios de molho múltiplo diminuiu gradualmente no data center US-West-1. Os serviços afectados incluíam: * Autenticação \(sign-in, SSO, sessões existentes e inscrição\) * Nuvem de Dispositivo Virtual \(VDC\) * Real Device Cloud \(RDC\) * Molho Conectar * API REST * Armazenamento de aplicativos Perspectivas * Molho Visual * Test Composer * Gerenciamento de Usuário e Equipe * Planos de cobrança e API de uso Porque aconteceu A implantação do serviço de Autenticação desencadeou um surto inesperado de conexões de banco de dados, causando falhas de autenticação e interrompendo vários serviços do Sauce Labs. Como o consertamos Reiniciado o nó de banco de dados afetado. O que estamos a fazer para evitar que volte a acontecer Melhore as estratégias de implantação, gerenciamento do ciclo de vida de conexão, mecanismos de failover e responsividade ao exame de saúde.
Traduzido automaticamente da atualização oficial do incidente.
Estamos vendo taxas de erro elevadas para testes de dispositivos reais em data center EU-Central-1. Estamos a investigar.
A causa raiz das taxas de erro elevadas para os testes de dispositivos reais no centro de dados EU-Central-1 foi identificada. Foi aplicada uma reparação e estamos a acompanhar activamente a situação.
Após tomar medidas corretivas, as taxas de erro de teste do dispositivo real retornaram ao normal no centro de dados EU-Central-1. Todos os serviços estão totalmente operacionais.
** Datas:** Quarta-feira, 2 de setembro de 2026, 08:30 UTC - 11:15 UTC. O que aconteceu? Os Testes Automatizados de Dispositivo Real não tiveram início no Centro de Dados Central da UE, com elevadas taxas de erro atingindo quase 100% por curtos períodos de tempo. Porque aconteceu Uma implantação levou ao aumento de falhas de cache e carga elevada na infraestrutura subjacente. Como o consertamos O serviço foi restaurado reiniciando a aplicação. O que estamos a fazer para evitar que volte a acontecer Recursos adicionais foram alocados para reduzir a probabilidade de recorrência em curto prazo. A longo prazo, vamos otimizar o desempenho de tarefas intensivas de recursos e introduzir escala dinâmica.
Traduzido automaticamente da atualização oficial do incidente.
Atualmente estamos vendo elevadas taxas de erro para os testes macOS e iOS no centro de dados US-West-1. Estamos a investigar.
Após tomar medidas corretivas, todos os testes macOS e iOS estão agora funcionando como esperado no Centro de Dados US-West-1. Todos os serviços estão totalmente operacionais.
Datas: Terça-feira 25 de Agosto de 2026, 11:38 – 13:10 UTC O que aconteceu? Os clientes que executam testes macOS e iOS em nossa região EUA-Oeste experimentaram serviço degradado. Cerca de 50% da capacidade virtual do Mac na região parou de aceitar novos testes, então testes em fila ou não foram iniciados. A capacidade restante veio sob pressão adicional à medida que o trabalho se deslocou para ele, o que estendeu os tempos de início para testes de desktop e simulador. Porque aconteceu Um certificado de segurança interna usado pelos nossos hosts Mac para alcançar um serviço de nuvem de suporte atingiu sua data de validade. Depois de caducado, os hosts não podiam mais estabelecer uma conexão confiável com esse serviço e pararam de fornecer novas máquinas de teste. O certificado foi emitido manualmente e não teve renovação automática nem alerta de expiração. Como o consertamos Nós emitimos e implementamos um certificado de substituição, que restaurou a conectividade e devolveu a capacidade do Mac a níveis normais. O que estamos a fazer para evitar que volte a acontecer Estamos transferindo esses certificados para a renovação automatizada e adicionando alertas para que eles sejam substituídos bem antes da expiração, juntamente com a revisão das ferramentas circundantes para tornar o manuseio do certificado mais seguro.
Traduzido automaticamente da atualização oficial do incidente.
Estamos vendo taxas de erro elevadas para testes de desktop virtual no centro de dados US-West-1. Estamos a investigar.
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.
Traduzido automaticamente da atualização oficial do incidente.
Entre 16 de julho 13:03 UTC e 16 de julho 17:33 UTC, nós experimentamos uma interrupção de serviço onde arquivos de símbolos utilizando protocolos de upload multi-parte não conseguiram processar. O incidente foi resolvido e todos os serviços estão operacionais.
### **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.
Traduzido automaticamente da atualização oficial do incidente.
Entre 14 de julho 23:45 UTC e 15 de julho 23:05 UTC, tivemos um problema onde uploads de arquivos de símbolos para projetos Backtrace falharam com erros HTTP 400. O incidente foi resolvido e todos os serviços estão operacionais.
### **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.
Traduzido automaticamente da atualização oficial do incidente.
Estamos experimentando um problema no centro de dados EU Central 1, onde os testes de aplicativos do iOS ARM Simulator falham com erros de infraestrutura. Estamos a investigar.
Os downloads de aplicativos estão demorando mais do que o esperado quando esses erros de infraestrutura são vistos. Continuamos a investigar.
Implementámos uma solução para esta questão. Os testes deverão agora realizar-se como esperado no centro de dados da EU Central 1. Estamos a monitorizar.
Continuamos monitorando quaisquer outros problemas.
Após tomar medidas corretivas e monitorar a situação, estamos vendo testes de aplicativos ARM iOS executarem como esperado no Centro de Dados da UE. Todos os serviços estão totalmente operacionais.
Datas: Terça-feira 14 de julho de 2026, 09:00 - 18:28 UTC O que aconteceu? Os testes do iOS ARM em execução no nosso centro de dados da UE falharam. Porque aconteceu Ocorreu uma falha com o nosso principal fornecedor de rede no nosso centro de dados da UE. Como o consertamos Falhámos com um fornecedor secundário de rede do nosso centro de dados da UE. O que estamos a fazer para evitar que volte a acontecer Nós melhoramos nosso monitoramento e alerta para problemas de captura com provedores de rede de terceiros.
Traduzido automaticamente da atualização oficial do incidente.
Em 1o de julho entre 17:02 UTC e 21:31 UTC, os testes do macOS 14 não foram iniciados nos centros de dados EUA-Oeste e UE-Centro. Esta questão foi resolvida. Todos os serviços estão totalmente operacionais.
### **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.
Traduzido automaticamente da atualização oficial do incidente.
Estamos tendo um problema com o acesso do inspetor de Appium nos centros de dados US-West-1, EU-Central-1 e US-East-4. Estamos a investigar.
Identificámos a causa raiz e implantámos uma solução para esta questão. Todos os serviços estão totalmente operacionais.
Datas: Quarta-feira, 1 de Julho de 2026, 09:37 – 12:46 UTC O que aconteceu? O recurso Appium Inspector, usado durante sessões reais de testes ao vivo, tornou-se indisponível após uma implantação programada de UI. Os usuários que tentaram usar o recurso durante um teste ao vivo foram apresentados com um erro de 500, interrompendo sua sessão de teste ativo. Oleodutos de teste automatizados não foram afetados. Porque aconteceu Uma atualização de rotina de uma biblioteca frontend central introduziu uma incompatibilidade com a lógica de renderização do Inspetor Appium. A versão anterior da biblioteca tolerava o padrão, mas a versão atualizada não tolerava. A questão não foi captada antes da implantação devido à cobertura de teste de ponta a ponta insuficiente para esta característica específica. Como o consertamos Retrocedemos a UI para a última versão de trabalho conhecida para restaurar o recurso imediatamente, e então implantamos uma correção direcionada para a incompatibilidade. O que estamos a fazer para evitar que volte a acontecer Estamos adicionando cobertura de teste de ponta a ponta para o recurso Appium Inspector para garantir que ele seja validado automaticamente antes de futuras implementações.
Traduzido automaticamente da atualização oficial do incidente.
No dia 24 de junho, entre 08:28 UTC e 15:32 UTC, experimentamos falhas na sessão de teste de dispositivos reais impactando a API Appium e Access nos data centers dos EUA East, US West e EU. Esta questão foi resolvida. Todos os serviços estão totalmente operacionais.
Datas: Quarta-feira, 24 de Junho de 2026, 09:42 UTC - 15:45 UTC. O que aconteceu? Sessões de teste de dispositivos reais usando Appium e Access API experimentaram taxas de erro aumentadas nos centros de dados dos EUA East, US West e UE. As sessões foram cronometradas após aproximadamente 90 segundos ou ficando presa no estado de "Conectação", impedindo-os de serem fechadas. Porque aconteceu Um defeito de produto foi introduzido, fazendo com que as sessões de teste do Real Device não começassem e impedissem que as sessões ativas fossem fechadas. Como o consertamos Voltar para uma versão estável. O que estamos a fazer para evitar que volte a acontecer Melhore o monitoramento e alerta e melhore a validação pós-implantação.
Traduzido automaticamente da atualização oficial do incidente.
Por volta das 3:51 AM UTC começamos a experimentar menor disponibilidade de dispositivos iOS no centro de dados EU-Central. Nossa equipe está ativamente investigando a causa raiz e trabalhando para uma resolução.
Temos experimentado indisponibilidade do dispositivo em nosso centro de dados EU-Central-1 e identificamos a causa raiz. Tomámos medidas correctivas e estamos actualmente a acompanhar.
Depois de tomar medidas corretivas, estamos vendo dispositivos reais disponíveis para testes no centro de dados EU-Central-1. Todos os serviços estão totalmente operacionais.
Datas: Quinta-feira 18 de Junho de 2026, 03:45 UTC - 06:45 UTC. O que aconteceu? Aproximadamente 7% dos dispositivos iOS no nosso centro de dados da UE estavam temporariamente indisponível para as sessões de teste do cliente após uma perda de energia para o rack hosting-los. Porque aconteceu O circuito elétrico que alimentava o rack afetado excedeu sua capacidade, e um disjuntor protetor tropeçou para proteger a energia de corte de linha dos dispositivos naquele rack até que o circuito fosse restaurado. Como o consertamos O circuito afetado foi reiniciado e a energia restaurada no rack, devolvendo os dispositivos ao serviço ao cliente. O que estamos a fazer para evitar que volte a acontecer Estamos redistribuindo carga de energia através de racks afetados, adicionando monitoramento de capacidade com alertas de alerta precoce antes dos limites do circuito e introduzindo uma revisão de capacidade antes de novos dispositivos serem implantados em rack.
Traduzido automaticamente da atualização oficial do 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.
