Retention is a per-workspace setting that clamps what you can query. Physical deletion is a separate, documented process.
Cloud retention has two parts. One is the query-window clamp: a per-workspace number of days that bounds how far back analytics and trace queries can read. The other is deletion: what happens to stored rows when you delete a workspace or account. These are configured and enforced differently, and this page keeps them separate so the guarantees are clear.
The local daemon is unaffected by any of this. Cloud reads a copy; your
~/.halton-meter/db.sqlite keeps every captured row until you prune or
wipe it yourself. See Cloud overview.
How retention is configured
Retention is configured per workspace via the workspaces.data_retention_days
column. The default is 365. This value clamps the analytics and trace
query windows: when a query asks for a period that reaches past the
retention floor, the backend's resolve_period returns HTTP 400 rather
than serving rows older than the window. The optimisation and overview
windows clamp their from boundary up to the retention floor instead of
erroring.
On the Business+ and Enterprise tiers, the Advanced settings endpoint exposes the retention configuration:
$ curl -H "Authorization: Bearer <token>" \ https://api.haltonmeter.com/v1/workspaces/{ws}/settings/advanced { "data_retention_days": 365, "audit_log_retention_days": 365 }
GET /v1/workspaces/{ws}/settings/advanced returns data_retention_days
alongside audit_log_retention_days (also 365). Advanced settings are
gated to Business+ and Enterprise; lower tiers do not expose this surface.
What the windows look like in the product
The Traces page applies tier-bound receipt windows on top of the configured retention:
| Tier | Traces window |
|---|---|
| Solo | Last 7 days |
| Team | Last 30 days |
| Business+ | Archived to the Audit surface; the Traces endpoint still returns roughly 30 days for parity |
These window numbers and the configured data_retention_days default do
not all agree, and we are not going to paper over that. The repository
carries a 365-day default column, a 7-day Solo Traces window, and a
separate note that Solo advertises a 90-day window for the optimisation
rolling analyses. The mechanism above is accurate. The exact per-tier
retention promise is regulated copy and is not yet settled.
Placeholder: the customer-facing per-tier retention period (Solo / Team / Business+) is being finalised. Until then, treat the windows above as the operative product behaviour, not a contractual retention guarantee.
Deletion
Deleting a workspace (or an account) is a soft delete. The workspace
row is stamped with a deleted_at timestamp and a documented window of
roughly 30 days is intended to pass before the data is physically
purged. The soft delete takes effect immediately for access: a
soft-deleted workspace stops serving in the product.
The physical purge worker that would sweep soft-deleted rows
(WHERE deleted_at < now() - 30d) is not yet built. The same is true
of the broader retention sweep: the requests table is partitioned by
month and the design anticipates a retention worker, and the
audit_events.retain_until column exists, but no worker is wired to act
on either today. Retention is enforced as a query-window clamp right
now. Automated physical deletion is documented-but-unbuilt.
Because retention older than the configured window is already unqueryable, export anything you need before you delete. Every project PDF report and the audit-log CSV are downloadable from the dashboard.
Placeholder: the data-retention and deletion guarantee (the deletion process, the exact grace period, and what "deleted" means once the purge worker ships) is being finalised. Until then this page describes the implemented mechanism only and makes no erasure promise.
See also
- Cloud overview: what the hosted cloud adds
- Data sync & retention: which fields sync and the per-tier retention windows
- Cloud security & compliance: auth, encryption, access control
- Workspaces: per-workspace billing, roles, and settings