Sauce Labs kesinti geçmişi

1. 2 Eylül 2026 09:39 UTCinvestigating

   EU-Central-1 veri merkezinde Gerçek Cihaz testleri için yüksek hata oranları görüyoruz. araştırıyoruz.

2. 2 Eylül 2026 11:30 UTCidentified

   AB-Central-1 veri merkezindeki Real Device testleri için yüksek hata oranlarının temel nedeni tespit edilmiştir. Remediasyon uygulandı ve durumu aktif olarak izliyoruz.

3. 2 Eylül 2026 11:53 UTCresolved

   Remedial aksiyon aldıktan sonra, Real Device test hatası oranları AB-Central-1 veri merkezinde normale döndü. Tüm hizmetler tamamen operasyoneldir.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 25 Ağustos 2026 12:33 UTCinvestigating

   Şu anda ABD-West-1 veri merkezinde Mac ve iOS testleri için yüksek hata oranları görüyoruz. Şu anda araştırıyoruz.

2. 25 Ağustos 2026 13:19 UTCresolved

   Remedial aksiyon aldıktan sonra, tüm Mac ve iOS testleri şimdi ABD-West-1 Data merkezinde beklendiği gibi performans gösteriyor. Tüm hizmetler tamamen operasyoneldir.

3. 3 Eylül 2026 20:23 UTCpostmortem

   ## **Dates:** 25 Ağustos 2026, 11:38 - 13:10 UTC ## ** Ne oldu:** Müşteriler ABD-West Bölgesimizde Mac ve iOS testlerini çalıştırıyor, bozuldu. Bölgedeki sanal Mac kapasitesinin yaklaşık% 50'si yeni testleri kabul etmeyi bıraktı, bu yüzden ya kuyruklanmış ya da başlamak için başarısız oldu. Kalan kapasite, her iki masaüstü ve simülatörü testleri için zaman uzatan iş olarak ek baskı altında geldi. ## ** Neden oldu:** Mac'imiz tarafından kullanılan bir iç güvenlik sertifikası, bir destek bulut hizmetine ulaşmak için geniş bir tarihe ulaştı. Bir zamanlar, ev sahipleri artık bu hizmete güvenilir bir bağlantı kuramadı ve yeni test makinelerini durdurdu. Sertifika manuel olarak yayınlandı ve ne otomatik bir yenileme ya da uyarmadı. ## **Bunu nasıl düzelttik:** Bağlantıyı restore eden ve Mac kapasitesini normal seviyelere iade ettik. ## ** Bunu tekrar gerçekleştirmeyi önlemek için ne yapıyoruz:** Bu sertifikaları otomatik yenilemeye ve uyarıya ekliyoruz, böylece genişletilmeden önce iyi bir şekilde değiştirildiler ve sertifika işlemeyi daha güvenli hale getirmek için çevreleyen aracı gözden geçirdikler.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 7 Ağustos 2026 12:08 UTCinvestigating

   We are currently seeing elevated error rates for virtual desktop tests in the US-West-1 datacenter. We are currently investigating.

2. 7 Ağustos 2026 13:06 UTCresolved

   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

3. 14 Ağustos 2026 16:43 UTCpostmortem

   ### **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.

1. 16 Temmuz 2026 20:33 UTCresolved

   16 Temmuz 13:03 UTC ve 16 Temmuz 17:33 UTC arasında, çok bölüm yükleme protokolleri kullanan sembolün süreç başarısız olduğu bir hizmet kesintisi yaşadık. Olay çözüldü ve tüm hizmetler operasyonel.

2. 14 Ağustos 2026 16:48 UTCpostmortem

   ### **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.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 16 Temmuz 2026 20:30 UTCresolved

   14 Temmuz 23:45 UTC ve 15 Temmuz 23:05 UTC arasında, sembolün geri çekilme projelerinin HTTP 400 hatalarıyla başarısız olduğu bir konu yaşadık. Olay çözüldü ve tüm hizmetler operasyonel.

2. 14 Ağustos 2026 16:47 UTCpostmortem

   ### **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.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 14 Temmuz 2026 17:19 UTCinvestigating

   AB Merkez 1 veri merkezinde bir sorun yaşıyoruz, iOS ARM Simulator uygulaması testleri altyapı hatalarıyla başarısız oldu. araştırıyoruz.

2. 14 Temmuz 2026 18:05 UTCinvestigating

   App indirmeleri, bu altyapı hatalarının görüldüğünden daha uzun sürüyor. Araştırmaya devam ediyoruz.

3. 14 Temmuz 2026 18:56 UTCmonitoring

   Bu konu için bir düzeltme yaptık. Testler artık AB Merkez 1 veri merkezinde beklendiği gibi performans göstermelidir. İzlemeliyiz.

4. 14 Temmuz 2026 19:11 UTCmonitoring

   Daha fazla sorun için izlemeye devam ediyoruz.

