"Rate limit exceeded" is one of the most frustrating messages on Bluesky because it usually appears when you were not doing anything unusual. This post explains what triggers it, how long you actually have to wait, and how to stop it happening – both for ordinary users and for developers writing against the API.
What the Error Actually Means
Bluesky's servers cap how many requests any one account or IP can make in a rolling time window. Exceed the cap and the server responds with HTTP 429 Too Many Requests, which clients surface as "Rate limit exceeded."
This is not a ban, a suspension, or a moderation action. It is a throttle, it is temporary, and it resets on its own.
If You Are a Normal User
How long do I have to wait?
Usually five minutes to an hour. Most limits are enforced on short rolling windows. If you close the app, wait, and come back, it will almost always be gone.
Do not repeatedly retry. Hammering the endpoint while rate limited extends the problem on some limits rather than shortening it.
Why did this happen to me?
| Cause | Fix |
|---|---|
| Scrolling fast through a huge thread or feed | Slow down; the limit resets in minutes |
| Mass following or unfollowing | Space out bulk actions – write operations have their own tighter limits |
| Multiple accounts signed in on one device or network | Limits can apply per IP; sign out of accounts you are not using |
| A third-party tool syncing in the background with your credentials | Audit which apps you have authorized and revoke ones you do not use |
| Shared or corporate network / VPN | Everyone behind that IP shares a bucket; switch networks |
| Rapid login attempts | Session creation is one of the tightest limits – stop retrying and wait |
The one that catches people out
A poorly-behaved third-party analytics or scheduling tool authorized against your account can burn your entire limit in the background while you are doing nothing. If you are getting rate limited regularly and cannot explain it, revoke app authorizations you do not actively use and see if it stops.
If You Are a Developer
The details are in our full Bluesky API rate limits guide, but here are the parts people get wrong most often.
Read the headers – do not guess
Every response carries the current state of your budget:
ratelimit-limit– the ceiling for this windowratelimit-remaining– how many requests you have leftratelimit-reset– Unix timestamp when the window resetsratelimit-policy– the policy being applied
Back off before you hit zero, not after you get a 429. Watching ratelimit-remaining and throttling proactively is the difference between a service that works and one that spends its life in exponential backoff.
Respect the reset timestamp
When you do get a 429, use ratelimit-reset rather than a fixed sleep. Sleeping 60 seconds when the window resets in 4 minutes just gets you another 429.
Write operations are the expensive ones
Creating records – posts, likes, follows, blocks – is governed by tighter limits than reads, and there are longer-horizon caps on top of the short-window ones. If you are writing a bot that follows accounts or posts on a schedule, this is where you will hit a wall. Our Bluesky bot guide covers pacing.
Session creation is tightly limited
A very common bug: creating a new session on every request instead of persisting and refreshing the one you have. This will rate limit you almost immediately. Create a session once, store the refresh token, refresh when it expires. See our OAuth implementation guide.
Do not poll when you can stream
The single biggest architectural fix. If you are polling endpoints on a timer to detect new posts, you are burning rate limit budget for data the firehose will push to you for free.
The firehose and Jetstream are not rate limited the way the XRPC endpoints are, because you open one connection and receive everything. If your app watches for new content, stream it. Our firehose streaming guide and Jetstream guide cover both options – Jetstream is dramatically lighter if you do not need full CAR block verification.
Cache aggressively
Profile data, handle resolution and DID documents change rarely. Caching them for even a few minutes eliminates a large fraction of typical request volume.
Handle read-after-write correctly
A related trap: retrying reads in a tight loop because a record you just wrote has not appeared yet. That is not a failure to retry through – see our read-after-write guide for the correct pattern.
A Sane Retry Policy
- Check
ratelimit-remainingon every response and throttle at ~10% remaining. - On 429, read
ratelimit-resetand sleep until then plus a small jitter. - Use exponential backoff with jitter for anything without a reset header.
- Cap total retries and surface a real error rather than looping forever.
- Never retry a write blindly – you risk duplicate records.
Frequently Asked Questions
Is being rate limited the same as being banned?
No. It is a temporary throttle with no moderation implications and it clears automatically.
Can I request a higher rate limit?
There is no self-serve tier upgrade. The right answer for high-volume applications is architectural: stream instead of poll, cache aggressively, and run your own infrastructure where appropriate.
Does using a third-party client cause rate limits?
A well-built one should not. A client that polls aggressively or re-authenticates constantly absolutely can.
Do limits apply per account or per IP?
Both, depending on the endpoint. Some limits are keyed to the authenticated account, others to the source IP – which is why shared networks can rate limit you through no fault of your own.
Tools That Play Nicely with the API
- Skyscraper for iOS – built with proper caching and backoff
- Trending Hashtags – firehose-powered, no polling required on your end
- Keyword Alerts – we run the stream so you do not have to