There seems to be a problem during collections installation from galaxy.ansible.com
ERROR! Unknown error when attempting to call Galaxy at 'https://galaxy.ansible.com/api/v3/collections/community/postgresql/versions/': The read operation timed out
ERROR! Unknown error when attempting to call Galaxy at 'https://galaxy.ansible.com/api/v3/plugin/ansible/content/published/collections/index/community/general/versions/?limit=10&offset=40': The read operation timed out
This normally takes a few seconds, but now it seems to be taking minutes and it returns a timeout error once it reaches the configured limit.
I began noticing this issue last week, and it is still persisting now.
Does anyone have the same issue ?
We didn’t have any errors to report, but when running AWX jobs or GitHub Actions that needed to install Galaxy collections around 11am EST today we noticed that jobs that normally took a couple of minutes were taking 30 minutes or more. We had one job fail with a message that it couldn’t retrieve a collection, but relaunching it worked (but it still took forever).
The API is also very slow when answering requests for a version page, like Ansible Galaxy. That was never fast to begin with, but now it’s extremely slow.
Can confirm this has been an issue over the last 1-2 days. I have people in Australia (Perth, Brisbane, Melbourne) and New Zealand with multiple carriers/connection types, as well as our Github CI continues to fail.
For us, the final error is:
ERROR! Unexpected Exception, this is probably a bug: The read operation timed out
Let me know if you need any more info to troubleshoot.
We have tried version locking the collections and increasing timeouts but nothing seems to have worked permanently so far. The issue is intermittent it seems, with about a 90+% failure rate in our experience.
I can confirm the same problems with AWS and my home Telekom germany connection.
Some requests work. Some don’t:
❯ for i in {1..20}; do
printf "%2d: " "$i"
curl -4 -sS \
--connect-timeout 3 \
--max-time 2 \
-o /dev/null \
-w 'HTTP=%{http_code} start=%{time_starttransfer}s total=%{time_total}s\n' \
https://galaxy.ansible.com/api/
sleep 1
done
1: curl: (28) Operation timed out after 2003 milliseconds with 0 bytes received
HTTP=000 start=0.000000s total=2.004001s
2: curl: (28) Operation timed out after 2006 milliseconds with 0 bytes received
HTTP=000 start=0.000000s total=2.006843s
3: curl: (28) Operation timed out after 2002 milliseconds with 0 bytes received
HTTP=000 start=0.000000s total=2.002438s
4: curl: (28) Operation timed out after 2006 milliseconds with 0 bytes received
HTTP=000 start=0.000000s total=2.006256s
5: curl: (28) Operation timed out after 2004 milliseconds with 0 bytes received
HTTP=000 start=0.000000s total=2.004255s
6: HTTP=200 start=0.240432s total=0.240810s
7: curl: (28) Operation timed out after 2006 milliseconds with 0 bytes received
HTTP=000 start=0.000000s total=2.006661s
8: curl: (28) Operation timed out after 2006 milliseconds with 0 bytes received
HTTP=000 start=0.000000s total=2.006229s
9: curl: (28) Operation timed out after 2006 milliseconds with 0 bytes received
HTTP=000 start=0.000000s total=2.006887s
10: curl: (28) Operation timed out after 2004 milliseconds with 0 bytes received
HTTP=000 start=0.000000s total=2.004550s
11: curl: (28) Operation timed out after 2006 milliseconds with 0 bytes received
HTTP=000 start=0.000000s total=2.006094s
12: curl: (28) Operation timed out after 2002 milliseconds with 0 bytes received
HTTP=000 start=0.000000s total=2.002448s
13: curl: (28) Operation timed out after 2005 milliseconds with 0 bytes received
HTTP=000 start=0.000000s total=2.005761s
14: HTTP=200 start=1.516323s total=1.517025s
15: curl: (28) Operation timed out after 2006 milliseconds with 0 bytes received
HTTP=000 start=0.000000s total=2.006525s
16: HTTP=200 start=0.220031s total=0.220326s
17: curl: (28) Operation timed out after 2006 milliseconds with 0 bytes received
HTTP=000 start=0.000000s total=2.006105s
18: HTTP=200 start=0.259384s total=0.259723s
19: curl: (28) Operation timed out after 2006 milliseconds with 0 bytes received
HTTP=000 start=0.000000s total=2.006687s
20: curl: (28) Operation timed out after 2006 milliseconds with 0 bytes received
HTTP=000 start=0.000000s total=2.006580s
I am facing the same issue with Ansible Galaxy collection downloads.
We noticed that AAP Project Sync is taking around 5–6 minutes specifically at:
TASK [Fetch galaxy collections from collections/requirements.(yml/yaml)]
Projects that do not have a collections/requirements.yml file complete much faster.
To verify whether this was related to our AAP environment, I tested the same collection downloads directly from a Linux VM using ansible-galaxy collection download.
For the last few weeks (~3) we get more and more random failures / success on ansible-galaxy install commands. Can happen on any dependency at any time. Example :
ERROR! Failed to resolve the requested dependencies map. Could not satisfy the following requirements:
* community.library_inventory_filtering_v1:>=1.0.0 (dependency of community.docker:5.0.2)
Hint: Pre-releases hosted on Galaxy or Automation Hub are not installed by default unless a specific version is requested. To enable pre-releases globally, use --pre.
For the last 48h it is hardly workable at all. 90% galaxy-install random failures.
[edit 16.09.2026 15:41 GMT+2]
Wrong: Putting our local galaxy mirror / proxy off-line in order to avoid external failing interactions does not help.
Correct : Putting our local galaxy mirror / proxy off-line provides a bit of relieve. Yet not durable : no new galaxy artefact version can pointed at, while we have this hack on.
[/edit]
Potentially 100’s requirements files to hack as to point github urls.
Is this forum kinda the official place to report the severity is… severely increasing ? What would be the official chanel otherwise ?
Same here, many pipelines taking much longer (~30min) instead of ~5min or completely fail with read timeout. We observed this behavior sporadically since at least for 2 weeks but since 2 days it seems to be permanent.
Problems with galaxy aren’t that often in my experience. But since they do happen from time to time, and if you rely on installing collections anytime, you might want to have a look at mirroring / proxy caching galaxy.
Having some kind of fall-back / redundancy is always a good idea in my experience.
