Twitter (X) Rate Limit Exceeded Error: Causes, Fixes, and Reset Time

Rate Limit Exceeded on Twitter (X) means an account or application has used the allowed number of actions or API requests within a specific period. The error can affect posts, replies, follows, Direct Messages, or a particular API endpoint.

Moving from a phone to a browser usually does not reset the counter because X aggregates account activity across all devices and connected applications. If the problem appeared during authentication, first try to log in to X through a browser: a password error or protective login lock requires a different solution from an exhausted posting limit.

The situation is more complicated for an agency or SMM team. One employee schedules posts, another replies to the audience, and an analytics service polls the API at the same time. A workflow for multiple X accounts should identify the responsible person, the time of the last action, and active integrations. Otherwise, the team sees the error but cannot see who consumed the quota.

Check the account history separately. After a change of owner, device, or network, the error may coincide with a security check. If a profile was acquired for legitimate brand work, use a controlled first login to an acquired X account without launching bulk actions and new integrations at the same time. This does not increase limits, but it removes unnecessary variables from the diagnosis.

What does Rate Limit Exceeded mean on Twitter and which actions does it stop

Rate Limit Exceeded means a specific action has been temporarily rejected after its technical quota was exhausted. It is not an automatic account suspension. If X blocks only replies, the profile may still be able to read the feed or send other permitted requests until their separate counters are exhausted.

The platform uses several types of restrictions. Regular users most often encounter limits on posts, replies, follows, and Direct Messages. Developers see HTTP 429 when an application exceeds the quota for a particular API endpoint. A request to confirm an email address, phone number, or CAPTCHA indicates an ownership check or temporary feature restriction instead.

Record the difference before attempting any fix.

This classification saves time. Clearing the cache will not restore an exhausted daily quota, and waiting will not complete a check when X explicitly asks for email confirmation.

Why does Twitter keep showing the rate limit message

Twitter continues to display Rate Limit Exceeded when the time window has not ended or a connected application keeps consuming the same quota. A shorter half-hour limit within a daily allowance can also be responsible. A small number of visible actions during the day therefore does not prove that the counter is still available.

The most common causes can be checked without guessing:

• too many original posts or replies within a short period
• bulk follows or unfollows that X evaluates separately from the published daily limit
• 500 Direct Messages sent in one day or an aggressive messaging pace
• several schedulers, CRM tools, or analytics services with access to one account
• an automatic retry loop after HTTP 429 that ignores the time in x-rate-limit-reset
• several operators working in parallel without a shared activity log
• a temporary reduction in technical limits during high X load
• a security check after changing a device, IP address, or following several failed logins

To identify the cause, a team can review activity from the previous 30 minutes: posts, replies, and integration activity. When three services send requests to the same API endpoint every few seconds, the user's manual activity may be almost zero while the API quota is already exhausted.

There is another useful signal. If the error disappears for feed viewing but remains for replies or follows, it likely concerns a separate action limit. If X displays an ownership verification screen, stop testing other functions and complete the proposed process.

Which Twitter and X limits apply in 2026

As of October 2026, the official X help center publishes separate technical limits for account actions. It lists 50 original posts and 200 replies per day for unverified accounts. The page also retains older wording about 2,400 updates per day divided into half-hour intervals.

The help article does not explain how the 2,400-update limit relates to the separate restrictions for unverified accounts. Therefore, 2,400 should not be treated as a universally available number of posts for every profile.

The values below come from the official X help center. Before planning bulk operations, check the current terms for your account and relevant API: https://help.x.com/en/rules-and-policies/x-limits.

These are maximum allowed values, not a recommended operating pace. For example, a 400-follows-per-day limit does not mean that a new profile should perform them in one batch. X separately evaluates overly intensive following, duplicate content, and automated behavior.

Advertising teams should not mix organic activity quotas with advertising operations. Campaign planning, audiences, and metrics belong to a separate Twitter and X advertising workflow, while a reply or follow limit is not an advertising budget or impression quota.

How long does Rate Limit Exceeded last and when does the counter reset

Rate Limit Exceeded lasts until the relevant time window ends, and there is no universal timer for every action. Individual API endpoints may use 15-minute or 24-hour windows; the specific interval depends on the API rules.

