404s downloading worker binary

What to do

• Check whether you use Spacelift in eu. Check your stack

  Paste a package.json, lockfile, Terraform or a list of domains at down.guide/stack to see every provider you depend on.

• Confirm your retries, queues and scheduled jobs caught up after the 52m it lasted.

  Anything that failed between 2026-10-29 15:48 UTC and 2026-10-29 16:40 UTC may need a replay.

• Subscribe to Spacelift's feed to hear about the next one first. RSS feed

  https://down.guide/feed?provider=spacelift works in Slack (/feed subscribe), Discord feed bots and any RSS reader.

Root cause

**Root Cause**

Updates from Spacelift 4

1. investigatingOct 29, 2026, 3:48 PM UTC

   We are investigating an issue where some runs fail to start with the error "couldn't start worker: error populating worker binary". Our team is actively working on this.

   provider

2. monitoringOct 29, 2026, 4:24 PM UTC

   A fix has been applied and runs in the EU region are working again. We are monitoring the situation to make sure all runs start as expected

   provider

3. resolvedOct 29, 2026, 4:40 PM UTC

   This incident has been resolved. Runs in the EU region are starting normally again. If any of your runs failed during this period, please retrigger them

   provider

4. postmortemOct 30, 2026, 9:10 AM UTC

   **Summary** Between 15:31 UTC and 15:55 UTC on October 29th, runs for customers using ARM runners failed to start with the following error message: couldn't start worker: couldn't start docker container: error populating worker binary: unexpected response code when querying for worker binary at [https://downloads.spacelift.io/worker-arm64/752bab1d/spacelift-worker](https://downloads.spacelift.io/worker-arm64/752bab1d/spacelift-worker): 404 **Incident Timeline** * 15:31 UTC - A new deployment of the Spacelift backend was triggered. * 15:45 UTC - We triggered a rollback to the previous version. * 15:50 UTC - The fix began to take effect. * 15:55 UTC - The fix was fully rolled out. **Root Cause** The problem was caused by our build pipeline failing silently to upload that single file. When we triggered a new deployment of the Spacelift backend, new runs switched over to the new worker version and began to fail because the file was missing. **Mitigations** * Immediate: we rolled back to a previous working version. * Permanent: we have updated our deployment pipeline to ensure that it cannot silently fail to upload assets like this in future.

   provider

Corrections

None so far.

Something wrong on this page? Report an error or send us a note. Every fix is listed here.