Is X.com (Twitter) Down Right Now, or Is It Just You?

Work through these in order. Each step either confirms an outage or narrows the problem to your side, and none needs more than a few seconds.

1. Look at an outage tracker. Downdetector (downdetector.com) and similar sites chart user reports. A real outage is a cliff, not a bump: on June 22, 2026, X went "from a small handful of issues to almost 30,000" Downdetector reports at about 9 a.m. Eastern, according to LongIsland.com's live report. A gentle rise of a few dozen reports is normal background noise.

2. Search X for fresh reports. If X loads at all, search is x down and switch to the Latest tab. During an outage new posts arrive several a minute; on a quiet day you will see one or two an hour, and most will not be about an outage (see the study below). If search itself will not load, that is a signal too.

3. Switch device and network. Turn Wi-Fi off and try mobile data, or open x.com in a private browser window on another device. If X works there, X is up and the problem is your app, browser, DNS, VPN or network.

4. Sign out, or look at someone else's profile. If X loads but your own timeline, posting or profile fails while other people's profiles load, the problem is account-level: a read limit, a lock, a suspension or an automation flag.

5. For developers: check the API status page. developer.x.com/status reports X API endpoint health. If your integration fails while that page is green, look at your credentials, rate limits and request code first.

X does not run a consumer status page for the app or website. The official sources are written for developers, and one widely linked address no longer works. We checked each URL this session:

What developer.x.com/status actually measures. The page's own front-end code fetches a status feed every 60 seconds and shows, for each X API v2 route (for example GET /2/tweets/search/recent, GET /2/users/me, POST /2/tweets) and Ads API route, a current success rate and a short history, grouped by data center. An endpoint at 99% or above shows green; lower rates show as degraded, and the overall banner moves to Degraded or Outage. That makes it the best official signal for developers. For consumers it is a partial signal: a broad outage can show up there (X's incident log titled the June 22, 2026 event "X site-wide outage: API endpoint degradation"), but an outage that only breaks the iOS app or the web timeline may never appear.

What docs.x.com/incidents adds. It is the after-the-fact record. The most recent entries when we checked included "X site-wide outage: API endpoint degradation" on June 22, 2026 from 12:00 to 15:41 UTC, a Recent Search outage on June 17, 2026 from 02:20 to 03:45 UTC, and an OAuth 2.0 login and /2/users/me outage from 23:00 UTC on June 30 to 01:00 UTC on July 1, 2026. Use it to confirm, after the fact, that the failure you saw was X's.

Third-party trackers. Downdetector, IsItDownRightNow and similar sites count user reports. They count reports as they arrive, so they move quickly, but they measure complaints, not failures: a viral post asking "is X down?" can produce a bump without an outage. Use them for step 1 above, never as the only signal.

Searching X for "twitter down" is the oldest outage check there is. We measured how useful it is. We ran the same search, ("twitter down" OR "x down" OR "is x down" OR "is twitter down" OR "x is down" OR "twitter is down" OR "x.com down") -filter:retweets, one query per UTC hour, over three windows: the 24 most recent hours at collection time, a quiet Monday (06:00 to 20:00 UTC, one week before the outage), and the same hours on Monday, June 22, 2026, the day X's own incident log records a site-wide outage.

The burst is sudden. The search returned nothing from 06:00 UTC until 13:52 UTC on the outage day, then 111 posts in the 15 minutes from 13:52 to 14:07, about 7.4 a minute. The busiest five minutes (14:00 to 14:05) held 53 posts. The peak hour, 86 posts, is about 52 times an average quiet hour. Then it faded: 11, 15, 4 and 9 posts in the four hours after 16:00 UTC.

The timing is not perfect. News reports put the start of the outage at about 9 a.m. Eastern (13:00 UTC), and X's incident log puts API degradation from 12:00 UTC. The posts our search returned start at 13:52. Either people were slow to post about it (they could not, if X was down), or the search index for that window is incomplete; we cannot tell which from this data. Either way, "is X down" chatter is a lagging signal: it confirms an outage, it does not announce it first.

