ScoutSentinelScoutSentinel
Menu

Data retention

What is stored, for how long, what survives expiry and how deletion and export work.

v1Updated

Retention is a plan entitlement and a per-organisation policy. It is enforced by storage lifecycle rules and by the API, not by hoping nobody asks.

Settings

Retention is configured in the Retention section of Settings → General (GET and PATCH /v1/settings/retention, admin role). Each value is bounded by your plan’s maximum, which the same response returns as limits.

Setting Applies to Range
evidenceDays Bulky evidence objects: screenshots, HTML, HAR, traces, response bodies, recordings, transcripts 1 to 3650 days, up to the plan maximum
observationDays Observations, step results and assertion results 7 to 3650 days, up to the plan maximum
auditLogDays The append-only audit log 30 to 3650 days, up to the plan maximum
rawAudioDays Raw call audio from voice probes (transcripts follow evidenceDays) 1 to 90 days

Plan maximums follow the plan table on the pricing page: 30 days of evidence on Starter, one year of history on Team, longer retention on Business and custom terms on Enterprise. Those figures are indicative launch hypotheses; the value in force for your organisation is always GET /v1/entitlements (evidenceRetentionDays) and the limits in your retention settings.

What is stored

Data Where Retention
Observations and assertion results (outcome, timings, metrics, summary hash) Postgres observationDays
Evidence objects Object storage, one bucket per environment, keyed by organisation, date and observation evidenceDays, or the per-object retentionUntil when it was extended
Evidence rows (kind, sha256, bytes, capturedAt, runner identity, probe version, redaction flag) Postgres Kept after the object expires so conclusions remain auditable
Events and their timeline Postgres Life of the organisation
Audit log and evidence access log Postgres, append-only auditLogDays
Secrets (test credentials, API tokens) Envelope-encrypted at rest with a data key per organisation Rotation replaces the saved value. Deletion is temporarily unavailable until race-safe reference checks are implemented; usage and version-history metadata are currently unknown.
Account and billing data Postgres and Stripe Life of the account plus statutory periods

What survives expiry

When an evidence object expires, its row keeps the kind, sha256, bytes, capturedAt, runner identity, probe version and the step it belonged to, and the API reports objectAvailable: false. An Event that cited it still shows what was captured, when, and its hash, so a historical conclusion can be checked against any copy you exported. Because text evidence is redacted before it is hashed, the hash matches the bytes you were able to download.

Extending retention and holds

Retention for one object can be extended with POST /v1/evidence/{evidenceId}/retention (retainUntil, reason); the extension and its reason are written to the evidence access log. Legal hold across all evidence of an Event, and evidence packs (every artefact and its metadata with a manifest of hashes), are Enterprise plan features; each export is recorded in the audit log.

Deletion

  • Retiring a Watch stops new runs and keeps history. Its Observations and Evidence follow the normal retention policy unless you request immediate deletion.
  • Deleting an organisation (owner role, confirmed by typing the organisation slug) schedules deletion of all tenant data, with a written confirmation when complete. Backups age out afterwards; the timings are stated in your order form.
  • Personal data in evidence (for example a test account’s name) is your test data. Use synthetic identities; see the synthetic traffic guidance.

Residency

Metadata is stored in the database region chosen at organisation creation (EU at launch). Evidence buckets are created in the same region. Enterprise plans can request additional regions.

Sub-processors

The current list of sub-processors, with purpose and location, is on the trust centre. We give 30 days’ notice before adding one.