Mastodon ‘Status Already Deleted’ on Edit Attempt: Causes

You attempt to edit a post on Mastodon and see the error message Status Already Deleted. This happens even when the post is still visible on your profile and in your home timeline. The error is not caused by you deleting the post manually. It is triggered by a specific mismatch between how Mastodon handles post edits and how it caches post data across servers. This article explains the root cause of the Status Already Deleted error, why it appears only on certain posts, and how to verify whether a post is truly editable.

Why Mastodon Shows Status Already Deleted on Edit Attempt

Mastodon uses an event-driven architecture for post edits. When you edit a post, the server broadcasts an Update activity to all federated instances. Each instance that received the original post must process the edit and update its local copy. If any instance fails to apply the edit — for example, due to a network timeout or a database conflict — Mastodon marks that instance’s copy of the post as deleted in the local database. This is a safety mechanism. Mastodon does not allow editing a post that has been marked as deleted, because the edit operation would attempt to modify a record that the server considers removed.

The error is most common when you edit a post shortly after publishing it. The original post is still being federated to remote servers. If you send an edit before the original post has been fully propagated, some remote instances may receive the edit before they receive the original. Those instances create a placeholder record for the post and then immediately mark it as deleted when the edit cannot be matched to an existing local copy. Later, when you try to edit that same post from your home instance, the server checks its local database and finds the deleted_at field populated. It returns the Status Already Deleted error.

Server-Side Race Condition During Edit Propagation

Mastodon processes incoming activities in a queue. When an Update activity arrives for a post that has not yet been fully stored, the server creates a stub record and then attempts to fetch the full post content. If the fetch fails or times out, the stub remains with a deleted_at timestamp. This race condition is more likely on small or overloaded instances where the queue processing is delayed. The error is not a bug in the traditional sense. It is a deliberate design choice to prevent data inconsistency across the fediverse.

How to Verify Whether a Post Is Actually Deleted

You can confirm the status of a post without relying on the error message. Open a browser and visit the following URL, replacing your-instance.com with your Mastodon instance domain and POST_ID with the numeric ID of the post:

https://your-instance.com/api/v1/statuses/POST_ID

The API returns a JSON object. Look for the deleted_at field. If it shows null, the post is editable. If it contains a timestamp such as 2025-03-15T10:30:00.000Z, the post is marked as deleted and cannot be edited. You can also check the visibility field. A post that is still visible on your profile will show public, unlisted, followers-only, or direct. The deleted_at field is the definitive indicator.

1. Get the post ID
   Open the post in your browser. The URL contains the post ID after the last slash. For example, in https://mastodon.social/@username/109876543210987654, the ID is 109876543210987654.
2. Call the API endpoint
   Paste the API URL into a browser address bar. Make sure you are logged into your instance in the same browser session.
3. Inspect the JSON response
   Search for "deleted_at". If the value is null, the post is editable. If it contains a date string, the post is locked.

Related Failure Patterns and Their Causes

Edit Button Grayed Out on a Visible Post

The edit button may appear grayed out in the Mastodon web interface even though the post is visible. This happens when the client-side JavaScript checks the deleted_at field before enabling the edit button. The same race condition that triggers the error in the API also disables the button. Refreshing the page or clearing the browser cache does not change the status. The post is locked on the server side.

Post Disappears After Edit Attempt

In rare cases, attempting to edit a post that is marked as deleted causes the post to disappear from your profile entirely. This occurs when the edit request triggers a cleanup routine that removes the orphaned record. The post is not recoverable through the web interface. You must use the Mastodon API with a GET request to /api/v1/statuses/:id to verify whether the post still exists. If the API returns a 404 error, the post has been purged.

Error Appears Only on Remote Instances

The Status Already Deleted error may appear when you try to edit a post from a remote instance’s web interface. This is expected behavior. Mastodon only allows editing a post from the instance where it was originally created. Remote instances store a read-only copy. If you attempt to edit from a remote instance, the server returns the error because the local copy is not the authoritative source. Always edit posts from your home instance.

Item	Editable Post	Deleted Post
API deleted_at field	null	Timestamp string
Web interface edit button	Enabled (blue)	Grayed out or missing
Post visibility on profile	Visible	Visible or invisible
Edit from remote instance	Not allowed	Not allowed
Recovery method	Normal edit	Delete and repost

You can now identify the exact cause of the Status Already Deleted error by checking the deleted_at field via the Mastodon API. If the post is locked, the only practical fix is to delete the post and create a new one with the corrected content. To avoid this error in the future, wait at least 30 seconds after publishing before editing a post. This delay gives the federation queue time to propagate the original post to all remote instances. For posts that receive a lot of engagement, consider using Mastodon’s scheduled post feature to compose and review the content before it goes live.