What Actually Happens to a File After It Expires?

'It expires' is the kind of phrase that sounds definitive but covers a lot of engineering. Different file-sharing services mean very different things by 'expire'. Some put the link behind a 'this link has expired' page while keeping the file forever (looking at you, certain analytics tools). Some soft-delete for 30 days. Some immediately purge. Here's exactly what SendMe does.

The moment of expiry

Every transfer has an `expires_at` timestamp in our database, set at upload time. The instant the current time exceeds that timestamp, the file becomes inaccessible to receivers. The next request to /api/transfers/by-code/{code} returns a 410 Gone status — the standard HTTP code that says 'this resource is intentionally permanently absent'.

Crucially, this happens in real time. There's no cron job that 'sweeps' expired transfers every hour. The expiry check is part of every code lookup.

The actual file deletion

While the URL becomes inaccessible the instant the deadline passes, the bytes on disk are deleted in a background process that runs hourly. So technically a file might exist on encrypted storage for up to an hour after its public availability ends. During this window:

• →No public URL can access the file.
• →No SendMe API endpoint can access the file.
• →Internal storage layer would technically allow access — but no application code paths reach into expired transfers.
• →Object storage logs the lifecycle event (created, expired) for audit purposes.

Within the next hour, the background process issues a delete against object storage. The blob is overwritten and unrecoverable from our side.

What about backups?

Object storage providers maintain replicas of every blob across multiple availability zones for durability. When we issue a delete, the delete propagates to all replicas within seconds. There is no 'tape backup' or long-term archive that would retain expired files for compliance purposes — that would defeat the entire premise of expiry.

We do back up our database (metadata, user accounts, billing records) nightly. Database backups don't contain file content — only the metadata describing transfers (file name, size, content-type, expiry, code). After 90 days, even the metadata of expired transfers is purged from rotation.

Metadata we retain (and for how long)

After file purge, we retain aggregated, anonymised metadata for analytics: 'a 12 MB JPEG was uploaded on 2026-02-04, expired without download, deleted 2026-02-05'. This contains no information about who sent it or where it went. Aggregate metadata is retained for 12 months and then summarised into monthly statistics, which are kept indefinitely.

Legal holds

If we receive a valid legal order to preserve a specific transfer's content, we'd be required to comply. To date we have received zero such orders. If we received one, we would (a) preserve the file, (b) notify the user where legally permitted, and (c) publish the aggregate count in our annual transparency report. The published count is currently zero.

Why this matters

When you set a transfer to expire in 4 hours, you should be able to trust that 4 hours from now the file is genuinely inaccessible — to receivers, to attackers, to subpoenas issued after that window. SendMe's pipeline is designed to make that promise true within the limits of physics (you can't undo a download the receiver already saved) and law (we still comply with valid pre-expiry orders).