5. 14 Temmuz 2026 20:23 UTCresolved

   Remedial eylemi yaptık ve durumu izlemekten sonra, iOS ARM uygulama testlerini EU Data Center'da beklendiği gibi görüyoruz. Tüm hizmetler tamamen operasyoneldir.

6. 29 Temmuz 2026 17:40 UTCpostmortem

   ## **Dates:** 14 Temmuz 2026, 09:00 - 18:28 UTC ## ** Ne oldu:** AB veri merkezimizde çalışan iOS ARM testleri başarısız oldu. ## ** Neden oldu:** Bir hata AB veri merkezimizde birincil ağ sağlayıcımızla gerçekleşti. ## **Bunu nasıl düzelttik:** AB veri merkezimizden ikincil bir ağ sağlayıcısına geçemedik. ## ** Bunu tekrar gerçekleştirmeyi önlemek için ne yapıyoruz:** İzlememizi geliştirdik ve üçüncü parti ağ sağlayıcıları ile sorunları yakalamak için uyarılıyoruz.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 1 Temmuz 2026 21:37 UTCresolved

   17:02 UTC ve 21:31 UTC arasında 1 Temmuz'da, Mac 14 testleri ABD-Batı ve AB-Central veri merkezlerinde başlamadı. Bu konu çözüldü. Tüm hizmetler tamamen operasyoneldir.

2. 11 Ağustos 2026 20:37 UTCpostmortem

   ### **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.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 1 Temmuz 2026 12:12 UTCinvestigating

   ABD-West-1, EU-Central-1 ve ABD-Doğu-4 veri merkezlerine erişim konusunda bir sorun yaşıyoruz. araştırıyoruz.

2. 1 Temmuz 2026 12:58 UTCresolved

   Kök nedeni tespit ettik ve bu konu için bir düzeltme kurduk. Tüm hizmetler tamamen operasyoneldir.

3. 20 Temmuz 2026 20:34 UTCpostmortem

   ## **Dates:** Çarşamba Temmuz 1st 2026, 09:37 - 12:46 UTC ## ** Ne oldu:** Gerçek cihaz canlı test seansları sırasında kullanılan Appium Inspector özelliği, planlanan bir UI dağıtımından sonra kullanılamaz hale geldi. Canlı bir test sırasında özelliği kullanmaya çalışan kullanıcılar, aktif test seanslarını kesintiye uğrattı. Otomatik test hatları etkilenmedi. ## ** Neden oldu:** Temel bir ön kütüphanenin rutin bir yükseltmesi Appium Inspector'un oluşturma mantığıyla bir uyumsuzluk tanıttı. Önceki kütüphane versiyonu deseni tolere etti, ancak güncellenmiş sürüm yapmadı. Sorun, bu özel özellik için yetersiz son test kapsamı nedeniyle dağıtımdan önce yakalanmadı. ## **Bunu nasıl düzelttik:** UI'yi hemen özelliği geri yüklemek için bilinen son iş versiyonuna geri döndük ve sonra incompatability için hedefli bir düzeltme dağıttık. ## ** Bunu tekrar gerçekleştirmeyi önlemek için ne yapıyoruz:** Appium Inspector özelliği için son test kapsamı ekliyoruz, gelecekteki dağıtımlardan önce otomatik olarak doğrulanır.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 24 Haziran 2026 16:39 UTCresolved

   24 Haziran'da 08:28 UTC ve 15:32 UTC arasında, ABD'de Appium ve Access API'sini etkileyen Real Device test seans başarısızlıklarını yaşadık. Bu konu çözüldü. Tüm hizmetler tamamen operasyoneldir.

2. 22 Temmuz 2026 20:49 UTCpostmortem

   ## **Dates:** Çarşamba, 24 Haziran 2026, 09:42 UTC - 15:45 UTC. ## ** Ne oldu:** Appium ve Access API kullanarak gerçek cihaz test seansları ABD Doğu, ABD Batı ve AB veri merkezlerinde hata oranları arttı. Oturumlar yaklaşık 90 saniye sonra ya da "bağlantı" durumundan sonra zamanlanıyordu, onları kapalı olmaktan alıkoydu. ## ** Neden oldu:** Bir ürün hatası tanıtıldı, Real Device test seanslarına başlamak ve kapalı olmaktan aktif seansları önlemek için neden oldu. ## **Bunu nasıl düzelttik:** Sabit bir sürüme geri dön. ## ** Bunu tekrar gerçekleştirmeyi önlemek için ne yapıyoruz:** İzleme ve uyarılama ve posta dağıtımını doğrulamayı geliştirin.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 18 Haziran 2026 05:30 UTCinvestigating

   Yaklaşık 3:51 AM UTC AB-Central veri merkezinde daha düşük iOS cihazı erişilebilirliği yaşamaya başladık. Ekibimiz aktif olarak kök nedenini araştırıyor ve bir karara doğru çalışıyor.

