Data Retention

Two rules about plans, and one exception

A retention window runs from the moment a record is written. It is not measured from the end of your billing period, and it does not restart. A log line written today is governed by the window in force when it was written.

Changing a plan never shortens data that is already stored. A plan change applies forwards only, by design. If you downgrade, records already written keep the window they were written with, and they age out on that schedule. This is deliberate: the alternative would delete history a customer already paid to have collected. Upgrading works in the other direction and does reach back, lengthening the window on rows already written.

The exception is a ceiling you set yourself, and it applies to exactly two categories. Real user monitoring measures and real user monitoring events can each be capped below your entitlement, per application, and unlike a plan change that cap does reach back over data already written for that application. Nothing else in this document can be shortened by a setting: not session replay, not telemetry, and nothing outside the analytics store. The two sections below say exactly how it behaves; every other window on this page is decided by your plan alone.

One consequence worth stating plainly: deleting a monitor, an application or an alert destination removes it from your dashboard, but it does not delete the history already stored for it. If you want that history deleted, ask us.

Where we enforce a window automatically

Every figure in this table is enforced by a database time-to-live rule, an object-storage lifecycle rule, a partition-retention setting or a log-group retention setting. These delete data whether or not anyone asks.

Where the behaviour is not a simple window

Some categories behave in a way a single number would misrepresent, so we describe them instead.

Real user monitoring measures (page views, Core Web Vitals, page and resource URLs, user agent, country)

These are kept for 458 days, a little over 15 months, on every tier, free and paid alike. Your plan does not change it: 458 days is the window on the free tier and on every paid tier, so there is nothing to buy and nothing to lose by downgrading. It is by a wide margin the longest window in the product and is materially longer than everything in the table above, so we would rather flag it than bury it. Note that 15-month retention is a property of every account rather than a feature of any particular tier, and we no longer present it as one.

Lowering a real user monitoring window yourself

Two categories, and only these two, can be capped below your entitlement: real user monitoring measures (458 days) and real user monitoring events (30 days). The cap is set per application, and the window stamped on each new row becomes the lower of your entitlement and the cap you set.

• It can only ever shorten. A value above your entitlement is accepted and silently capped at the entitlement, so this can never be used to buy retention.
• The floor is one day. Zero is refused with an error rather than accepted, because a zero window would expire a row the moment it was written.
• It reaches backwards. Setting a cap also lowers the window on data already stored for that application. This is the one place in this document where a change shortens existing data, and it is deliberate: a retention period you cannot reduce is the problem this setting exists to solve.
• It reaches only the application you name, inside your own account.
• It is available through the API only today. Set settings.retention.observe_days or settings.retention.analyze_days on PUT /rum/{app_id}. There is no control for it in the dashboard, and we would rather say so than let you look for one.
• It does not extend to session replay. A request that includes a replay window is refused with an error explaining why, rather than being accepted and ignored. See the session replay rows above.

[[VERIFY: whether the retention ceiling and the URL minimisation described on this page have shipped to production at the time this page is deployed. Both ride on one change to the API and the two ingest services. Until it is live there is no ceiling to set, and the page and resource URLs stored for 458 days still carry their query strings.]]

Stored response bodies from failed HTTP checks

When a check fails we store the response body so you can see what the endpoint actually returned. Your plan window controls how far back we will show you a stored body. It is enforced when a body is served, not by deleting the object. The object itself is deleted on a separate fixed schedule that is longer than any plan window. Two consequences: upgrading your plan retroactively unlocks bodies we already captured, and downgrading does not delete anything. [[FOUNDER INPUT: decide whether the read-gate windows and the deletion ceiling are published as figures. Today the plan window is a read gate and the only deletion is the storage ceiling, so quoting the plan window alone as a retention period would be misleading.]]

Migrated historical response bodies

A one-time migration moved the full response body of every historic check into object storage. That set of objects is deliberately excluded from the deletion schedule above and has no deletion schedule of its own. It accumulates.

