Mastodon ‘Rate Limit Exceeded’ Message: How Long to Wait

The ‘Rate Limit Exceeded’ message in Mastodon appears when you send too many requests to a server in a short time. This can happen when you refresh your timeline too fast, use third-party apps that poll the server aggressively, or run automated scripts that interact with the Mastodon API. The server deliberately slows you down to protect its resources and ensure fair access for all users.

This article explains why rate limits exist, how long you typically need to wait before the limit resets, and how to avoid triggering the message again. You will learn the exact timeout durations for common actions such as posting, following, and fetching the timeline. You will also get practical steps to reduce your request frequency and keep your account active without interruptions.

Why Mastodon Enforces Rate Limits

Mastodon instances are run by volunteers or small teams on shared or limited server hardware. Each incoming request consumes CPU time, memory, and database connections. Without rate limits, a single user or a misconfigured client could saturate the server, degrading the experience for everyone else on the instance.

Rate limits are applied per IP address, per user token, and sometimes per endpoint. The most common limit is 300 requests per 5 minutes for the main API. When you exceed that threshold, the server returns HTTP status code 429 with the body {"error":"Rate limit exceeded. Try again in X seconds."}.

How the Server Tracks Your Requests

Mastodon uses a sliding window algorithm. Each request is logged with a timestamp. The server counts how many requests you made in the last 5 minutes. If the count exceeds 300, the server blocks further requests until the oldest timestamp falls outside the window. This means the wait time is not fixed; it depends on when you made the first request that pushed you over the limit.

How Long You Must Wait for Rate Limit Reset

The wait time varies by the type of request and the instance configuration. Below are the standard timeout durations for the most common actions.

1. General API rate limit (300 requests per 5 minutes)
   If you exceed this limit, you must wait until the oldest request in your sliding window expires. In practice, that is usually 60 to 300 seconds from the moment you receive the 429 error. Check the response header Retry-After for the exact number of seconds the server recommends.
2. Posting statuses (toots)
   Most instances allow about 30 statuses per 30 minutes. If you hit this limit, wait 30 minutes before posting again. The server returns the remaining time in the X-RateLimit-Reset header.
3. Following or unfollowing accounts
   Mastodon limits follow actions to roughly 100 per hour. If you exceed this, wait 60 minutes. The limit resets exactly 60 minutes after the first follow action that triggered the block.
4. Fetching the public or home timeline
   Manual refreshes are rate-limited to about 1 request per second. If you refresh more often, the server may return a 429 error. Wait 60 seconds before refreshing again.
5. Searching for hashtags or accounts
   Search endpoints have a lower limit of 30 requests per minute. If you exceed this, wait 2 minutes before searching again.

To see your exact rate limit status, open the browser developer tools (F12) and inspect the network tab. Look for any API response that includes the headers X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset. The X-RateLimit-Reset header contains a Unix timestamp. Convert that to your local time to know the exact second when the limit resets.

Common Mistakes That Trigger Rate Limit Errors

Many users hit the rate limit without realizing they are making too many requests. The following scenarios are the most frequent causes.

Using Multiple Third-Party Clients Simultaneously

If you have the official Mastodon web app open, plus a desktop client like Whalebird, and a mobile app like Tusky, each client sends its own requests. Together they can quickly exhaust the 300-request limit. Close unused clients or log out from apps you are not actively using.

Aggressive Auto-Refresh Browser Extensions

Extensions that auto-refresh tabs every few seconds can trigger rate limits even when you are not actively reading. Disable any auto-refresh extension for your Mastodon tab. If you need to monitor a timeline, use the built-in refresh button instead of automated reloads.

Running Scripts or Bots Without Proper Pacing

If you use a custom script to fetch data from Mastodon, make sure it includes a delay of at least 1 second between requests. Many instance admins permanently block IPs that ignore rate limits. Use the sleep() function in your script to respect the server limits.

Sharing an IP Address With Other Users

If you are on a school, office, or public Wi-Fi network, your IP address is shared with many other Mastodon users. Their requests count toward the same 300-request pool. If you get rate-limited while others are also active, wait 5 minutes and try again. Consider using a personal VPN if this happens often.

Rate Limit Comparison: Mastodon vs Twitter vs Bluesky

Understanding how Mastodon’s rate limits compare with other platforms helps you set realistic expectations for posting and browsing frequency.

Item	Mastodon	Twitter (X)	Bluesky
Default requests per window	300 per 5 minutes	450 per 15 minutes (user auth)	5000 per 5 minutes (app passwords)
Post limit	30 per 30 minutes	300 per 3 hours	100 per minute
Follow limit	100 per hour	400 per 24 hours	100 per hour
Timeline refresh	1 per second	1 per 15 seconds	1 per second
Header for reset time	X-RateLimit-Reset	X-RateLimit-Reset	ratelimit-reset

Bluesky offers a much higher default request limit, but its follow limit is similar to Mastodon. Twitter’s per-window limit is higher, but its post limit is more restrictive over a longer window. Mastodon’s limits are moderate and designed to protect smaller servers from overload.

What to Do If Rate Limits Persist

If you consistently hit the rate limit even after spacing out your requests, contact your instance admin. The admin can raise your personal rate limit by adding your user ID to the config/initializers/rack_attack.rb file on the server. Ask politely and explain why you need a higher limit, for example if you run a legitimate bot that posts infrequent updates.

You can also switch to a larger Mastodon instance with higher default limits. Instances like mastodon.social or mstdn.jp often have more generous rate limits because they have more server resources. Check the instance’s about page for its specific rate limit policy before joining.

You now know that the ‘Rate Limit Exceeded’ message typically resolves within 5 minutes for general API use, within 30 minutes for posting, and within 60 minutes for following. Check the X-RateLimit-Reset header in your browser’s network tab to get the exact reset time for your situation. To avoid future blocks, close unused third-party clients, disable auto-refresh extensions, and add a 1-second delay between any custom script requests. If you need sustained high-volume access, ask your instance admin for an exception or move to a larger server.