Overpass 429 errors & rate limits in production

More and more people are experiencing the 429'ers. You're not doing anything wrong on your side. The query still runs when you paste it into overpass turbo. So what broke?

Nothing broke. You met the rate limiter. This post covers what the public Overpass servers are protecting, how the limiter works, and how to build a client that stays out of its way.

What a 429 from Overpass means

The public Overpass instances are shared machines, most of them run by amazing volunteers, and funded purely by donations. The official user's manual puts the load in perspective: each server can fulfil roughly a million requests a day (about 11-12 per second!), shared among tens of thousands of users.

A 429 is not a judgement on your query. It is the server declining to start another request from you right now, either because you already have too many running at once or because you have sent too many too quickly. The query is fine. The pattern of requests is the problem, which means the fix lives in your client, not so much in your query.

And the stakes went up recently. In August 2026 one of the amazing server operators reported a spike in rate-limited requests, pointed at blind retry loops as the cause, and tightened the rules: clients that repeatedly run into a 429 now get banned faster, not just throttled.

How the public limiter works

The main instance tracks demand per user, where a user is normally an IP address. Each user gets a small number of slots: the number of your queries the server will run at the same time. A request that arrives while all your slots are busy waits in a queue for up to 15 seconds. If a slot frees up in time, it runs. If not, you get the good old 429. Under heavy overall load the server also applies growing cooldowns between requests, so the busier the day, the sooner a heavy user gets throttled.

The /api/status endpoint is your guide. Here is an example response:

Connected as: 2036499443
Current time: 2026-08-20T01:40:40Z
Announced endpoint: gall.openstreetmap.de/
Rate limit: 2
2 slots available now.
Currently running queries (pid, space limit, time limit, start time):

Let's take a look at each line: Connected as is the identity the limiter tracks, derived from your IP. Rate limit: 2 means this user gets two slots. The next line says both are currently free, and the final section lists any of your queries running right now. When you are throttled, the useful line changes: instead of "slots available now" the server names the moment your next slot frees, in the form Slot available after: <timestamp>, in N seconds. That is the server telling you exactly how long to wait.

There is also a published fair-use guideline for the main instance: stay under about 10,000 queries and about 1 GB of downloads per day and you can assume you are not disturbing anyone. Those numbers are a guideline, not a contract, and they move with server load.

Telling the limits apart

Overpass says no in more than one way, and they need different reactions.

Do not wait for a Retry-After header: the current version of the Overpass server software does not send one. A 429 arrives as a plain HTML page with no machine-readable wait time, so /api/status is the only place to learn how long to back off.

Client behaviour that stops the bleeding

In rough order of effort:

• Respect the slot count. If /api/status says you have two slots, run at most two queries at a time. Most 429 storms are a thread pool nobody capped.
• Back off on 429, and back off for real. Wait the time the status page names, and with a minimum of 30 seconds; If you use curl's --retry, add --retry-delay 30. A retry loop with no delay is exactly the pattern that is overloading the servers, and it now gets clients banned.
• Cache what you already paid for. OSM data does not change by the minute for most uses. If your pipeline asks the same question every run, store the answer and re-ask weekly, not hourly.
• Consolidate requests. One union query beats a loop of small ones. There is a worked example in the next section.
• Run bulk jobs off-peak. The limiter reacts to total server load, so the same job that gets throttled at midday European time can sail through at night. Peak public server load time is typically between 0600 and 2200 UTC
• Identify yourself. Send a meaningful User-Agent with contact information. That way operators might be able to contact you about your use and help out with query management.

And one thing not to do: when the main instance throttles you, resist the urge to rotate through the other public instances as spare capacity. They are run by volunteers and non-profits too. Private.coffee's instance, for example, advertises no rate limit at all and asks in return for fair use and a heads-up before large jobs. A policy like that is a courtesy to honour, not a loophole.

Reduce the work itself

The limiter measures cost as well as count, so cheaper queries get throttled later. The two knobs every query carries are [timeout:] and [maxsize:], defaulting to 180 seconds and 512 MB. They are not just safety nets: the server weighs what you ask for against what it has free, so demanding a huge timeout or memory ceiling makes your query more likely to be turned away on a busy day. Ask for what the query needs and no more.

Then shrink the work. Tighten the bounding box to the area you actually use, and merge per-type loops into one union. Instead of three requests like this:

[out:json][timeout:10];
node[amenity=cafe](-36.852,174.762,-36.846,174.772);
out body;

// ...then the same again for bench, and again for drinking_water

ask once like this:

[out:json][timeout:10];
(
  node[amenity=cafe](-36.852,174.762,-36.846,174.772);
  node[amenity=bench](-36.852,174.762,-36.846,174.772);
  node[amenity=drinking_water](-36.852,174.762,-36.846,174.772);
);
out body;

We ran that exact query against the main instance while writing this: 192 elements back in a single response, one slot occupied once, instead of three round trips eating three slots' worth of goodwill.

When you have outgrown the free pool

Some workloads do not belong on donated hardware, and the people who run the public servers say so themselves. The manual's own list of cases that call for a private instance includes scraping large areas, asking for millions of individual elements, and using a public server as the backend of an app. If your Overpass usage is scheduled, business-critical, or growing, the 429s are the infrastructure telling you that you have graduated. Due to the recent explosion of AI driven projects, the tireless operators are having to clamp down.

The honest options are two. Run your own instance: it is real Overpass and it works, at the cost of a server to size, a planet to import, and a database to keep current. Or pay someone to run one and keep your existing queries. Full disclosure: Overspan, whose blog you are reading, is one of the paid options. The neutral list of every public and commercial instance lives on the OSM wiki.

Either way, moving production load off the volunteer servers is not just good for you. It is the best way you can graduate and allow for future budding OSM builders to get the best start.