> ## Documentation Index
> Fetch the complete documentation index at: https://docs.abtestly.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Recycle bin

> Soft delete leaves the file serving. Permanent delete is the one that actually frees storage. Two-step, on purpose.

Deleting an asset is a two-step process.

## Step 1: soft delete

**Delete** on an asset row moves it to the recycle bin.

* The asset **still serves at its URL.** Nothing hosted or embedded
  breaks.
* It shows up in the **Recycle bin** view (toggle at the top of the
  Assets tab).
* It **still counts against your storage budget.**

The two-step exists because "an asset is not attached to a variant"
is not the same as "the asset is not in use". Emails you sent last
month, third-party embeds, cached copies in a stakeholder's browser
all of those might still hit the URL. Soft-deleting without
breaking the URL gives you a moment to notice.

## Step 2: permanent delete

**Permanent delete** in the recycle bin actually removes the file.

* The R2 object is deleted.
* The Cloudflare cache is purged (within minutes).
* **The URL will 404 from now on.** Anything referencing it stops
  working.
* **Storage is freed**, your budget usage drops.

This step is confirmation-gated. There is no undo.

## Restore

From the recycle bin, **Restore** brings a soft-deleted asset back
to active, no permission changes, no URL changes, just moves out of
the bin.

## Storage stays used until permanent delete

The Assets tab meter includes soft-deleted files. This is the
opposite of what you might expect, most trash bins in most products
"free up space" on soft delete. Ours does not, because the URL
still serves and R2 still stores the bytes.

If you are running close to your plan's storage budget, soft delete
does not help. Permanent delete does.

## Dependents check

Before deleting, click the asset to see **which variants reference
this file**. Substring match on the URL across every variant's JS
and CSS on the site.

Zero dependents is safe to delete. Non-zero dependents means at
least one variant will break if you delete the file, decide whether
to update the variant first.

## Assets that were used a long time ago

The dependents check reads *current* variants. It does not know
about:

* **Archived experiments**, the variants are still in the archive;
  the URL might still be embedded in the archived variant's JS/CSS.
* **Cloned experiments**, if the clone kept a hard-coded URL to the
  original's asset, the dependents check catches it via string
  match, which is why we do string match rather than a
  metadata-only lookup.
* **External embeds**, an email you sent, a third-party site that
  hotlinks the URL. Nothing on our side can see those.

For assets that have been around a while, prefer soft delete over
permanent delete. A week in the recycle bin gives you time to notice
external breakage.