Is Sauce Labs down right now?
No — Sauce Labs is up. All systems operational as of Aug 19, 10:37 PM UTC.
Current Status
All Systems Operational
Components
Recent Incidents
2026-August-07 Service Incident
noneAug 7, 2026 · resolved Aug 7
### **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.
2026-July-16 Resolved Service Incident - Error Reporting (Backtrace)
noneJul 16, 2026 · resolved Jul 16
### **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.
2026-July-15 Resolved Service Incident - Error Reporting (Backtrace)
noneJul 14, 2026 · resolved Jul 14
### **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.
2026-July-14 Service Incident
majorJul 14, 2026 · resolved Jul 14
### **Dates:** Tuesday July 14th 2026, 09:00 - 18:28 UTC ### **What happened:** iOS ARM tests running in our EU data center failed. ### **Why it happened:** A fault occurred with our primary network provider in our EU data center. ### **How we fixed it:** We failed over to a secondary network provider from our EU data center. ### **What we are doing to prevent it from happening again:** We've improved our monitoring and alerting to catch issues with third party network providers.
2026-July-1 Resolved Service Incident 1
minorJul 1, 2026 · resolved Jul 1
### **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.
Get alerted when Sauce Labs goes down
Alert24 monitors Sauce Labs and 3,700+ other cloud and SaaS providers. When an outage is detected, it updates your status page automatically and pages your on-call team. No manual updates at 2 AM.
Sauce Labs status — frequently asked questions
Is Sauce Labs down right now?
No — Sauce Labs is up. All systems operational as of Aug 19, 10:37 PM UTC.
What is Sauce Labs's current status?
Sauce Labs: All Systems Operational. Alert24 checks Sauce Labs's status page continuously and can notify you the moment it changes.
How do I get alerted when Sauce Labs goes down?
Alert24 monitors Sauce Labs and 3,700+ other cloud and SaaS providers. When an outage is detected it updates your status page automatically and pages your on-call team — no manual checks. Start free at alert24.net.