Most quiet-day matches are noise. We read and labeled all 52 posts from the two quiet windows and a random 100 from the outage window:

On a quiet day, the most common match is a phrase that has nothing to do with an outage: people telling themselves to "put twitter down", reply-guys writing "@X down to connect", "Gen X down". The real quiet-day reports were scattered single questions ("is X down?") with no wave behind them, alongside a few local problems: a country-level block, one ISP, one person who could not post. During the outage, real reports dominate, and jokes become the second-largest group within minutes. Nine of the 100 outage posts explicitly asked the question this page is about: is it X, or just me, my network, or my account?

How to use this. Two or three "is X down" posts in the last hour mean nothing. Dozens in the last 15 minutes, several a minute, mean an outage. The script further down turns that rule into a number you can check.

Outage trackers and X search share a weakness: they count people saying something, not X failing. Our labeled sample shows how far apart those can be.

The phrase is ambiguous. "Twitter down" is also what people say when they mean "put Twitter down" (stop scrolling), "shut Twitter down" (hyperbole), or, since the rename, "@X down to connect" in networking replies. On a quiet day these made up 62% of matches. Any outage detector that counts the phrase without context inherits that noise.

Other services borrow the words. 8% of quiet-day matches were about a different service with "X" in the name, such as a fiber internet provider, or a list of several services going down at once.

Local failures look like outages to the person having them. Three quiet-day posts were from users who could not reach X because of their country or their ISP, and two said they had switched to a VPN to get back on. For them X was down; for everyone else it was up.

During an outage, people joke fast. 20% of the outage sample were jokes ("Twitter is down so I guess I'll go outside"), and 13% were news write-ups, link-bait or spam riding the trend. They still count as a signal, because jokes about X being down rarely appear in volume unless it is.

If X works on another device or for another account, the problem is yours alone. These are the account-level causes that most often get mistaken for an outage, and how each one shows itself.

Read limits are real and have caught millions at once. On July 1, 2023, Elon Musk announced temporary daily reading limits (first 6,000 posts for verified accounts, 600 for unverified and 300 for new unverified accounts, raised the same day to 10,000 / 1,000 / 500), and users who hit them saw "Rate limit exceeded", as ABC13 reported. Because so many people hit the cap the same afternoon, it looked like an outage. The lesson holds: if the error says "rate limit", it is about your session, not X's servers.

