Website doesn't work at all for me
When I try to open https://osm-boundaries.com/map, I get four "Failed to report error." popups in a row and then on the left it says "Failed to load boundaries." instead of having the usual list of countries
When I try to open https://osm-boundaries.com/map, I get four "Failed to report error." popups in a row and then on the left it says "Failed to load boundaries." instead of having the usual list of countries
Mine also doesn't work, it was fine until 3 days ago. It currently appears like this

It’s a great website, but now it’s unusable—it’s really a shame. Just a few months ago, I could use it with ease.
The issue appears to be server side, as ive tried opening it on another device and it does the same. I hope they will address it soon as it is quite a serious issue for many
@mcliquid The JS bundle 404 was unrelated, and affected all. Honestly we are a bit unsure of why. It seems to be a bug in Docker actually. It might sound far-fetched, but due to how we did the last release it didn't find every config.
This also changes the cookie domain to be correct. Your analyzes was great, sadly it was based on a faulty release.
Please test again. To our knowledge it should work now as long as no client software blocks any requests.
@mcliquid The JS bundle 404 was unrelated, and affected all. Honestly we are a bit unsure of why. It seems to be a bug in Docker actually. It might sound far-fetched, but due to how we did the last release it didn't find every config.
This also changes the cookie domain to be correct. Your analyzes was great, sadly it was based on a faulty release.
Please test again. To our knowledge it should work now as long as no client software blocks any requests.
It is fixed. Thank you for your action
@mcliquid The JS bundle 404 was unrelated, and affected all. Honestly we are a bit unsure of why. It seems to be a bug in Docker actually. It might sound far-fetched, but due to how we did the last release it didn't find every config.
This also changes the cookie domain to be correct. Your analyzes was great, sadly it was based on a faulty release.
Please test again. To our knowledge it should work now as long as no client software blocks any requests.
It is ready for use.thank you very much!
still not working for me, across different browsers. Yesterday evening at least it was working on Chrome but not Yandex, which is my main browser; despite cleaning cookies and disabling adblock (and it's telling me it's not blocking any tracker)
the console says this:
| 19:49:03 | ERROR | Reported error as c818bb11f65f96ae9898de50fffd607c. |
| 19:49:03 | INFO | Loading root boundaries tree... |
| 19:49:03 | ERROR | Reported error as 70155e6b8d25a92cbca1acd627c27340. |
| 19:49:04 | ERROR | Reported error as 7822e06bf8db906c09dd8d2adad90deb. |
| 19:49:04 | ERROR | Reported error as 96d355c101cc47cc62a8bbeffde432ab. |
while https://osm-boundaries.com/api/web/databases/ shows a lot of text like this:
osm20260907":{"db":"osm20260907","name":"2026-09-07","state":3,"is_latest":true,"is_basic_allowed":false},"osm20260803":{"db":"osm20260803","name":"2026-08-03","state":3,"is_latest":false,"is_basic_allowed":false},"osm20260706":{"db":"osm20260706","name":"2026-07-06","state":3,"is_latest":false,"is_basic_allowed":true},"osm20260608":{"db":"osm20260608","name":"2026-06-08","state":3,"is_latest":false,"is_basic_allowed":false},"osm20260511":
...
24","state":3,"is_latest":false,"is_basic_allowed":false},"osm20100317":{"db":"osm20100317","name":"2010-03-17","state":3,"is_latest":false,"is_basic_allowed":false}}
my setup didn't change since my last post
Thanks, I found something more specific.
The original issue does not seem to be completely resolved.
/api/web/databases/ now works correctly for me and returns the expected JSON.
However, one of the API requests made by the map, for example:
.../api/web/boundaries?...
returns HTTP 200, but the response body is not API JSON. It is the complete Anubis challenge HTML page:
<title>Dein Browser wird geprüft!</title>
including a new anubis_challenge.
This also explains why there are no failed/red requests in DevTools despite the map failing.
The frontend then throws:
TypeError: can't access property "map", n.admin_levels is undefined
and shows:
Failed to load boundaries.
So the frontend expects the boundary API response, but Anubis intercepts that API request and returns its challenge page with status 200 instead.
Interestingly, /api/web/databases/ works at the same time, so Anubis appears to allow some requests while challenging at least the boundaries API request.
EDIT:
I can now reproduce this intermittently.
After a hard refresh, the site works correctly and the boundaries API returns normal JSON. I can use the map for a while.
After some use, Failed to load boundaries appears again.
So this is not a permanently broken API route. It appears that the Anubis authentication becomes invalid during an active session.
Earlier, on a failing API request, I observed that the techaro.lol-anubis-auth-* cookie existed in Firefox's cookie storage, but was not included in the request. The response then returned the Anubis challenge HTML with HTTP 200 and also sent:
techaro.lol-anubis-auth-...; Max-Age=0
A hard refresh makes it work again temporarily.
This seems consistent with an Anubis cookie/session issue rather than the boundaries API itself.
I think I found the cause, at least in my case.
I opened
/api/web/databases/directly and inspected the Anubis challenge in Firefox DevTools.The JS challenge runs and the browser requests:
https://osm-boundaries.com/.within.website/x/cmd/anubis/api/pass-challenge?...That request returns HTTP 500.
More importantly, the response contains these
Set-Cookieheaders:techaro.lol-anubis-auth-...; Domain=prod.osm-boundaries.com; ...techaro.lol-anubis-cookie-verification-...; Domain=prod.osm-boundaries.com; ...However, the request host is
osm-boundaries.com, notprod.osm-boundaries.com.Firefox therefore does not store these Anubis cookies. Cookies in general are enabled and working — other cookies such as
PHPSESSIDforosm-boundaries.comare stored and sent normally.This seems to explain why Anubis subsequently reports that cookies are disabled, although they aren't.
It looks like the Anubis/reverse-proxy configuration may be using the internal/production hostname
prod.osm-boundaries.comas the cookie domain instead ofosm-boundaries.com.I also get 404 responses for the map JS bundles (
page-map.bundle.min.js,page-vendor-leaflet.bundle.min.js, etc.), although I'm not sure yet whether that is related.