What Does "Rate Limited" Mean? (Twitter, Discord, APIs and the 429 Error Explained)

You scroll, you refresh, you tap a bit too enthusiastically, and the app stops: “You are being rate limited.” Or “Rate limit exceeded.” Or nothing loads for a minute and then everything is fine again. You weren’t banned. You weren’t hacked. You hit a counter.

What does “rate limited” mean?

Rate limiting means a service has a cap on how many requests it will accept from you in a given window of time, and you went over it. Every time your phone asks the server for something (a feed refresh, a message send, a search) that’s one request. The server keeps a tally per user, per account, per IP address, or per app. Cross the line and the next requests are refused until the window rolls over. Usually that’s seconds; sometimes it’s minutes; in Twitter’s July 2023 “rate limit exceeded” episode, it was a hard daily cap on how many posts you could read at all.

On the web, the refusal has a name: HTTP status 429 Too Many Requests. Well-behaved servers send it with a Retry-After header saying how long to wait, and well-behaved apps read that header and wait.

Why do apps rate limit on purpose?

Four reasons, and they’re all about the server, not about you.

Capacity. A server can handle a finite number of requests per second. If one user, one bot or one buggy script can send ten thousand a second, everyone else’s experience depends on that one client’s manners. A limit converts “first come, first served” into “everyone gets a fair share”.

Cost. Each request costs CPU, bandwidth and sometimes a paid downstream call. A limit is a budget.

Abuse. Password guessing, scraping, spam, buying up every ticket. All of them look like one account doing something normal, far too fast. A limit of five login attempts a minute makes brute-forcing a password take years instead of hours.

Protection from mistakes. The most common thing that gets rate limited isn’t an attacker; it’s a developer’s script stuck in a loop. A limit turns an outage into a 429.

How does the server count?

A few standard algorithms, from simplest to most common.

Fixed window. Count requests per minute. At the top of each minute, reset to zero. Simple, but it has an edge problem: 100 requests at 11:59:59 and another 100 at 12:00:00 is 200 requests in two seconds, all allowed.

Sliding window. Count requests in the last 60 seconds from right now. Fixes the edge problem at the cost of remembering timestamps.

Token bucket. The one most big services use. Imagine a bucket that holds, say, 100 tokens. Tokens drip into it at a fixed rate, 10 per second. Each request takes one token; if the bucket is empty, the request is refused. The beauty is that it allows bursts (you can spend all 100 at once if you’ve been quiet) while still enforcing an average (10 per second over the long run). Tapping refresh twenty times in a row is fine; doing it for a solid minute is not.

Leaky bucket. The mirror image: requests pour in, and they’re let out at a steady rate. Smooths traffic instead of allowing bursts.

In practice the counters live in a fast in-memory store like Redis. The pattern for a fixed window is two commands: increment the key user:123:minute:1699999980 and set it to expire in 60 seconds. One round trip, a few microseconds, and every server in the fleet shares the same count.

Why does Discord rate limit me for sending messages?

Because sending messages is the thing bots abuse most. Discord’s limits are per channel and per action: send too many messages, reactions or edits in a few seconds and the client tells you to slow down. It’s the same reason a game won’t let you spam chat. The limit is tuned so that typing like a human never trips it and pasting a loop does.

How do I avoid being rate limited?

If you’re a user: stop tapping, wait the time it tells you, and if you’re on a shared network (an office, a university, a VPN) remember that everyone behind that one IP address may be sharing a bucket.

If you’re writing code against an API:

1. Read the limits in the docs before you write the loop.
2. Check for 429 and honour Retry-After.
3. Back off exponentially: wait 1 s, then 2, then 4, then 8, with a little random jitter so a thousand clients don’t all retry at the same instant.
4. Cache. The fastest request is the one you don’t make.

Rate limiting isn’t the service being difficult. It’s the service staying up, for you and for everyone sharing it, by making the one rule that scales: nobody gets to go faster than their share.

Was this useful? The video version is on YouTube — a like or a comment there helps more people find it. New guides every week: subscribe to DigiCirq.

Topics: what does rate limiting mean · rate limited twitter · rate limited discord · rate limiting api · 429 too many requests · rate limiting algorithms · token bucket · rate limiting with redis