2. 18 Haziran 2026 06:12 UTCmonitoring

   AB-Central-1 veri merkezimizde uygun olmayan cihazı deneyimliyoruz ve kök nedenini tespit ettik. Remedial aksiyon aldık ve şu anda izliyoruz.

3. 18 Haziran 2026 06:59 UTCresolved

   Remedial aksiyon aldıktan sonra, AB-Central-1 veri merkezinde test için mevcut gerçek cihazlar görüyoruz. Tüm hizmetler tamamen operasyoneldir.

4. 6 Temmuz 2026 17:17 UTCpostmortem

   ## **Dates:** Perşembe 18 2026, 03:45 UTC - 06:45 UTC. ## ** Ne oldu:** AB veri merkezimizdeki iOS cihazlarının yaklaşık% 7'si, onları raf barındırmasından sonra müşteri test seansları için geçici olarak kullanılamazdı. ## ** Neden oldu:** Etkilenen rafı besleme gücü kapasitesini aştı ve hattı korumak için koruyucu bir mola - devre restore olana kadar bu raftaki cihazlara güç kesmek. ## **Bunu nasıl düzelttik:** Etkilenen devre, rafa restore edildi ve cihazlara müşteri hizmetine geri döndü. ## ** Bunu tekrar gerçekleştirmeyi önlemek için ne yapıyoruz:** Etkilenen raflara güç yüklerini yeniden dağıtıyoruz, devre sınırları önünde erken savaş uyarıları ile kapasite izleme ve yeni cihazlardan önce kapasite incelemesi tanıtıyoruz.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 1 Haziran 2026 14:02 UTCinvestigating

   We are experiencing an issue where the US-EAST data center is currently unavailable. We are investigating.

2. 1 Haziran 2026 14:55 UTCinvestigating

   We are continuing to investigate this issue.

3. 1 Haziran 2026 15:30 UTCinvestigating

   We have identified the root cause and are working on implementing a fix.

4. 1 Haziran 2026 16:02 UTCmonitoring

   Access has been restored to the US-EAST data center. We are monitoring.

5. 1 Haziran 2026 18:24 UTCresolved

   After taking remedial action, access to the US-EAST data center is fully restored. This incident is resolved.

6. 15 Haziran 2026 23:32 UTCpostmortem

   ### **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.

1. 21 Mayıs 2026 14:53 UTCresolved

   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.

2. 26 Mayıs 2026 15:07 UTCpostmortem

   ### **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.

1. 24 Nisan 2026 16:33 UTCresolved

   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.

2. 13 Mayıs 2026 15:05 UTCpostmortem

   ### **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.

1. 16 Nisan 2026 10:10 UTCresolved

   Between 02:00 and 11:15 CEST, live and automated tests on iOS 17.0 simulators were failing to start in the EU and US-West Data Center. We executed a deployment rollback, which restored services. All systems are now fully operational.

2. 8 Mayıs 2026 18:42 UTCpostmortem

   ### **Dates:** Thursday, April 16th 2026, 00:00 UTC – 09:15 UTC ### **What happened:** Live and automated tests on iOS 17.0 simulators failed to start in both the EU and US-West data centers. Customers running tests on iOS 17.0 Intel-based simulators were unable to execute their tests for approximately 9 hours. ### **Why it happened:** A deployment introduced an incompatibility affecting iOS 17.0 on Intel-based infrastructure. The issue was not caught prior to release due to insufficient post-deployment test coverage for that specific simulator configuration. ### **How we fixed it:** We performed a rollback to the previous deployment, which restored full iOS 17.0 simulator functionality. ### **What we are doing to prevent it from happening again:** We are reviving and expanding automated post-deployment tests to cover a broader range of simulator configurations, including legacy Intel-based iOS versions, to catch incompatibilities before they reach production.

1. 7 Nisan 2026 15:02 UTCinvestigating

   We are currently investigating reports of test failures affecting users running tests using SauceCtl in our US-West-1 and EU-Central-1 Data Center. We are investigating.

2. 7 Nisan 2026 16:13 UTCresolved

   We have identified the root cause and have deployed a fix for this issue. All services are fully operational.

3. 10 Nisan 2026 21:56 UTCpostmortem

   ### **Dates:** Monday April 7th 2026, ~11:00 – 15:55 UTC ### **What happened:** Some customers experienced 503 errors when running tests via saucectl. The test-composer service was intermittently unavailable, preventing framework-based test execution. ### **Why it happened:** A stale Docker image was deployed to the test-composer service due to a packaging issue that arose during an internal container registry migration. This caused service pods to crash. ### **How we fixed it:** We identified the stale image and redeployed the correct version, restoring the service. ### **What we are doing to prevent it from happening again:** We are hardening our image deployment pipeline and adding validation checks to ensure container registry migrations do not result in stale or incorrect images being deployed to production.

