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.