For regular account actions, X may apply daily limits and shorter half-hour limits. For some temporary login locks, the official help center gives a guideline of about one hour, although the actual duration can differ.

Use the error type rather than the popular advice to "wait 15 minutes."

Do not set a timer for exactly 15 minutes if the error appeared after 500 DMs or the daily follow limit. Conversely, there is no need to wait a day after HTTP 429 if the response header shows a reset in seven minutes.

The device time zone does not determine the reset moment either. The X server tracks its own window, so changing the clock or starting a VPN has no effect. For the API, use the Unix time in the response header. For regular actions, record the time of the first rejection and wait for the relevant interval to end.

In a team log, specify the exact time of the next check, such as 14:35 Kyiv time, instead of writing "in an hour." An operator on another shift will then avoid repeating the action too early. If employees work in different time zones, store time in UTC and display the local value in the log interface.

If the error remains after waiting, compare the exact new message with the original one. A request to confirm the account may replace Rate Limit Exceeded. That is a new state, and additional waiting alone will not resolve it.

How to fix Twitter Rate Limit Exceeded without unnecessary retries

To fix Rate Limit Exceeded, identify the blocked action, stop retries, check active integrations, and wait for the relevant reset. If X requests verification, complete it instead of trying to change the device or network.

The diagnostic sequence should be the same for one account and for a large team:

1. record the exact error text, time, account, and failed action
2. stop repeating the blocked action to avoid creating unnecessary log entries
3. check whether other X functions work, but do not launch a large test series
4. review connected applications and pause unnecessary schedulers or analytics tasks
5. match the action to the published limit or the relevant API endpoint
6. check x-rate-limit-reset when the server returns HTTP 429
7. complete email, phone, or CAPTCHA verification if X explicitly requests it
8. repeat one action only after the relevant time window ends
9. record the result and new permitted time in the team log

The first verification attempt should be a single action. If a post succeeds, do not immediately launch a queue of dozens of delayed posts. Resume work gradually and watch for another warning. After the limit resets, an API worker checks the remaining quota with one request before restarting the queue.

Consider a specific case. At 10:12, an editor cannot publish a post, and at 10:14, an analytics service receives HTTP 429. These may be two different limits. The editor checks post history and the interface message, while the developer checks the API endpoint, authorization key, and response headers. It is easy to combine both events under the word "limit," but waiting together at random will not reveal the cause.

Another case occurs after a password change. A scheduler continues to use an old token, an operator tries to log in several times from a new device, and X requests ownership confirmation. Account verification and revoking the unnecessary integration take priority here. The post counter may not be involved at all.

Save a screenshot of the error before clearing the cache or authenticating again. It will let the next shift see the exact message and incident conditions.

Clear the cache only when the interface displays an outdated message after the limit has actually reset. The cache does not change the server-side counter.

Do not move previously scheduled bulk actions to another profile to bypass the restriction. If the account has a legitimate business function, restore normal operation under X rules. For profiles with a changed owner, separately review the safe workflow for Twitter accounts, especially before connecting new services.

How should developers handle HTTP 429 and X API headers

HTTP 429 means a request has been restricted because the applicable limit was exceeded. Depending on X API rules, it may apply to an endpoint, user, application, or a combination of them. The correct response is to pause until the limit resets, not to send continuous retry requests. User and application limits can differ even for the same API endpoint.

For basic control, inspect these response headers when the X API returns them:

• x-rate-limit-limit shows the maximum number of requests in the window
• x-rate-limit-remaining shows the number of requests still available
• x-rate-limit-reset contains the Unix time of the next reset

When x-rate-limit-remaining reaches zero, the worker pauses requests governed by that quota. If the headers are missing, rely on the endpoint documentation and other available restriction signals. Add a small time buffer before resuming to avoid another rejection at the exact second boundary.

For network errors, use exponential backoff between retries, but do not substitute it for the official reset time after an HTTP 429 response.

To determine which queue stopped, store the following fields in the integration log:

• API endpoint and authorization type
• available x-rate-limit-remaining and x-rate-limit-reset values
• task identifier and account

Without these data, it is difficult to determine which quota the 429 error concerns.

