Recover deleted Slack messages: what is actually possible

Short answer: you cannot recover deleted Slack messages from inside Slack. There is no trash, no recycle bin and no undo — Slack's own help documentation puts it plainly: "Deleting a message is permanent, so please proceed with care." Whether the content still exists anywhere was decided before the deletion happened, by a workspace retention setting that most teams have never opened. If that setting was configured to keep edits and deletions, the data is preserved and can be extracted through compliance tooling on the top plan tier. If it was not, there is nothing to retrieve, and no support ticket changes that.

That makes this a configuration question rather than a recovery question, which is good news: it is fixable in ten minutes, but only in advance.

Slack's answer: deletion is permanent, and lots of people can do it

Two things are worth reading together.

First, deletion has no undo in the interface. Second, by default every member can delete their own messages, and owners and admins can delete other members' messages in public channels, private channels and group DMs they are part of. Slack does let owners restrict the member-level permission — which is the single most useful setting in this whole article, and one most workspaces leave at the default.

So the common scenario is not a malicious actor. It is somebody deleting a thread because they posted the wrong figure, and taking the correct figure with it, in the channel where a decision was recorded three months ago.

What decides whether a deleted Slack message still exists

Slack's message retention setting is the whole ballgame, and the option names are unusually literal about what they do.

Free plan:

• "Keep messages, but don't track edits or deletions"
• "Delete messages after 90 days"

Pro and Business+:

• "Never delete messages — save edits"
• "Never delete messages — don't save edits"
• "Choose custom timeline"

Note the distinction that matters. On the Free plan, the default option explicitly does not track deletions — the deleted content is gone as data, not merely hidden. On paid plans, "save edits" is what preserves the revision and deletion history; "don't save edits" discards it. Both options otherwise sound identical, and they produce completely different outcomes on the day somebody asks what the message said.

Files run on their own separate settings, which is a trap of its own. Free plans choose between "Keep files for one year, but don't keep deleted content" and "Keep files for 90 days, including deleted content". Paid plans add explicit "including deleted files" variants, and Enterprise adds options to align file retention with the org-level message policy. A workspace can therefore be keeping deleted files while discarding deleted messages, or the reverse, purely by accident. We mapped the full retention picture in what Slack actually keeps.

Where you can recover deleted Slack messages from, if retention kept them

Assume the retention setting was right and the data was preserved. How do you actually see it?

The interface Slack documents for this is the Discovery API, which is available on Enterprise plans only. Slack describes it as able to collect data from the beginning of an organisation's history "as well as content that has been edited and deleted (if preserved by retention policies or legal holds)" — note the conditional. The API surfaces what retention already kept; it does not resurrect what retention discarded.

Standard exports are a weaker instrument than people expect. On Free and Pro plans an export covers public channels only, and carries file links rather than the files themselves. Business+ and Enterprise owners can apply for a self-serve data export tool that reaches private channels and DMs. Slack also documents that exports exclude data more than a year old that has been deleted. We went through what an export does and does not contain in what a Slack workspace export actually holds.

The honest summary: on Pro and Business+, choosing "save edits" preserves the history, but Slack does not document a self-serve admin screen where you read a deleted message back. The documented retrieval path for edited and deleted content is Enterprise-tier compliance tooling. If you are on Pro and assuming an admin can look up a deleted message later, verify that assumption before you rely on it.

Four cases where nothing native helps

• The channel was deleted, not the message. Deleting a channel takes its contents out of reach and bypasses workspace retention entirely. Archiving is the reversible action; deleting is not.
• The Free-plan window has passed. On a 90-day setting, the messages roll off on schedule whether anyone deleted them or not, and older data is removed on a rolling basis. No retention decision made today reaches back.
• The person has left. A departed member's DMs and the files they shared follow the workspace's settings, not their intentions, and an offboarding that removes the account does not pause any of those clocks.
• The file was deleted separately. Because files are governed by their own setting, a message can survive with a dead link where the attachment used to be — the export behaviour makes this especially visible.

None of these are bugs. They are a collaboration platform behaving like a collaboration platform: it optimises for a clean, current workspace, not for an evidentiary record.

What to change this week

Four settings and one decision, in this order:

1. Open the retention settings and write down what they currently say — message and file, separately. Most teams discover here that they are on a default nobody chose.
2. Decide whether members should be able to delete their own messages at all. For a workspace where decisions, approvals or client commitments are recorded, restricting it is usually the right answer.
3. Set message retention to preserve edits and deletions if your plan offers it, and align file retention deliberately rather than by omission.
4. Ask what evidence you would need. If the honest answer involves a compliance conversation — showing who approved what, and when — then a chat platform's retention setting is a thin place to keep it. That is the same gap NIS2 asks about for SaaS data: not "do you keep things", but "can you produce them".

Then the structural point. Every option above lives inside the workspace, under the same admin identity, subject to the same "clean up the workspace" pressure that caused the deletion in the first place. An independent copy — held outside Slack, on retention you control — is the only version of this that survives both an accidental deletion and a compromised administrator. That argument generalises across platforms, and we make it in full in does cloud backup protect against ransomware.

The realistic expectation

If a message was deleted today and your retention setting did not preserve deletions, it is gone, and the useful work is making sure the next one is not. If your setting did preserve it, the retrieval is a compliance-tooling exercise gated on your plan tier — worth confirming you can actually perform before you need to.

We help you choose the right fit for your stack, deploy it and get you protected across Slack, Microsoft 365, Google Workspace and Atlassian Cloud — you own and run the platform, we make sure it covers the conversations and files you would actually be asked to produce.

If you want to know exactly what your workspace could and could not recover today, an assessment is a short, practical review of your current settings, windows and gaps.