Slack export: what a workspace export actually contains
Slack export explained: you get JSON messages and links to files, not the files, and no supported restore. See what each plan reaches and where the gaps are.
A Slack export hands you a ZIP of JSON: a folder per conversation, the messages split into daily files, plus workspace metadata describing your channels and members. What it does not hand you is your files. Slack's own guidance is explicit that "data exports will include links to files, but not the files themselves". It also gives you no supported way to put any of it back into the workspace it came from. And which conversations you can export at all is decided by your plan — on Business+ and Enterprise, by an application Slack has to approve.
This post covers what a standard export contains, what each plan can reach, and the four gaps that stop an export from doing the job of a backup.
What a standard Slack export actually contains
Every plan has the same baseline: a workspace owner or admin can export messages and file links from public channels, in JSON. That baseline is genuinely useful for what it was designed for — moving a workspace, answering a legal request, feeding messages into an archive tool. It is a data extract, not a recovery mechanism.
Three properties of that extract matter:
- Files are references, not content. The export carries URLs pointing back at Slack-hosted files. Whatever authenticates those URLs — the workspace, the account, the plan — has to still exist and still grant access when you need the file. A ZIP of links is only as durable as the thing the links point at.
- The format is machine-readable, not human-readable. JSON per channel per day is fine for an import tool or an e-discovery platform. Nobody reads a thread out of it under time pressure, which is exactly when you need to.
- It is a snapshot of what remains. An export captures the workspace as it currently stands. It does not resurrect what has already gone.
Your plan decides what you can export
This is the part teams usually discover mid-incident.
Free and Pro get public channels only. Private channels and DMs are out of reach without valid legal process or the consent of the members involved. On the free version there is a second limit stacked on top: you can view and search the most recent 90 days of message and file history, and data more than one year old is deleted. Between 90 days and a year, messages are hidden rather than gone — upgrading reveals them — but past the one-year mark there is nothing left to reveal.
Business+ keeps the standard public-channel export for admins, and adds a self-serve tool that can export all channels and conversations, including private channels and direct messages. Access is not automatic: an owner has to apply for it, with approval from the Workspace Primary Owner, and Slack expects the appropriate employment agreements and corporate policies to be in place first. Approved workspaces can also schedule recurring exports. Files are still links, not files.
Enterprise adds export by conversation type, by member, or for a single workspace, and access to the self-serve tooling starts with a request to Slack Support. The Discovery API is the one route that can include files as direct downloads rather than references.
The practical read: if your workspace runs on Free or Pro and your incident touches a private channel or a DM, the native export has nothing for you. If you are on Business+ and have not already applied for the broader export, the application is not something you complete during an outage.
The four gaps that stop an export being a backup
1. There is no restore. Slack's import tooling exists to move data between workspaces, not to roll one back to Tuesday. There is no "restore workspace to a point in time" button, and Slack states plainly that imports to Enterprise organizations are not supported. Even a perfect export leaves you re-creating channels and membership by hand and reading history out of JSON.
2. Deleting a channel bypasses retention entirely. This is the sharpest edge in the whole system. Slack documents that retention does not apply to messages in deleted channels: delete a channel and its messages and revisions are permanently deleted, regardless of your workspace retention settings. An admin — or an attacker holding admin credentials — removes a channel, and a retention policy you configured for exactly this reason does not apply. Deletion is a normal authenticated action, and it does not queue for review.
3. Retention deletes, and it deletes for good. On paid plans, data is kept for the lifetime of the workspace by default, but administrators can shorten that. Slack's warning is unambiguous: "Data deleted according to your retention setting is permanent. Adjust these settings with care." Deletions run once a day, so a mistaken policy change acts on its own schedule rather than immediately — which sounds like a grace period and is not one.
4. Exports are episodic; loss is continuous. Unless you are approved for scheduled exports, an export is a thing someone remembers to run. The window that matters is between the last export and the incident, and that window is exactly as long as the gap in your habits. We covered the underlying windows in more depth in what Slack actually keeps and for how long.
When an export is the right tool
To be fair to it, the export does its own job well. Reach for it when you are migrating to another workspace or tool, responding to a legal or regulatory request for specific conversations, offboarding someone and needing a defensible record, or feeding an archive or e-discovery platform.
Reach for something else when the question is "a channel was deleted this morning, how do we get it back?" That is a recovery question, and the export was never built to answer it.
What an independent Slack backup adds
The split here is the ordinary SaaS shared responsibility model: Slack keeps Slack running and survives its own infrastructure failures. Whether your conversations are recoverable after someone inside your workspace deletes them is your side of the line.
An independent copy for Slack should cover what the native export structurally cannot:
- Scheduled capture of public and private channels, DMs, threads and workspace structure, without an application process gating which conversations are in scope
- The files themselves, stored as content rather than as links back into Slack
- Point-in-time restore — back into Slack, not into a folder of JSON
- Coverage of deleted channels, including the archived and shared ones people forget are still carrying business decisions
- Anomaly detection, so a bulk deletion is flagged as it happens rather than discovered when someone goes looking for a thread
We help you choose the right fit for your stack, deploy it, and get you protected — you own and run the platform, we make sure the setup covers the workspace you actually have. The Slack backup and recovery page sets out what gets protected, workload by workload.
Where to start
If the answer to "what happens if someone deletes the wrong channel on a Friday afternoon?" is a pause, an assessment is the fastest way to size the gap: a short, practical look at what your current Slack setup can and cannot recover, and what an independent copy would close.
Related reading
Slack message & file retention: what's actually kept
Slack retention varies by plan and admin config — from a 90-day cap on Free to indefinite-until-configured on paid tiers. Here's what's actually kept, and what isn't.
The SaaS shared responsibility model — why Microsoft, Google and Atlassian don't back up your data
The short answer: your SaaS vendor keeps the platform running. Keeping your data is your job. Here's what that actually means for M365, Google Workspace, Slack and Atlassian.
How to back up Google Workspace: every route, and what each misses
There are four ways to back up Google Workspace and only one is a backup. The documented windows, exclusions and restore limits of each, side by side.