This is the end-to-end timeline of what happens to a bucket when a service is cancelled. Page-by-page details are in the Bucket Cleanup Plugin article.

Why staged?

Force-deleting a bucket with millions of objects can run for hours — far too long for the web request that processes a cancellation. So cancellation never deletes anything directly: it queues the bucket, and an hourly cron walks it through expiration and deletion with two approval gates and a full audit trail.

The timeline

T+0 — cancellation. The service is cancelled in Blesta; the bucket is queued (Needs Lifecycle Approval). Data is untouched. If the cleanup plugin isn't installed, cancellation is refused.

Gate 1 — lifecycle approval. In Admin approval mode a staff member approves; in Automatic mode the next cron pass approves by itself.

T+~1h — lifecycle applied. The cron attaches a 1-day expiration rule to the bucket and locks it against new uploads (the cancelled client's keys still exist, so writes are explicitly denied). Objects start expiring roughly 24 hours later.

T+~26h — deletion approval. After a 25-hour wait (24h expiry + 1h buffer) the record moves to Needs Deletion Approval. Gate 2: staff approval or automatic, same as gate 1.

T+~27h — deleted. The cron force-removes the now-mostly-empty bucket and marks the record Deleted. The audit record stays forever (prunable from the UI). Impatient? Delete Now on an approved record runs the removal immediately.

In fully automatic mode the whole flow takes roughly 26–27 hours with zero clicks; in admin-approval mode it pauses indefinitely at each gate.

If the service comes back

Reactivating the service at any point stops the machine:

• Before deletion — the cleanup is Aborted: the expiration rule is removed and the bucket policy restored. Objects already expired (reactivation later than ~24h after gate 1) are gone.
• After deletion — the bucket is re-provisioned automatically: recreated empty with the package quota and visibility. The client's user, keys and permissions survived, so everything works — with a fresh, empty bucket.

Neither the cron nor Delete Now will ever remove a bucket whose service is active again.

Failure handling

Every failed step is recorded on the record's notes with a failure counter; after 5 failures the cron leaves the record alone until staff press Retry. A bucket that already vanished from the server counts as successfully deleted. The Orphaned Buckets page catches anything that ever falls between Blesta and the storage server, in both directions.