Intermittent failures on logging in with Google Artifact Registry

[yairhay-di]

Contributing guidelines

• I've read the contributing guidelines and wholeheartedly agree

I've found a bug, and:

• The documentation does not mention anything about my problem
• There are no open or closed issues that are related to my problem

Description

When running the login action
# - name: Login to GAR # id: docker_gar # uses: docker/login-action@v3
We intermittently experiencing the following error:
Error: Error response from daemon: Get "https://${region}-docker.pkg.dev/v2/": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

Most of the time it works, but sometimes it fails.

Expected behaviour

To login successfuly

Actual behaviour

Error: Error response from daemon: Get "https://${region}-docker.pkg.dev/v2/": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

Repository URL

No response

Workflow run URL

No response

YAML workflow

`    # - name: Login to GAR
    #   id: docker_gar
    #   uses: docker/login-action@v3`

Workflow logs

No response

BuildKit logs

Additional info

No response

[joaodiogocosta]

Same here

[austinpray-mixpanel]

with

Run docker/login-action@v3
  with:
    registry: us.gcr.io
    username: oauth2accesstoken
    password: ***
    ecr: auto
    logout: true

getting

Error: Error response from daemon: Get "https://us.gcr.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

[crazy-max]

Do you still repro? Might be smth flaky with Google Artifact Registry

[jsmith212]

Same here, but for a self hosted registry. I haven't had any issues elsewhere with that registry, and rerunning a few times usually fixes it. Would it be possible to just add a retry count?

[moicalcob]

We're seeing a similar behaviour every now and then and it's happening more frequently lately:

  with:
    registry: gcr.io
    username: _json_key
    password: ***
  
    logout: true
Logging into gcr.io...
Error: Error response from daemon: login attempt to https://gcr.io/v2/ failed with status: 401 Unauthorized

[matthiasPOE]

Our actions are completely down due to unable to pull:

Unable to find image 'docker.pkg.github.com/**/**/**:head' locally
docker: Error response from daemon: unknown: failed to resolve reference "docker.pkg.github.com/**/**/**:head": unexpected status from HEAD request to https://docker.pkg.github.com/v2/**/**/**/manifests/head: 401 Unauthorized

The login works fine before it?

Run docker/login-action@v3
Logging into docker.pkg.github.com...
Login Succeeded!

Anyone else experiencing the same issue?

[crazy-max]

Our actions are completely down due to unable to pull:

Unable to find image 'docker.pkg.github.com/**/**/**:head' locally
docker: Error response from daemon: unknown: failed to resolve reference "docker.pkg.github.com/**/**/**:head": unexpected status from HEAD request to https://docker.pkg.github.com/v2/**/**/**/manifests/head: 401 Unauthorized

The login works fine before it?

Run docker/login-action@v3
Logging into docker.pkg.github.com...
Login Succeeded!

Anyone else experiencing the same issue?

That's unrelated with this issue that is about GAR. Also docker.pkg.github.com is EOL, switch to ghcr.io: https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-docker-registry

[esavier]

is this really triage since Aug 2025...?

[esavier]

here, a PR.
generally network issue. Error is forwarded from docker and is misleading.

[SirBrenton]

This smells like transient network / registry edge flake rather than a deterministic auth/config bug.

Two concrete guardrails that usually collapse this class fast:

1. Retry transient failures only (timeout / connection reset / EOF), with a hard cap + jittered backoff.

   • e.g. 3 attempts, 2s → 4s → 8s (+ jitter)
   • Never retry 401/403 (those are terminal: creds/permissions).

2. Emit a tiny “receipt” per attempt so we can separate:

   • DNS vs TCP connect vs TLS handshake vs “awaiting headers”
   • runner context (hosted vs self-hosted, region if known)
   • latency_ms + error_class

If maintainers are open to it, docker/login-action could accept something like retry_max + retry_backoff_ms (or implement internally around the docker login call), but only for known transient error classes.

Happy to help draft the minimal classification list + defaults.

———

If you can share 5–20 redacted failure receipts (timestamps + error string + latency), I can turn it into a ranked hazard signature.