Restricted, Locked or Suspended: What Each X Account State Means for Deleting Old Tweets

--
title: "Restricted, Locked or Suspended: What Each X Account State Means for Deleting Old Tweets"
description: "A restriction notice halfway through a cleanup raises one practical question: can deletion continue. Restricted, locked and suspended are three different states with three different first moves. What each one allows, how to test write access with a throwaway post, and how to keep your progress when a batch job stops in the middle."
tags: ["privacy", "twitter", "howto", "productivity"]

canonical_url: https://digital-footprint-health.shop/blog/delete-tweets-restricted-account

Halfway through a deletion queue, a restriction banner appears at the top of the page. The notice itself is not the problem. Two concrete questions are: can the deletion keep running right now, and how much of the earlier work still counts.

Both answers depend on which state the account is actually in. People say banned and mean three different things, and the three behave differently enough that using the wrong first move costs real time.

The three states side by side

State	What it looks like	Can you delete tweets
Restricted	Some features degraded: posting, following, reposting	Usually yes. Work on existing content often sits outside the restriction
Locked	Login stops at a phone or email verification step	Usually no, until verification is finished
Suspended	Account unreachable, profile not publicly visible	No. Recovery comes first

Read it as a lookup: find your row, then read the third column.

Restricted accounts usually still allow deletion

A restriction is mostly a feature-level downgrade. You can log in and read your own timeline while posting, following and direct messages get tightened. Deleting an old post is technically a write action, but it acts on content that already exists, and that path does not fully overlap with the path for adding new content.

One case breaks the pattern. When the restriction came from a suspected-activity flag, platforms tend to tighten the whole category of write actions at once, which can block posting and deletion together. So do not trust the wording of the notice. Test it.

Test with a post you do not care about

Pick an old post you already wanted gone, one where a mistake costs nothing, and delete it by hand. Success means the route is open. Failure returns a specific error, which is more informative than re-reading the notice. Using an important post as the test subject is a common and avoidable waste.

Locked accounts: verify first, clean later

A lock is a verification gate, not a penalty. X asks you to confirm a phone number or email address and normal access generally returns once that is done. Deletion attempts while verification is pending tend to fail.

One detail gets missed. Retrying various actions during the verification window can push the account's risk score tighter, which lengthens the lock. The steadier move is to stop, finish the verification, then return to the queue.

Suspended accounts: recovery before removal

Content on a suspended account is already invisible. Anyone opening the profile gets an error page and search engines drop the pages over time, which shrinks the exposure a lot on its own.

If complete removal is the goal, recovery has to happen before anything else. Recovery runs on a window, and past it the account can be removed permanently, taking its content with it. Those two paths end in different places, so decide which outcome you want before starting.

Where third-party tools fit

Deletion tools depend on API permissions, and permissions move with account state. A restriction can narrow the write scope the tool receives. Sometimes the calls get rejected, sometimes the authorization is revoked outright.

After a revocation the fix is re-authorizing, not restarting the tool. If you keep retrying while the account state is unclear, the failure looks like a broken tool when the cause is somewhere else. Pause bulk jobs and keep only reading and assessment running.

Six steps while the account is abnormal

Laid out in order, this avoids most of the trial and error.

• Identify the state. Restricted, locked or suspended. If unsure, check which features are missing after login.
• Check write access. Whether you can publish a throwaway post is more direct than reading the notice.
• Delete one unimportant post by hand. Not an important one.
• Record the range already cleared. Dates, keywords, counts, written down locally.
• Pause batch jobs. No point hammering the API while the state is unknown.
• Resume from the record once recovered. Restarting from zero duplicates work and invites misses.

Progress rarely disappears, the record does

Posts already deleted do not come back when account state changes. That part is settled. What gets lost is the unfinished queue and the evidence of what was already handled. After an interrupted batch job, without a local record it becomes genuinely hard to tell which posts were processed.

Three columns carry a usable log: an identifier (post time, or the opening words), a status (pending, deleted, kept), and a timestamp. Resuming from that table beats working from memory, and exporting a copy weekly keeps the log itself from going missing.

Three edge cases worth separating

Posts created during the restriction window: handle those after the older material, since historical exposure comes first.

Two devices at once: one machine running a batch job while another deletes by hand means two conflicting views of progress. Avoid that parallelism even more while the state is unclear.

Giving up because it looked permanent: restrictions are common and often lift within days. Abandoning the cleanup usually costs more than waiting.

When waiting beats working around it

Most restrictions lift within days, and resuming the original plan afterwards is the cheapest route. Forcing progress through a degraded state rarely saves time.

One situation does call for immediate action: exposure that is actively spreading. If a post is being reposted, quoted or screenshotted right now, waiting is not neutral. Where the footprint is stable and no new engagement is arriving, a few days of delay does not raise the risk. Telling those two apart is the whole decision.