Tweet Failed to Send on Twitter (X)? What Each Error Means and How to Fix It

X uses several different wordings for a post that did not go through. Each wording below appears verbatim in public posts in our sample, or on X's help pages; match yours, then jump to the cause.

The wording changed with the rename. In our sample of the "weren't able to send your" dialog, posts from 2023 quote the "Tweet" version 57 times and the "post" version 2 times; in 2026 it is 16 "post" and 0 "Tweet". If your app still says "Tweet not sent", the app itself is old, which is one of the causes in its own right.

The limit message is specific. X's limits page says that when you reach a limit, "we'll let you know with an error message telling you which limit you've hit". So a generic "Failed to send post" with no mention of a limit is weak evidence that you hit the cap.

The single most useful fact about "failed to send post" is that it comes in waves. Across 214 days, the phrase appeared in a median of 1 public post a day, and 36.0% of days had none. Then, on 32 spike days (more than three times the median day), it exploded, and those days hold 65.8% of all the complaints.

The busiest day in the sample had 46 posts. Two waves dominate: mid to late May 2026 (112 posts that month) and August 9 to 11, 2026 (163 posts that month, with the single busiest week at 88). In the August wave many people describe replies failing while new posts still go through; in May they describe both, and some blame a new app version.

How to check in a minute. Open X search, type "failed to send post" and switch to the Latest tab. Several posts in the last hour from unrelated accounts means the problem is X-side. On spike days 13.4% of complaints use words like bug, glitch, down or "anyone else", against 7.6% on ordinary days, so you will usually see other people asking the same question.

What to do. Save the post to drafts (the "Post not sent" dialog offers this), stop retrying, and come back in a few hours. Reinstalling the app, clearing data or changing your password does not fix an X-side failure, and repeated identical retries can trip the duplicate check once X recovers. X runs no consumer status page; our is X down guide covers the developer status pages and what they can and cannot show.

Cause 2: duplicate text ("Whoops, you already said that"). X's posting help page is explicit: the "Whoops, you already said that" error appears when you post exactly the same text as a recent post, and it should only appear for an exact match. The fix is to change the wording.

Where this catches people. A failed post that actually went through. People in our sample describe getting "Failed to send post", pressing Retry, and then being told they already said that, because the first attempt had posted after all. Before retrying, refresh your profile and check whether the post is already there.

How common it is. Only 1.9% of complaints in our sample mention duplicate text. It is a quick check, not the usual cause.

For schedulers and scripts. Templates that post the same sentence every day ("Good morning!") hit this constantly. Add something that changes, such as the date, a counter or the headline you are sharing.

Cause 3: too long, or the media is too big. X's help center sets the size limits. A standard post holds up to 280 characters; longer posts are a feature of X Premium and The X Subscription plans. A post can carry photos, a GIF or a video, up to 4 media items in total.

What to do. If the post carries a long or large video, trim it, export it again as an MP4, or post the text first and the media in a reply. If you are near 280 characters, our tweet character count guide shows how X counts them.

How common it is. 4.4% of complaints in our sample mention a video, image or GIF. Media failures are real but a minority.

X's limits page (help.x.com, rules and policies, X limits) now lists the post cap as 50 original posts and 200 replies per day for unverified accounts, and says the daily limit is further broken down into smaller limits for semi-hourly intervals. The same page still carries an older line about a limit of 2,400 updates per day, so the page itself is inconsistent; the 50 and 200 figures are the newer wording, reported by the press in May 2026.

What counts. The page says the limits include actions from all devices, including web, mobile, phone and API, so posts made by a scheduler or a connected app count against the same cap as posts you type. It also says the limits may be temporarily reduced during heavy site usage.

What to do. If the error names a limit, wait. The page says that for time-based limits you can try again once the period has passed, and suggests trying again in a few hours. Spreading posts through the day avoids the half-hour sub-limits that bite during live-tweeting.

How common it is. Only 2.2% of complaints mention a limit at all, and the share is lower on spike days (1.5%) than on ordinary days (4.1%). The big waves of "failed to send post" were not people hitting the cap. For read limits ("rate limit exceeded" while scrolling), see our rate limit guide.

Cause 5: a link X will not let you post. X's posting help page says it has "automations in place that could impact your ability to post certain links", and points to its page on phishing, spam and malware links. X does not publish the list of links it blocks.

Test it. Post the same text without the link. If that works, the link is the problem; try the full destination URL instead of a shortener, or share it in a reply.

How common it is. 0.7% of complaints in our sample mention a link, the rarest cause we measured.

Cause 6: a locked or limited account. X's locked-account page says an account can be locked or limited if it may be compromised or in violation of the X Rules, and that the first step is to verify you are the owner. You may see "Please verify your account" or "Your account has been locked", and the check is by phone, email or captcha. If X thinks the account showed automated behavior, it may ask you to pass a captcha.

What it looks like. Posting fails on every surface (app and web), while browsing still works, and a banner or email explains the lock. If you never see a notice and the failure is on replies only, it is much more likely cause 1.

How common it is. 2.2% of complaints mention a lock, ban, restriction or label. Some of those are guesses ("am I shadowbanned?") rather than confirmed locks. Our shadowban checker shows whether your posts appear in search; error 226 is the automation-specific version of this cause.

