Archiving policy

Two different things get confused here

Backups exist so data can be recovered after a failure. Archives exist so something can be produced later — a record, an audit trail, a migration’s original source.

They have different lifetimes and different reasons, and a policy that treats them as one number ends up wrong about both.

Platform logs

Operational logs (the platform’s own diagnostics, not your store’s content) are held in a central workspace with a short retention window measured in days, and the workspace runs under a daily volume cap.

Both settings are deliberate. Log volume was measured before either was set — the platform

was producing on the order of 3 GB per day, effectively all of it application console output. Retaining that indefinitely buys very little and costs continuously.

The cap does not blind the alerts

A daily ingestion cap raises an obvious worry: does the platform stop noticing failures once the cap is hit? No — the alert rules in Monitoring & alerting run against metrics, not against log ingestion. That was the reason the cap was set before the alerts were built, rather than after.

Migration archives

When a merchant’s existing website is migrated onto CIQRA, the original site is captured before the switchover — its pages, its assets and a manifest recording a cryptographic hash of every file.

The reason is specific: once a domain points at CIQRA, the previous site is no longer reachable, so any question of the form “what did this page look like before?” becomes unanswerable at exactly the moment it starts being asked. The capture is taken while the answer still exists.

These archives are treated as records, not as working files: they are held under access control and are not part of the public site they were taken from.

When you leave

Your store’s content belongs to you. Export and self-service backup exist so that leaving does not depend on our cooperation or our timeline.

We are not going to print a specific deletion timetable on this page, because a retention schedule is a commitment and ours has not been measured end to end — which of the platform’s stores, backups and log records fall away on which day is exactly the sort of statement that should be checked before it is published, not after.

What this page does not say

• It does not state a deletion SLA for account closure. Not measured.
• It does not state an encryption-at-rest scope for backups or archives. Not measured.