Allocate quota in advance as well. If a report requires 120 requests in 15 minutes and the available quota is 300, do not assign the entire remaining quota to one task. Keep a reserve for manual checks, other workers, and retries after network failures. Always confirm the current limit for your endpoint and API plan because X may change the values.

Caching reduces the number of requests without losing useful data. If several employees open the same report, the application can store the result briefly instead of requesting it from X again. Cache duration depends on the task: a one-minute delay is barely noticeable for monthly analytics, while real-time monitoring requires a different balance.

Requests must be coordinated when several workers share one quota. A shared accounting mechanism tracks the remaining allowance and manages the queue. After HTTP 429, it pauses every task that uses that quota. Otherwise, five processes may simultaneously read a stale remaining value and quickly exhaust the reserve.

Before restarting, check whether the application's token, plan, or permission set changed. HTTP 401 and 403 indicate other problem types, although operators sometimes call them a "limit" in the log. Store the HTTP status, API endpoint, and a short response-body excerpt in separate fields. The 429 error will then remain distinguishable from authentication failures.

How can a team prevent recurring limits in its workflow

A team reduces recurring incidents when every account has an owner and all manual and automated actions enter a shared log. This makes it clear whether an operator, scheduler, or API worker consumed the quota.

A minimum incident log should contain these fields:

• account identifier and responsible employee
• exact error text without paraphrasing
• event time and time zone
• blocked action or API endpoint
• active device, browser profile, or application
• x-rate-limit-remaining and x-rate-limit-reset values for the API
• time of the next permitted attempt
• result of the check or recovery

A team working with three clients does not need a complex system. A table with one row per incident and a publishing calendar is enough. For dozens of profiles, add task-blocking rules: if one worker receives 429, other processes using the same authorization key must stop sending requests.

A weekly log review will reveal patterns. For example, 429 may appear every Monday after a large report starts, or replies may be blocked when two operators work at the same time. The team can then change the schedule or distribute the permitted load instead of fixing the same incident manually.

The content planner should include the statuses "ready," "scheduled," "published," and "paused due to limit." One responsible person moves the card between states. This prevents duplication when an editor and community manager both try to publish the same material after the first error.

API tasks need a separate request budget. Before launch, a worker receives an allowed share of the quota while leaving a reserve for other processes. If the remaining allowance falls to a set threshold, the task completes the current data page and queues continuation for after the reset. This arrangement remains predictable even while preparing large reports.

Manual activity should not be reduced to artificially precise "safe" numbers. X does not publish a universal pace that suits every account without exception. Follow the profile's legitimate purpose, its normal working pattern, platform messages, and current automation rules.

Sessions should also be separated. If employees accidentally open someone else's account or change networks during a shift, the log no longer explains the actual sequence of actions. A separate, stable working environment for every profile makes the incident easier to investigate but does not override X rules.

How does a rate limit differ from a lock, suspension, or shadow ban

A rate limit is a technical restriction on the number of actions within a time window. A login lock protects an account after suspicious authentication, a limited state disables specific functions, a suspension requires a separate appeal, and a shadow ban describes reduced content visibility. Each state requires its own response.

If X requests verification, do not disguise it as a technical failure. Cases involving actual loss of access require a separate locked or suspended account recovery process. Rate Limit Exceeded without additional messages usually does not require an appeal.

The worst diagnostic scenario is simple: a team clears the cache, changes the IP address, reinstalls the application, and enters the password several times. A protective login lock is then added to the original limit. One accurate error record would be more useful than all those actions.

When analyzing an incident, first determine what changed between the last successful request and the first failed one.

How does Afina help organize work with X accounts

When several employees manage client X accounts, sessions, cookies, proxies, and profile owners must not get mixed up. Afina can separate web sessions into browser profiles and assign a dedicated working environment to every account. This makes the error source easier to find and reduces the chance of accidentally opening the wrong profile. This material is provided solely for informational and educational purposes.

Afina does not affect X server-side limits and does not replace the official API. Its practical value is different: a team can maintain a clear mapping of "account, profile, proxy, owner" and link the incident log to a specific working environment. This helps identify which environment is associated with the incident more quickly.

Download