Where nothing is deleted automatically today

The following are retained indefinitely. There is no time-to-live, no partition drop and no scheduled job that removes them. We are publishing this rather than implying a window that does not exist. Data in these categories can be deleted on request: see the section below.

• Account, user, API key, integration, notification, usage and activity records. Closing an account marks it deleted and ends access to it. It does not by itself erase these records.
• HTTP check results. Each result stores the request headers used for the check, including any authentication header configured on that check, an extract of the response body, the full response header map, and the resolved remote address. Partition retention on this table is deliberately not armed, because dropping partitions would leave the archived response bodies unreachable.
• Notification delivery records. The recipient address or phone number and the rendered content of every message we sent.
• Email bounce and complaint records. The recipient address, the diagnostic returned by the receiving mail server and the full raw event, including for recipients who hold no account with us.
• The customer audit log. The dashboard shows you the last 90 days. That 90 days is a read limit in the API, not a deletion: rows older than that are retained.
• The staff audit log.
• Invitations that were never accepted. An invitation expires 14 days after it is sent, but expiry is evaluated when the invitation is read. The record, including the invited email address, is not removed.
• Inbound cron heartbeat records. Every request header received on a heartbeat endpoint, verbatim, plus the raw forwarded-for string.
• A second copy of every ingested log line, written to object storage in parallel with the analytics store. This copy has no deletion schedule, which means it outlives the log retention window in the table above. If you are relying on a 3-day or 30-day log window, this is the exception you need to know about.
• Source maps you upload for error symbolication.
• Status page branding assets you upload.

[[FOUNDER INPUT: retention period to commit to for each of the categories above. Do not publish a window on this page before the code enforces it: the whole reason this page exists is that published windows had drifted from what the software does.]]

Four stores that sit in a third party’s console, not in our code

The four below are configured in another company’s administration console rather than in software we deploy, so we cannot read their retention out of our own source the way we can for everything else on this page. We are recording all four as indefinite until we have confirmed the configured value. That is the honest reading: a retention setting we have not checked is not a retention we can promise, and we would rather state the worst case than publish a number we guessed.

• Google Analytics 4 marketing-site data (property G-3TNM429V9M): visitor identifiers, IP-derived location, pages viewed and referrer, for visitors to our marketing sites. Retained indefinitely. [[VERIFY: confirm the configured data-retention setting in the Google Analytics 4 admin console]]
• Microsoft Clarity session recordings (project tbv6fv0o2l): recordings of how visitors move through and interact with our marketing pages. Retained indefinitely. [[VERIFY: confirm the configured retention in the Microsoft Clarity console]]
• Our internal Slack alert channel. Every application log line at error level is posted to a Slack channel we operate. Six of our API handlers put a user’s email address into the logging context, so an error in one of those requests posts that address into the channel; monitored URLs and domains reach it the same way. Retained indefinitely. [[VERIFY: confirm the configured message-retention policy on the Slack workspace and on that channel]]
• The support mailbox. Everything anyone writes to support@siteqwality.com, plus the body of any in-app support message and the sender’s IP address, held in a hosted Zoho Mail mailbox. Retained indefinitely. [[VERIFY: confirm the configured retention and any archival policy on the Zoho Mail tenant]]

Asking us to delete something

Write to privacy@siteqwality.com. Deletion is carried out manually by our staff across the transactional database, the analytics store, object storage and the relevant providers, and we will confirm what was deleted and when. There is no self-service deletion control in the dashboard today, and deleting a monitor or an application through the product does not delete the stored history behind it.

If you are an end user of a website that has installed Site Qwality, we hold your data as a processor. Send your request to the operator of that website. See the Privacy Policy for how that works.

Related documents

• Privacy Policy: what we collect, why, and your rights over it.
• Data Processing Addendum: the contractual terms, including deletion on termination.
• Subprocessors: who else processes the data, and where.
• Cookie Policy: cookies and browser storage on our websites and in our SDK.