The email lands in an admin's inbox with a subject line about a sandbox scheduled for deletion, and the forwarded question to your team is always the same: "Are we using this? Can we ignore it?" Salesforce really does delete inactive sandboxes, the deletion really is permanent, and the warning schedule gives you months to decide — but only if someone reads the email and knows what to check.
The good news: keeping a sandbox alive takes one login, and deciding whether you should keep it takes a five-minute review. This guide explains what the inactivity warning means, how the deletion timeline works, and how to make a confident keep-or-delete call.
Quick Answer
Salesforce deletes sandboxes after 180 days of inactivity, and deletion is permanent — there is no restore. Salesforce emails warnings at 90, 60, and 30 days before deletion. To keep a sandbox, log in to it at least once every 179 days. To check when a sandbox was last used, go to Setup > Sandboxes in your production org. If you no longer need the sandbox, letting it lapse is safe as long as nothing in it — configuration, test data, integrations — is referenced elsewhere.
- What it is: Salesforce's policy of deleting sandboxes that nobody logs into for 180 days.
- Who it matters for: Salesforce admins, release managers, and anyone who received the expiration warning email.
- Decision it supports: keep the sandbox (one login), refresh it, or let it be deleted.
Key Takeaways (TL;DR)
- The rule: sandboxes with no logins for 180 days are deleted. Logging in at least once every 179 days keeps one active.
- The warnings: Salesforce emails admins 90, 60, and 30 days before deletion — three chances to act.
- No undo: a sandbox deleted for inactivity cannot be restored by Salesforce. Back up or migrate anything you need first.
- Check activity centrally: Setup > Sandboxes in production shows each sandbox and when it was last accessed.
- License angle: deleting an unused sandbox frees its license; questions about sandbox subscriptions go to your Account Executive or Customer Success Manager.
Why Does Salesforce Delete Inactive Sandboxes?
Sandboxes consume real infrastructure. Every full or partial copy of a production org — its data, metadata, files, and configuration — sits on Salesforce's servers whether anyone uses it or not. Orgs accumulate sandboxes over time: one for a completed project, one from a test last year, one someone created to try a feature and forgot. The 180-day inactivity policy is Salesforce's way of reclaiming capacity from orgs that have effectively abandoned an environment.
The policy also nudges good hygiene. A sandbox nobody has logged into for six months is not a reliable test environment anyway — its data is stale, its configuration has drifted from production, and its integrations may be pointing at decommissioned endpoints. In practice, a long-inactive sandbox usually should be refreshed or deleted, not preserved.
How the Deletion Timeline Works
Salesforce's process, per its help documentation, is deliberately slow and noisy:
| Timing | What Happens |
|---|---|
| Day 0 | Last login to the sandbox. The inactivity clock starts. |
| 90 days before deletion | First warning email: the sandbox has been inactive ~90 days and is scheduled for deletion if it stays inactive. |
| 60 days before deletion | Second warning email. |
| 30 days before deletion | Final warning email. |
| Day 180 of inactivity | Salesforce deletes the sandbox. Its data cannot be restored. |
Any login resets the clock. Salesforce's guidance is explicit: log in to each sandbox at least once every 179 days to keep it active. It does not need to be a working session — an authenticated login is what registers activity.
How to Check Which Sandboxes Are at Risk
You don't have to wait for the email. In your production org, go to Setup > Sandboxes. The list shows every sandbox associated with the org and when each was last accessed. Sort mentally by last-used date and anything approaching six months of silence deserves a decision this week, not after the final warning.
Make this a recurring review. A quarterly calendar reminder to scan Setup > Sandboxes takes ten minutes and guarantees a warning email is never the first time leadership hears about an expiring environment.
Keep, Refresh, or Delete: A Decision Framework
When the warning arrives, the honest question is not "how do we save it?" but "should we save it?"
Keep it (log in now, then calendar the next login) when the sandbox hosts active work: an in-flight project, a training environment in regular use, or an integration staging org that external systems authenticate against. For integration staging, remember that a deleted sandbox breaks connected systems — middleware, CI pipelines, and vendor test endpoints — which then fail in ways that look unrelated to a sandbox cleanup.
Refresh it when the environment is needed but stale. Refreshing replaces the sandbox with a current copy of production, which resets both the data and the inactivity clock. Check your refresh allowances and lead times first — full-copy refreshes in particular are limited and take time to queue.
Let it go when nobody can name what it's for. Before deletion, do a fifteen-minute export pass: any reports, validation rules, flow definitions, or test-data sets that someone might ask about later. Configuration can be recreated; the habit of exporting first is what prevents the one painful loss. And if the sandbox type is one you're no longer licensed to recreate, confirm with your Account Executive or Customer Success Manager before letting it lapse.
What to Do If a Sandbox Was Already Deleted
Salesforce's answer is unambiguous: once a sandbox is deleted for inactivity, it cannot be restored. The recovery path is to create a new sandbox (license permitting) and rebuild. This is where the fifteen-minute export habit pays off — teams that exported configuration and reference data rebuild in hours; teams that didn't rebuild from memory.
If the deletion just happened and the sandbox was business-critical, contact your Account Executive or Customer Success Manager anyway. They can't undelete it, but they can confirm license availability for a replacement and help with subscription questions.
What Businesses Should Do Next
Three actions this week: first, open Setup > Sandboxes and note the last-accessed date for every environment. Second, log in to anything you intend to keep — that single act defers the issue by six months. Third, assign sandbox hygiene to a named owner with a quarterly reminder, because warning emails go to whoever Salesforce has on file, which is often someone who changed roles two reorgs ago.
Longer term, fold sandbox lifecycle into your release-management practice. Sandboxes should be created with a purpose and an owner, reviewed quarterly, and refreshed or retired deliberately — not discovered via deletion warnings.
How Vantage Point Helps
Vantage Point's Salesforce consultants build the environment strategy around your org: which sandbox types you need, refresh cadences, data-loading standards, and the governance that keeps environments purposeful. Our Salesforce implementation and advisory team designs sandbox strategy for new implementations, and our managed services team runs environment reviews as routine maintenance so a deletion warning never catches you off guard.
Got the Expiration Warning?
Vantage Point has managed Salesforce environments across more than 400 engagements. Talk to us about your sandbox strategy — a short review usually settles what to keep, refresh, or retire.
FAQ
How long before Salesforce deletes an inactive sandbox?
Salesforce deletes a sandbox after 180 days without a login. Logging in at least once every 179 days keeps the sandbox active and resets the clock.
What warning emails does Salesforce send before deleting a sandbox?
Salesforce emails warnings 90, 60, and 30 days before the scheduled deletion, giving admins three opportunities to log in and keep the environment.
Can Salesforce restore a sandbox deleted for inactivity?
No. Salesforce's documentation states that once a sandbox is deleted due to inactivity, its data cannot be restored. Back up or migrate anything important before the deletion date.
How do I check when a sandbox was last used?
In your production org, go to Setup > Sandboxes. The list shows each sandbox and when it was last accessed, so you can spot at-risk environments before the warning emails arrive.
Does any activity count, or does it have to be a login?
Salesforce's guidance specifies logging in to the sandbox at least once every 179 days. An authenticated login is the reliable way to register activity — don't assume background jobs or API traffic count.
What happens to integrations connected to a deleted sandbox?
They break. Middleware, CI pipelines, and vendor test endpoints authenticated against the sandbox will fail once it's gone. Inventory connected systems before letting any sandbox lapse.
