[Bug]: error=failed to create container / context deadline exceeded

[lateparty]

Bug Report Checklist

• I checked existing issues and found no duplicates.
• I have reviewed Watchtower's documentation and confirmed compliance with documented configuration specifications.
• I have restarted Docker, re-pulled the latest image, and confirmed that the issue persists.

Bug Description

Over the last few weeks Watchtower has failed to restart containers after successfully finding a new image/version so the container just stays removed and dead. If I run my create script it starts up with the new pull. I have now monitored this occurring with Trace logs on

Start of log to show I'm using latest version

time="2026-05-22T02:01:41Z" level=info msg="Watchtower 1.17.1 using Docker API v1.54"
time="2026-05-22T02:01:41Z" level=info msg="Using no notifications"
time="2026-05-22T02:01:41Z" level=info msg="Only checking containers in scope" scope=services
time="2026-05-22T02:01:41Z" level=info msg="Next scheduled run: 2026-05-22 10:01:41 UTC in 7 hours 59 minutes 59 seconds"

time="2026-05-23T06:10:33Z" level=debug msg="Template processing completed successfully" entries_count=3 legacy_template=true msg_length=341 notify=no template_name=
time="2026-05-23T06:10:33Z" level=debug msg="Generated notification message" message="Found new image: ghcr.io/linuxserver/sonarr:latest (244f62065515)\nStopped stale container: sonarr (8f97e1852c5b)\nUpdated container state to failed | container_id=8f97e1852c5b error=failed to create container: failed to create container: Post \"http://%2Fvar%2Frun%2Fdocker.sock/v1.54/containers/create\": context deadline exceeded name=sonarr " notify=no
time="2026-05-23T06:10:33Z" level=debug msg="Preparing to send entries" error="<nil>" message="Found new image: ghcr.io/linuxserver/sonarr:latest (244f62065515)\nStopped stale container: sonarr (8f97e1852c5b)\nUpdated container state to failed | container_id=8f97e1852c5b error=failed to create container: failed to create container: Post \"http://%2Fvar%2Frun%2Fdocker.sock/v1.54/containers/create\": context deadline exceeded name=sonarr " notify=no
time="2026-05-23T06:10:33Z" level=debug msg="Successfully sent message to notification channel" channel_status=sent entries_count=3 msg_length=341 notify=no
time="2026-05-23T06:10:33Z" level=info msg="Update session completed" failed=1 notify=no scanned=18 updated=0
time="2026-05-23T06:10:33Z" level=debug msg="Update operation completed"
time="2026-05-23T06:10:33Z" level=debug msg="Scheduled next run: 2026-05-23 14:10:33 +0000 UTC m=+86430.270388256"

Steps to Reproduce

1. Start Watchtower with Docker container using

	docker run \
	-d \
	--name watchtower \
	--restart always \
	--label=com.centurylinklabs.watchtower.enable=true \
	--label=com.centurylinklabs.watchtower.scope=services \
	-v /var/run/docker.sock:/var/run/docker.sock \
	-e WATCHTOWER_TRACE=true \
  	-e WATCHTOWER_POLL_INTERVAL=28800 \
  	-e WATCHTOWER_CLEANUP=true \
  	-e WATCHTOWER_TIMEOUT=60 \
	-e WATCHTOWER_LABEL_ENABLE=true \
	-e WATCHTOWER_SCOPE=services \
	nickfedor/watchtower

The relevant fields from the failed updae container (but all my containers are failling)

docker run \
    -d \
    --name sonarr \
    --privileged \
    --restart always \
    --network="bridge" \
    -p 8989:8989 \
    -e PUID=1000 -e PGID=100 \
    -e TZ=Australia/Melbourne \
    -v /containers/sonarr:/config \
    --label=com.centurylinklabs.watchtower.enable=true \
    --label=com.centurylinklabs.watchtower.scope=services \
    ghcr.io/linuxserver/sonarr

2. Wait for the update cycle
3. Obserbe the errant behaviour logged above in the bug description

Expected Behavior

That watchtower works like it used to and bring the updated container back up after update

Watchtower Version

latest 1.17.1

Docker Version

Client:
Version:           29.5.1
API version:       1.54

Server:
Engine:
Version:          29.5.1
API version:      1.54 (minimum version 1.40)

Docker Info (optional)

Docker Compose Configuration

Docker CLI Command

Debug Logs

Relevant debug level logs attached above

Additional Context

No response

[nicholas-fedor]

There's a syntax issue with your configuration. The timeout value must use Go's time duration format (e.g., 30s, 1m, 2h). Try using WATCHTOWER_TIMEOUT=60s.

[vctls]

I've been having the same issue for a few weeks. I don't recall touching the timeout configuration. Did something change?
I've increased the timeout delay, added the missing s and increased log level just in case. We'll see if it happens again.

[lateparty]

I have been monitoring this with a tail on my watchtower logs hoping to provide confirmation that it's all working again since the update but it was a slow period for developers but now finally have confirmation of a successful update for both a privileged and non-privileged container, and watchtower updating itself too! Looks like the "60s" update has fixed at least my problems!

[dmcallejo]

I've been having the same issue for a few weeks. I don't recall touching the timeout configuration. Did something change? I've increased the timeout delay, added the missing s and increased log level just in case. We'll see if it happens again.

Same here. I have set up along a lot of docker hosts a timeout of "300" and it's been working fine for months. Suddenly I am having context deadline exceeded left and right.
I am changing all of them to "300s" but if this has changed it should've been retro-compatible with the previous configuration without time specification and default to seconds.

[nicholas-fedor]

In short, this is a longstanding (pre-fork) issue, as values configured without time units have always been interpreted in nanoseconds.

I'm adding additional logic that will set bare values to default to seconds, which should help further ameliorate this issue.

[dmcallejo]

Thank you! imho this is how it should be so it doesn't break the legacy configurations

[ErickBrown]

Can the watchtower logic be modified so that it does not delete containers until new containers are successfully created? I just ran into this configuration change issue and lost a couple dozen container configurations across 3 home servers.

[Mushoz]

Also getting this error without me ever using WATCHTOWER_TIMEOUT. I did not have this error previously, so it seems like a regression.