X's posting help page puts this last and simply: trouble sending posts "can often be attributed to a need to upgrade your browser or app". Use the latest browser on the web and install any available app updates.

The checklist, in order. Update the app. Force-close and reopen it. Try the same post on x.com in a browser (or the other way round): if one surface works, the problem is local. Log out and back in to refresh the session. On Android, clearing the app's cache is the last step before reinstalling; copy the text of any draft you care about first.

What the sample shows. Only 4.0% of complaints name a surface at all: Android 2.2%, web or browser 2.2%, iPhone or iOS 0.5%. Android is mentioned more often on spike days (4.6%) than on other days (2.3%), consistent with reports that some waves came from a single app build. 3.4% mention updating, reinstalling, clearing the cache or logging out.

Across all four error wordings, the most frequent detail is that the failure hit a reply or a comment (33.2%). People also attach a screenshot of the error (17.8%), mention drafts or retrying (17.7%), and call it a bug or ask whether anyone else has it (10.0%). Every specific cause the help pages list, from limits to locks to links, sits at about 2% or less.

The dialog wording is quoted far less often than the short toast, because people paraphrase the long message. Its search reaches back years, so the per-day figure is tiny, which is also why it is the best record of the Tweet-to-post wording change.

If you post through an API, the same refusals arrive as a response body instead of a toast, and reading that body is the whole job: it tells you whether to retry, change the post, or stop.

On X's official API. POST /2/tweets is billed at $0.015 per post created, or $0.20 when the post contains a URL (pay-per-usage card at docs.x.com/x-api/getting-started/pricing). X's response-codes page lists 403 Forbidden as "Valid auth but no permission for this resource or action" and 429 Too Many Requests as "Rate limit or usage cap exceeded"; it lists no duplicate-specific code, so log the body verbatim and decide from X's message.

On twitterapi.io. Posting runs through an authenticated session: one /twitter/user_login_v2 login ($0.10, with a residential proxy you supply) returns login_cookies, then /twitter/create_tweet_v2 takes login_cookies, tweet_text and proxy (plus optional reply_to_tweet_id, media_ids and others) at 60 credits ($0.0006) per call. When X refuses the post, the call still returns HTTP 200 with status: "error", and message carries the reason X gave, plus x_status (X's HTTP status) and code (X's error code) when available.

The caveats that matter. The call acts as that X account, so X can rate-limit, lock or suspend it exactly as it would if you posted by hand, and the daily cap above applies. Keep a human pace. The session can need a re-login; the docs ask you to enable 2FA before logging in, because without it the returned cookies may be faulty and posting can fail. Billing is per HTTP 200 call, including calls where X refused the post, so a retry loop on status: error costs money and looks like spam. Reads such as advanced search need only an API key, no X account.

For social teams: detect an X-wide failure before your users do. A brand account or a scheduling product sees "failed to send" as a support ticket. The question support needs answered is the one in cause 1: is X failing for everyone right now? You can answer it the same way we built this study, by counting fresh public complaints.

The check. Every few minutes, run /twitter/tweet/advanced_search with "failed to send post" -filter:retweets since_time:<one hour ago> and queryType=Latest, and alert when the count jumps. The full script is at the end of this page.

What it costs. Tweet endpoints bill 15 credits per tweet returned, $0.15 per 1,000 tweets, with a 15-credit minimum per request, so a check that finds nothing costs $0.00015. Checking every 5 minutes for a month is about $1.30 in empty checks, plus $0.00015 per complaint actually returned. On ordinary days the median is 1 complaint a day, so most checks are empty. Reading the same posts on X's own API costs $0.005 per post read on the pay-per-usage card, about 33x the $0.15 per 1,000 on twitterapi.io.

What our whole study cost. 70 search requests returned 1,379 posts, about $0.2069 at 15 credits per tweet.

Question. When people say a post failed to send on X, what do they describe, and do the complaints cluster into X-wide waves?

Queries. Four X advanced searches, Latest tab: "failed to send post"; "failed to send" with tweet, post, reply, X or Twitter (excluding the first phrase); "weren't able to send your"; and "post not sent" or "post was not sent" or "post wasn't sent". Reposts were excluded, and off-topic matches (for example money transfers that "failed to send") were dropped with a keyword rule.

Window and size. The most recent matching posts at collection time, collected in 2026: 70 requests, 1,334 unique posts after de-duplication. The main phrase covers 214 days; the dialog wording reaches back to 2015.

Method. Case-insensitive keyword rules written before collection flag each post (reply, media, limit, lock, link, duplicate, surface, bug). A spike day has more than three times the median daily count of the main phrase. 93.0% of posts are in English.

What the sample cannot show. It counts people who complained in public, not everyone who saw the error. Keyword rules miss paraphrases and misread jokes. Search results are what X returns for these phrases, not a complete archive, and nothing here proves the cause of any single failure.

Privacy. Aggregates only. The posts are by private individuals: no handles, IDs or text are published, raw pages were not kept with the study, and the de-identified sample holds only day, language and the keyword flags.