1. 24 Mart 2026 17:36 UTCresolved

   Between 09:32 and 15:13 UTC, we identified a technical issue affecting iOS tests when running with network capture enabled. We've resolved the underlying cause and tests are working as expected. All services are fully operational.

2. 10 Nisan 2026 23:06 UTCpostmortem

   ### **Dates:** Tuesday, March 24th 2026, 09:32 UTC – 15:13 UTC ### **What happened:** Network calls failed on iOS devices during Real Device Cloud sessions where network capture was enabled. Approximately 12-13% of iOS sessions were affected. Android was not impacted. ### **Why it happened:** A deployment introduced a DNS resolution change that was incompatible with the iOS platform, causing network capture to break. ### **How we fixed it:** Rolled back the deployment to restore service. ### **What we are doing to prevent it from happening again:** Adding synthetic tests to catch network capture regressions before production, and implementing monitoring alerts for faster detection after deployments.

1. 19 Mart 2026 09:51 UTCinvestigating

   Around 4:45 AM UTC we started experiencing lower iOS device availability in the US-West data center. Our team is actively investigating the root cause and working toward a resolution.

2. 19 Mart 2026 10:54 UTCresolved

   This incident has been resolved and our services are fully operational.

3. 10 Nisan 2026 22:59 UTCpostmortem

   ### **Dates:** Wednesday, March 19 2026, 04:45 UTC - 10:47 UTC. ### **What happened:** Approximately 15% of iOS devices in our US-West data center were temporarily unavailable for customer test sessions due to failed internet connectivity checks. ### **Why it happened:** An automated wireless network optimization feature adjusted transmit power levels on access points serving the affected devices, degrading wireless connectivity and causing devices to fail their availability checks. ### **How we fixed it:** The affected access points were identified and restarted, restoring normal wireless connectivity. ### **What we are doing to prevent it from happening again:** Evaluation of the automated optimization tools and a monitoring improvement.

1. 18 Mart 2026 17:15 UTCresolved

   Between 14:43 and 15:11 UTC on March 13, a small subset of Real Devices (iOS and Android) became unavailable across all our data centers. After taking remedial action, the issue was identified and resolved. All services are fully operational.

2. 10 Nisan 2026 22:57 UTCpostmortem

   ### **Dates:** Friday, March 13th 2026, 14:43 UTC - 15:11 UTC. ### **What happened:** Real Devices \(iOS and Android\) availability gradually decreased across all data centers. ### **Why it happened:** A product defect was introduced resulting in a small subset of Real Devices \(~10%\) failing to maintain required connectivity. ### **How we fixed it:** Rollback to a stable version. ### **What we are doing to prevent it from happening again:** Improve monitoring & alerting, enhance post deployment validation.

1. 10 Mart 2026 18:46 UTCinvestigating

   We are experiencing device unavailability in the US West 1, EU Central 1, and US East 4 data centers and have found that the issue is caused by a 3rd party service disruption. We are investigating.

2. 10 Mart 2026 23:34 UTCresolved

   This incident has been resolved.

3. 9 Nisan 2026 21:07 UTCpostmortem

   ### **Dates:** Tuesday March 10th 2026, 17:52 - 23:34 UTC ### **What happened:** The majority of iOS devices across all regions became unavailable. ### **Why it happened:** Apple's [ppq.apple.com](http://ppq.apple.com) app verification endpoint was down, causing internal device monitoring checks to fail, bringing devices offline. ### **How we fixed it:** We temporarily disabled these device monitoring checks. ### **What we are doing to prevent it from happening again:** Improved external monitoring to catch outages of apple’s [ppq.apple.com](http://ppq.apple.com) endpoint, loosened device monitoring to not take down live iOS devices if [ppq.apple.com](http://ppq.apple.com) is down.

1. 6 Mart 2026 23:28 UTCresolved

   Between 21:38 UTC and 23:11 UTC, our virtual iOS and MacOS live and automated device tests were failing to start in the EU Data Center. We executed a deployment rollback, which restored services. All systems are now fully operational.

2. 10 Nisan 2026 22:53 UTCpostmortem

   ### **Dates:** Friday, March 6th 2026, 21:38 UTC - 23:11 UTC ### **What happened:** During the incident timeline, customers running virtual iOS simulator tests on ARM or macOS ARM desktop tests in the EU Data Center were unable to start new sessions for either live or automated. ### **Why it happened:** There was a sequencing issue on the release of the ARM side disk images in the EU. ### **How we fixed it:** The image reference for the ARM side disk was rolled back to the previous reference to restore service. ### **What we are doing to prevent it from happening again:** The tests that run to validate the image syncing have been completed in each region.