Self-Healing CI: Recovering an apt GPG Keyserver Timeout
A GPG key import that times out hit a slow or briefly unreachable keyserver, not a broken repo -- the same import succeeds on a retry or via a different keyserver.
The problem
A repository setup step fails because importing a GPG signing key from a keyserver timed out. The key and the repository are valid; the keyserver was briefly slow or unreachable. A human re-runs the import -- often against a different keyserver -- and it succeeds, after which apt can verify the repo.
gpg: keyserver receive failed: Connection timed out
gpg: keyserver receive failed: No data (recv-keys ...)Why it happens
Importing a signing key contacts a public keyserver over the network, and keyservers are frequently slow or briefly unreachable, so a single import can time out even though the key exists and the repository is correctly configured.
It is a keyserver reachability blip, not a configuration error: the same key imports once the request is retried or directed at a healthier keyserver.
The manual fix
Manual mitigations for a keyserver timeout:
- Re-run the import, optionally against a different keyserver.
- Pin the key to a local file fetched over HTTPS instead of relying on a keyserver.
- Wrap the key import in a bounded retry loop.
for ks in keyserver.ubuntu.com keys.openpgp.org; do gpg --keyserver "$ks" --recv-keys "${KEYID}" && break; sleep 3; doneHow this gets automated
A keyserver timeout has a recognizable reachability-blip signature, and the safe response is to retry, potentially against an alternate keyserver. A self-healing CI pipeline detects the import failure, retries the key fetch, and only escalates if the key is genuinely unobtainable, distinguishing a slow keyserver from a real configuration problem.