Was seeing 502 errors and failed collection downloads a couple of hours ago, but everything seems to be back up and working now
Yes. Getting a 502 error at the moment on a pretty consistent basis.
ERROR! Error when finding available api versions from
- explicit_requirement_ansible.windows (https://galaxy.ansible.com) (HTTP Code:*
- 502, Message: Bad Gateway)*
To me the API is completely down (see a 502 cloudflare error) and the UI takes minutes if it loads at all
UI hangs like this
API:
We have seen similar things over the last couple days where it is going glacially slow and taking upwards of 15 minutes to resolve the collections on our execution environment pipeline 
I am seeing the same issues, when attempting to connect from Azure’s Central US region. Repeated timeouts and long waits for responses, rendering any pipeline leveraging a Galaxy collection unreliable. This is a major issue, but it doesn’t seem as if anyone knows who to call to get it resolved. Meanwhile, the status page shows green lights all the way, which is a bit absurd.
@mariolenz Agreed, but its not always easy.
My organization has configured Artifactory to “proxy” the ansible-galaxy repository. Unfortunately it does not help in this case because the api calls are still being made upstream - even when the collection has a pinned version number.
Unless the proxy also caches those responses, you are in trouble. Artifactory does not appear to be this solution. 
I also agree with a previous comment @sivel made in another thread about pre-packaging collections and ryour ees pre-packaging collections / roles rather than downloading them live.
Do you know if work is active on the ansible-galaxy client at this time? I am not python developer, but I can submit some requests / open some discussions for possible improvements.
Hello, Galaxy dev here
Sorry for the friction this has caused over the past few days.
Today, we performed the Galaxy upgrade and cleaned up the stale environment, which seems to have helped with the issue. Performance has stabilized and is back to normal for now. We are monitoring system health while continuing to look into the root cause.
Thanks!
Thank you, @jerabekjiri! We seem to notice a few times a year when the API becomes totally unavailable or unreliable for a period of time, but the experience over the last 2 day was new for us.
In the future what’s the best way to report issues like this for the best response, if not here? Is there a way that we, as community members and users, can help reduce these hiccups in the future? The thread that @mariolenz shared for mirroring/proxying is new to me, and I’ll be looking into some of these solutions. It’s been a while since I’ve gone out of my way to look, but is there any official Ansible documentation to encourage and provide examples of caching strategies that would minimize the load and reliance on https://galaxy.ansible.com?
I maintain my own EE with the collections that I rely on, and fall back to it in AWX when the API isn’t working well, but using it in my CIs never crossed my mind and may be an easy win.
Here on the forum is the right place to raise issues like this, and tag your post using the galaxy-ng tag. You can also use the @CommunityEngTeam group.
I’m not aware of any existing documentation like this on docs.ansible.com. The docs are always open to contributions at GitHub - ansible/ansible-documentation: Ansible community documentation · GitHub to include useful projects from Mirroring / proxy caching galaxy on an existing or new page.
At CfgMgmtCamp 2026 Ansible Contributor Summit, there was discussion of deploying a community status page to monitor community services and other related infrastructure: Ansible Community Status page & Notifications - Please join the dicussions there if you’re interested.
Hello.
Unfortunately, mirroring / proxying does not protect against this. We have mirror set up already.
The issue is
- Say we already have an artefact version cached in our mirror
- Fine ? If one pulls it, our mirror should serve it happily. Or is it ?
- Well no ! Because there are some more galaxy specific checks done with external calls, even when artefact is already cached
- 90 % gallaxy-install failed
- Our hack : turn our galaxy mirror to off-line mode to stop any external interactions
- drawback : any non mirrored new artefact cann’t be served by our mirror
I am surprised. To me this problem sounds like a major P1 issue. World wide 2-3 weeks low impact + 48h high impact : is it at all acceptable ? Really ?
Thanks for the job. 
I don’t disagree, but it seems Red Hat does.
When I contacted support, I was told “Since Ansible Galaxy is a community site, we can’t really offer support in regards to it or an ETA on when this will be fixed. If you rely on collections available on Ansible Galaxy, I would strongly recommend setting up Private Automation Hub in your environment.”
I’ve found this has been fairly typical of my experience with Red Hat over the last decade, which is unfortunate.
In my imagination, Ansible Galaxy is Red Hat’s infrastructure where they host Ansible integrations, community and otherwise. It’s one thing to not provide support for an integration they didn’t write. Pretending that Ansible Galaxy isn’t Red Hat’s infrastructure is something different.
Maybe they should instruct their partners to not configure AAP to rely on Galaxy in the first place.
That sounds like a specific issue with your mirroring / caching solution. The proper behavior would be:
- If a client hits the mirror/cache, it first checks whether it is stale by checking the original Galaxy, with strict timeouts + maybe retries.
- If Galaxy doesn’t reply in time, it provides the old data and sets a mark that the data needs to be refreshed eventually.
- In the background, the mirror/cache regularly checks the data that was marked as “needs to be refreshed”. If something can’t be refreshed repeatedly, a warning is raised somehow (through UI / … of the mirror/cache).
That should result in almost 100% successful ansible-galaxy installs for collections that were already installed successfully in the past. (For new things, obviously this can only be successful if Galaxy can be reached.)
I don’t know if there’s any solution around that implements this, but that’s how I would implement it if I would be writing a Galaxy cache/mirror.
This has been OK for a while now, but I have started to get the “Read operation time out” error again…
same - and the UI on https://galaxy.ansible.com/ is super slow again
Is the problem back?
Just to add - we are proxying via Artifactory - but it affects the proxy too since it must check upstream which seems to be incredibly slow rather than down so its not being detected as offline. It just means that all our builds are timing out right now
If you build with newer images for 2.5 e.g then you can add --timeout to ansible-galaxy, older images has older ansible-galaxy that does not support a --timeout parameter, so these will still fail with “Read Operation timed out”. Maybe this can help mitigate some of the problems for your builds…
Same here, the following task used to run for a couple of seconds, whereas it’s taking a couple of minutes each time now. This has been going on for a little while now, looks like it’s an issue multiple people are having.
Task in Ansible AWX
TASK [Fetch galaxy collections from collections/requirements.(yml/yaml)]
Just this task has been running for 6 minutes now, to fetch a total of 4 collections, and hasn’t finished yet.
We are also seeing much slower Ansible collection installations from Galaxy in the past few days.
@jerabekjiri Is there something you can do to address this?
Just for the record, I am seeing these errors/timeouts in CI runs for community.general and community.openwrt in almost every run these days.
I mentioned that in the Ansible Community Working Group chat, and the suggestion given was to use GitHub - sivel/amanda: A simple web application, to mimic the v3 API endpoints for Ansible Galaxy Collections, with no database, just a directory with artifacts · GitHub but I got some mixed feelings about this.