Storage

Rustrak accumulates data fast — every error event, transaction, span, and source map adds up. The Storage page lets an admin see exactly what the instance is holding and reclaim space by deleting old data, much like a server’s disk-cleanup tools.

Storage is instance-admin only. Members never see it, and every cleanup is destructive, so it lives behind the admin gate.

Where to find it

Go to Settings → Storage (visible only to admins).

Usage overview

The top of the page summarises what the whole instance is holding:

• Database size — total size reported by the database, with the event count.
• Transactions and Spans — performance data row counts (a transaction has many spans, so spans are usually the largest by count).
• Source maps — the on-disk weight of uploaded source-map artifacts and how many files.

Row counts are exact. The database size is the figure the backend reports (pg_database_size on PostgreSQL, page count × page size on SQLite); source-map weight is summed exactly from stored file sizes.

By project

A per-project table breaks the same data down by project: events, transactions, spans, source maps, and an estimated size for each. Empty projects still appear with zeros, so you can see at a glance which project is accumulating the most.

The estimated size is the summed length of the JSON payloads a project owns across events, transactions, and spans — a real per-project weight, not an apportioned guess.

Cleaning up old data

Under Clean up old data you pick:

• Retention period — older than 7, 30, 60, or 90 days.
• Scope — all projects, or a single project.

Then Preview runs a dry-run: it counts exactly what would be removed and deletes nothing. You see how many events, transactions, spans, and empty issues a cleanup would remove before committing. Confirm in the dialog to delete.

What a cleanup does:

• Deletes events and transactions older than the cutoff (a transaction’s spans cascade away with it).
• Removes any issue left with zero events — no empty ghost issues are kept.
• Keeps the denormalized event counts on projects and issues in sync, exactly like deleting an issue does.

Retention is keyed on ingestion time (when Rustrak received the data), not on the client-supplied timestamp, so a bad clock on a sender can’t hide data from cleanup.

Warning: Cleanup permanently deletes data and cannot be undone. Always run the preview first and check the counts.

Orphaned source maps

Source maps are content-addressed and shared, so deleting a project leaves its source-map files behind with nothing referencing them. The Orphaned source maps panel reclaims that space:

• Preview counts the orphaned files and the bytes a cleanup would free — it deletes nothing.
• Remove deletes those files from the database and disk.

It only ever touches files that no upload references — files still used for symbolication are never removed. Chunks from completed uploads are already cleaned up automatically during assembly, so they don’t accumulate.

API access

Every endpoint requires an admin bearer token (or admin session). Non-admins get 403 Forbidden.

# Instance-wide summary
curl -H "Authorization: Bearer YOUR_ADMIN_TOKEN" \
  http://localhost:8080/api/storage/summary
 
# Per-project breakdown
curl -H "Authorization: Bearer YOUR_ADMIN_TOKEN" \
  http://localhost:8080/api/storage/projects
 
# Dry-run a cleanup (deletes nothing)
curl -X POST -H "Authorization: Bearer YOUR_ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"older_than_days":30}' \
  http://localhost:8080/api/storage/cleanup/preview
 
# Execute the cleanup (optionally scoped to one project)
curl -X POST -H "Authorization: Bearer YOUR_ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"older_than_days":30,"project_id":1}' \
  http://localhost:8080/api/storage/cleanup
 
# Dry-run, then remove, orphaned source maps
curl -X POST -H "Authorization: Bearer YOUR_ADMIN_TOKEN" \
  http://localhost:8080/api/storage/source-maps/gc/preview
curl -X POST -H "Authorization: Bearer YOUR_ADMIN_TOKEN" \
  http://localhost:8080/api/storage/source-maps/gc

The preview and execute endpoints return the same shape, so a preview tells you exactly what an execute will remove:

{ "events": 1240, "transactions": 80000, "spans": 1200000, "issues_removed": 37 }

You can also drive all of this from an AI assistant via the MCP server — the destructive cleanup tool requires an explicit confirmation flag before it will run.

Behavior reference