Storage maintenance

Cleanup policies reduce artifact growth inside TestOps, but operating a self-hosted instance also requires understanding where the data lives, how the cleanup queue behaves, and why database size may lag behind logical deletion. Use this page when storage keeps growing, when you are preparing for migration or retention changes, or when you need to verify that cleanup is actually working.

What data lives where

Allure TestOps uses two different storage layers for test-execution data.

PostgreSQL stores projects, test cases, launches, test result metadata, scenarios, error messages, and references to stored files.
S3-compatible object storage stores binary artifacts such as attachments and fixture files.

This split matters operationally: a cleanup policy may reduce object-storage usage, database row counts, or both, but those effects do not appear in exactly the same way or on the same schedule.

What cleanup removes and what it does not

Cleanup policies work on closed launches only. They can mark three artifact types for deletion:

attachments;
fixtures;
scenario data.

Cleanup does not remove every piece of metadata associated with a test result. In particular, traces, error messages, and other reporting metadata can remain in PostgreSQL even after the heavier artifacts are gone. This is one reason why database growth may continue to matter even after object storage starts to stabilize.

Why database size may not shrink immediately

When TestOps deletes rows from PostgreSQL tables, the database does not usually return that disk space to the filesystem right away. PostgreSQL marks rows as dead first, and then VACUUM or autovacuum reclaims that internal space for reuse.

This means two things:

cleanup can be working correctly even if disk usage is not dropping yet;
long-running storage pressure often means you need to review both cleanup policy coverage and PostgreSQL vacuum behavior.

To inspect dead-row pressure, start with a query like this:

SELECT
  relname,
  n_live_tup,
  n_dead_tup,
  last_vacuum,
  last_autovacuum
FROM pg_stat_all_tables
WHERE schemaname = 'public'
ORDER BY n_dead_tup DESC
LIMIT 20;

If dead rows keep accumulating in heavily updated tables, review your autovacuum settings with your PostgreSQL administrator. For planned maintenance windows, a manual VACUUM may also be appropriate.

How to inspect the cleanup backlog

Cleanup runs in two phases:

TestOps finds files that match the configured rules and puts them into the cleanup queue.
TestOps removes queued files in batches.

To check whether the queue is draining, query the cleanup table during the day:

SELECT COUNT(*) FROM blob_remove_task;

If this number remains high late in the day, the queue is not being processed fast enough for the current artifact volume.

When to tune the cleanup batch size

The cleanup worker deletes queued files in batches. If your instance generates more files than the worker can remove, increase the batch size carefully by setting ALLURE_SCHEDULER_CLEANER_BLOB_BATCHSIZE.

Use this only after both of the following are true:

the necessary cleanup policies already exist;
the queue in blob_remove_task does not return close to zero during normal operating hours.

Increase the value gradually and prefer doing so during periods of low system load. An aggressive batch size can compete with active test ingestion for the same storage resources.

Migration and retention-preparation cleanup

Before a major migration, storage move, or retention-policy reset, reduce the amount of historical artifact data first.

Practical sequence:

Review your cleanup rules and make sure passed, failed, and other statuses all have the coverage you intend.
Close long-lived launches that should no longer keep artifacts.
Let the cleanup queue drain and verify blob_remove_task is decreasing.
Review PostgreSQL dead rows and vacuum behavior before measuring the final storage effect.

This usually produces a more predictable migration window than trying to move a large volume of stale artifacts first.

When deleting historical launches is the last resort

If retention changes and cleanup tuning are still not enough, deleting old launches can remove a larger amount of execution history at once. Treat this as an explicit reporting decision, not just a storage trick, because launch deletion also removes analytical history that teams may still rely on.

Use that option only after you have confirmed:

the launches are no longer needed for reporting, audit, or release analysis;
cleanup policies already match the retention you want going forward;
the storage issue is large enough that normal cleanup will not catch up in time.