Locked and suspended are different states. A locked account is usually a security hold that you can clear yourself by verifying a phone or email (X's unlock form is at help.x.com/en/forms/account-restoration/locked). A suspension is an enforcement action; X explains the types and the appeal route at help.x.com/en/managing-your-account/suspended-x-accounts. Either one can make X feel down, because your timeline, posting and notifications stop while everyone else carries on.

One quick test settles it. Open x.com/Support in a private window without signing in, or ask a friend to load your profile. If X's own support account loads and yours shows a suspension notice or nothing at all, the problem is the account. If neither loads, go back to the outage check. To check whether your replies are being hidden rather than blocked outright, use our free shadowban checker (linked in the related guides below).

Developers face the same question with different symptoms: a job that ran yesterday now returns errors. X's API reference (docs.x.com/x-api/fundamentals/response-codes-and-errors) separates the cases cleanly by HTTP status, and the split is the same one this page uses for consumers:

X's own guidance is to check the HTTP status before parsing the body and to "use exponential backoff for 429 and 5xx errors". A burst of 5xx responses across several endpoints, matching a degraded row on developer.x.com/status, is an outage. A 401, 403 or 429 is not, however many times you retry it. Our Twitter API error-handling guide (linked below) covers retry code in depth.

A second path helps you tell the two apart. If your official X API integration fails, the fastest way to separate "X is broken" from "my app, keys or quota are broken" is to ask X the same question through a path that does not use your credentials or your quota. twitterapi.io reads public X data with an API key and no X account or developer-app approval. The snippet below counts "is X down" posts from the last 15 minutes; compare the result with the quiet-day baseline of 1.7 an hour from our study.

The full script at the bottom of this page combines the three checks into one verdict. It never touches your phone, browser or X session, so it isolates X itself from everything on your side.

Control accounts. It asks for the profiles of @Support and @XDevelopers with GET /twitter/user/info. When X is up, both come back with status: "success" and a data object (when we checked, @Support had about 6.3 million followers). If those fail, X is not serving even its own accounts.

Your account. It asks for your handle the same way and for its latest posts with GET /twitter/user/last_tweets (posts are in data.tweets, newest first). An unknown or unavailable handle comes back as HTTP 200 with status: "error" and msg: "user not found", not a 404, so the script reads the status field rather than the HTTP code. Controls fine but your handle not served means the account was renamed, deactivated, locked or suspended.

Chatter. It counts matching posts from the last 15 minutes with GET /twitter/tweet/advanced_search, following has_next_page and next_cursor for up to three pages. The threshold, 20 posts in 15 minutes, sits far above a quiet hour (1.7 posts) and far below the first 15 minutes of the June 22 outage (111 posts). It is calibrated on one outage, so treat it as a starting point and tune it.

The verdict. Controls failing or chatter above the threshold: likely platform-wide. Controls fine but your handle failing: account-level. Everything fine: X is up and the problem is on your device, network or session, so go to our guide to Twitter posts not loading.

One caveat matters: during a deep outage, every route to X data can fail at once, including this one. That is still an answer. If the control probes fail with gateway errors across several retries, X is down.

A diagnostic you run a few times a year should cost close to nothing. On twitterapi.io, profile lookups cost $0.18 per 1,000 profiles (18 credits each), and tweet reads cost $0.15 per 1,000 tweets, with a 15-credit minimum ($0.00015) per request. One run of the script makes three or four profile lookups, one timeline page and one to three search pages, so it costs a fraction of a cent: a quiet-day search that finds nothing is billed at the $0.00015 minimum, and a full 20-post page costs $0.003.

The X figures come from X's pay-per-usage rate card at docs.x.com/x-api/getting-started/pricing; per 1,000 posts the ratio is $5.00 / $0.15, about 33x. If you wanted to run the check continuously, the polling floor is the number to know: one empty search every 5 minutes for a month is about $1.30, every 60 seconds about $6.48. New accounts that pass the automatic bot check get up to $1 of free credits (at most 100,000 credits, no card, one per person or network, expiring after 31 days), which covers thousands of runs; see the pricing page for subscriptions.

Question. How do people report an X outage on X itself, how does an outage day compare with a quiet one, and how much of the "X is down" chatter is a real outage report?

Query. ("twitter down" OR "x down" OR "is x down" OR "is twitter down" OR "x is down" OR "twitter is down" OR "x.com down") -filter:retweets through /twitter/tweet/advanced_search with queryType=Latest, one query per UTC clock hour using since_time: and until_time:, up to two pages per hour, and to the end of the results for the two outage hours that filled two pages.

Windows and sample. The 24 most recent complete hours at collection time (40 posts); a quiet Monday one week before the outage, 06:00 to 20:00 UTC (12 posts); and June 22, 2026, 06:00 to 20:00 UTC (212 posts). All 52 quiet-window posts and a random 100 outage-window posts were read and labeled by hand into six mutually exclusive categories. Collected in 2026, 105 requests in total including query tests and the control-account probes, about $0.08.

What it cannot show. Counts are the posts the search returned, not every post on X; search completeness for older windows is not guaranteed, and the 15:00 UTC outage hour hit our page limit, so it is a lower bound. One outage is one example: outages that start at night in the US, or that break only one app, will look different. Labels are one reader's judgment on a small sample. The threshold in the script is a heuristic, not a detector.

Privacy. The search authors are mostly private individuals. Raw search results were not kept with the study; the published sample holds only de-identified rows (period, hour, language, reply flag, text length, label) with no post IDs, links, text or handles. Only X's own organization accounts are named.