Data Retention Schedule
Last updated: August 14, 2026
01How to Read This Schedule
Article 5(1)(e) of the GDPR says personal data must be kept in an identifiable form no longer than is necessary. This page is our answer, category by category, with the reason attached to each period rather than left implied.
The periods here are the ones the deletion jobs actually enforce, not aspirations. A set of scheduled jobs runs daily against each table and removes what has aged out; where a period below is a policy we apply by hand rather than a job, the row says so.
Where a period looks unusually short, it is because the data is a credential or a transient marker. Where it looks long, the reason is nearly always a dispute window: a chargeback, a licence-abuse claim or a statutory accounting duty outlasts the product usefulness of the record by a wide margin.
Which third parties hold copies of any of this is listed on the Sub-processors page.
02Account & Billing
| Data | Retention | Why |
|---|---|---|
| Account record — email address, name, authentication settings | Life of the account, then per the cancellation policy below — 30 days if the email address was never confirmed | It is the account. Deleting it while the subscription is live would remove your own access. A signup that never confirmed its address is a different case: there is nothing to protect, so it goes early. |
| Subscription and licence key records | Life of the account, then per the cancellation policy below | Needed to answer entitlement questions, restore a licence after a billing problem, and defend a chargeback. |
| Transaction records — what was bought, when, for how much, and the tax applied | The statutory accounting retention period in the jurisdiction that applies to us, commonly 6 to 10 years | A legal obligation, not a choice. Tax and company law require a seller to keep books and records, and Art. 17(3)(b) of the GDPR expressly preserves processing needed to comply with such an obligation. These records survive an erasure request — see below. |
| Registered devices | Deactivated automatically after 180 days without contact when no active subscription remains; the record itself is retained with the account | The device list is what enforces the per-licence device limit and what a customer checks when they get a new machine. Deactivating a dormant device frees the seat without erasing the history that explains why a seat was used. |
| Newsletter subscription | Until you unsubscribe | Consent-based, and consent lasts until it is withdrawn. Unsubscribing is one click in any newsletter we send. |
| Email suppression list | Indefinitely, unless you ask us to remove an address | A suppression list has to outlive the record it suppresses. Deleting the entry for someone who unsubscribed or hard-bounced is how a service starts emailing them again, which is the outcome the list exists to prevent. |
03Authentication, Sessions & Tokens
Almost everything in this section is a credential with a deliberately short life. The pattern is the same throughout: the shorter the window, the more damage the item could do if it were intercepted.
| Data | Retention | Why |
|---|---|---|
| Web session (server-side) | 7 days, extended while you keep using it, up to 30 days from sign-in | Long enough not to sign a working professional out mid-week; short enough that an abandoned session on a shared machine expires by itself. The 30-day ceiling is what the sliding renewal cannot extend past, so a session that is kept warm indefinitely still ends. |
| Step-up re-authentication marker | 5 minutes | It exists so that a destructive action needs a fresh password or authenticator challenge. A longer window would defeat the point: a stolen live session could then delete the account. |
| Magic sign-in links | 15 minutes for sign-in, 30 minutes for a post-purchase link; single use | A link in an inbox is a credential. The window is the shortest one that still survives a slow mail server. |
| Consumed magic links | 7 days after creation, then deleted | Keeps it possible to correlate a session back to the link that created it while investigating a report, then removes it. |
| Email verification tokens | 24 hours; single use | People do not always check email immediately, and a verification link is lower risk than a sign-in link. |
| Password reset tokens | 1 hour; single use | The highest-value token we issue. It is deliberately the shortest. |
| Revoked session identifiers (the desktop sign-out blocklist) | 30 days | It must outlast the longest-lived refresh token that could still be presented, which is 14 days. Shortening it below that would let a revoked session be re-validated. |
| Revoked licence tokens | Grace-period entries 24 hours past their grace end; all entries 30 days | The blocklist only needs to cover the lifetime of the tokens it blocks. Beyond that it is dead weight that slows the lookup it exists to serve. |
| Desktop app sessions | A session with no heartbeat for 1 hour is closed and marked crashed; ended sessions are deleted after 30 days | Recent session history answers 'was the app actually running when the show failed?'. A month of it is enough; a year of it is a log nobody reads. |
| Rate-limit counters and lockouts (short-lived rows in the database, not a separate cache service) | The length of the window: 60 seconds or 1 hour for most limits, 24 hours for a licence-key prefix lockout, up to 24 hours for a per-day limit | A counter with no expiry is not a rate limit, it is a permanent ban. Each key expires with its own window. |
| Short-lived key-value entries (sign-in state, one-time flows) | Their own time-to-live, then deleted by the daily sweep | These are transient by construction. The sweep exists because rows whose expiry had passed were being ignored by readers but left on disk. |
04Studio Content
Studio content is yours, and the default is that we keep it until you remove it. The rows below cover the cases where something is removed without you asking — an abandoned upload, an orphaned file, an expired invitation.
| Data | Retention | Why |
|---|---|---|
| Projects, cues, tracks, sections, comments, snapshots and spec documents | Until you delete them, or per the cancellation policy below | This is your work. It stays until you or your project owner removes it, or until the account it belongs to is closed. |
| Uploaded files — audio masters, PDFs, images, specs — in object storage | Until the project or the file is deleted; then removed from storage by the cleanup job | Deleting a reference without deleting the object would leave your audio on our storage indefinitely. The job closes that gap. |
| Incomplete uploads | 24 hours | An upload that was started and never finished is not your content; it is a stuck request holding your project's storage quota. |
| Files no longer referenced by any track or document | Deleted after a 1-hour grace window | Replacing a track's audio orphans the previous file. The grace window avoids deleting a file that is mid-way through being attached. |
| Project membership and invitations | Membership for as long as the person is a member; unaccepted invitations expire after 7 days | An invitation is an offer, and an offer that stays open forever is a live credential sitting in an old inbox. |
| Project activity feed | 365 days | A full production cycle. It answers 'who changed this cue, and when' for the season the show ran in, and stops being useful long before it stops being personal data. |
| Presence (who is currently viewing a project) | 7 days | Presence is meaningful for about ninety seconds. Seven days is a generous margin over a job that runs daily, not a retention decision. |
05Security & Anti-Abuse Records
| Data | Retention | Why |
|---|---|---|
| Audit log — sign-ins, activations, subscription changes, administrative actions | 90 days live, then moved to an archive; the archive is deleted at 12 months | The live window is what the account's own audit view and an active investigation need. Twelve months total covers a full billing cycle and a dispute that follows it, which is the outer edge of when an audit row is still evidence of anything. |
| Anti-tamper signals from the desktop application | 730 days | Longer than analytics on purpose. A chargeback or a licence-abuse dispute reaches back further than a funnel report, and this is the evidence that answers it. Shortening it is a policy decision, not a cleanup. |
| Anomaly signals (unusual device, activation or network patterns) | 730 days from when the signal was last seen | Same reason as above. These are also what a false-positive review is calibrated against, so deleting them early would make the detector harder to make fairer. |
| Known sign-in locations, stored as one-way hashes of the IP address | 180 days | It exists only to decide whether to send you a 'new device' notification. An address you have not used in six months is a new location again, which is the correct answer. |
| Multi-device confirmation records | 30 days past their own expiry, once any suppression window has lapsed | The record is what stops us asking you the same question twice. It is useless once both windows have passed. |
| Copyright notices and counter-notices | 3 years from receipt | We have to be able to show how a notice was handled, and a misrepresentation claim under the DMCA can be brought long after the takedown. The retention is of the correspondence and the identification of the material, not of the material itself. See the Copyright & Takedown policy. |
06Product & Release Analytics
These are counts of product events tied to an installation or an account, held in our own database. Website analytics held by third parties are covered further down.
| Data | Retention | Why |
|---|---|---|
| Update-install events (which build was installed, and when) | 365 days | A full seasonal cycle. It is how we tell whether a release actually reached people before we decide to stop supporting the one before it. |
| First-cue events (whether a new installation got to a working cue) | 365 days | The single measure of whether the product onboards people. A year lets it be compared against the same point in the previous season rather than against last month. |
07Operational Records
Records of the machinery rather than of you: billing events arriving from the payment processor, the outbound email queue, and the jobs that process them. They contain personal data incidentally — an email address, an account identifier — which is why they are in this schedule at all.
| Data | Retention | Why |
|---|---|---|
| Webhook event log (billing events received from Paddle) | 90 days once processed | Long enough to answer 'which event changed this subscription last month?' during a billing dispute. Events still in flight or stuck are kept regardless of age until an operator resolves them, because deleting an unresolved job is deleting the evidence of a problem. |
| Webhook de-duplication records | 30 days | They exist to stop the same billing event being applied twice on a retry. No payment processor retries an event a month later. |
| Permanently-failed webhook jobs | Cleared from the work queue 7 days after the final failure | A job that has exhausted its retries is an operator's problem, not the queue's. The record of what happened stays in the event log; only the dead queue entry goes. |
| Outbound email queue — messages that were sent or permanently failed | 90 days | The window in which someone says 'I never received my licence key' and we need to show whether it was sent. Messages still pending or retrying are never deleted by age. |
08Backups
The database is backed up on an encrypted, rolling cycle: a nightly dump encrypted before it is written to disk and retained for 30 days, plus an hourly copy to separate off-site storage. The backup job refuses to run at all if the encryption key is missing, rather than producing a readable dump.
Backups are not selectively editable, and this is the honest consequence: data deleted from the live system persists in backups until those backups age out of the cycle. During that period it is not restored, not queried and not used for any purpose other than disaster recovery, and it remains covered by the same confidentiality and security obligations. If a restore ever did bring back data that had been erased, we would re-apply the erasure after the restore.
09Data Held by Third Parties
Some data is held by providers on our behalf, and their retention is set in their systems rather than ours. We are not going to state a number here that we cannot enforce.
- Support chat and CRM records (ClientFlow): retained until deleted on request — they have no automatic expiry. Ask us and we will have them deleted. The copy in your own browser clears after 24 hours, or immediately when you use "Clear conversation".
- Website analytics and session replay (PostHog): retained under PostHog's configured retention, which is a provider setting we have not restated here because it can change without a code change. It is only collected at all after you accept analytics cookies.
- Error monitoring (Sentry):retained under Sentry's configured retention. Events are stripped of credentials, tokens and licence keys by a filter in our own code before they are sent.
- Payment records (Paddle): held by Paddle as Merchant of Record under its own policy and its own statutory duties, independently of us.
- Advertising platforms:conversion events and hashed identifiers are retained under each platform's policy. The Do Not Sell or Share page explains what is sent and how to stop it.
If you need a specific provider's retention confirmed for a compliance review, ask at privacy@cuesync.live and we will get it in writing and publish it.
10After You Cancel or Delete
Cancelling a subscription
Cancelling ends the subscription at the end of the paid period. Your account and your data stay where they are; you keep the ability to sign in, and Studio content remains until the retention window below runs out. Cancelling is not deleting, and we do not treat it as a request to erase anything.
The 90-day window
Account data is kept while your subscription is active, plus 90 daysafter it ends. An account whose entire paid footprint has been dead for longer than 90 days is erased, by exactly the same erasure an erasure request runs — one routine, not two, described under "Deleting your account" below. A job on our server runs nightly to find those accounts.
What that job does today is report, not erase. Enforcement has not been switched on in production yet, so each nightly run lists the accounts that are past the window and the erasure is then applied by hand. We would rather say that than let a page imply your dormant account has already been erased on a schedule. When enforcement is switched on the nightly run erases them without anyone asking, and this paragraph will say so instead.
Ninety days is long enough to cover a production that ends and resumes a season later, an accidental cancellation, and a billing failure resolved a month afterwards — all of which we have to be able to undo without asking you to rebuild a show from scratch.
The job refuses rather than guesses. It will not touch an account with any live entitlement — a subscription still inside its paid period, an unrevoked add-on grant, an active licence key — and it will not touch one showing any sign of life inside the window: a device that checked in, a desktop session heartbeat, or any recorded account activity. Signing in resets the clock. An account that subscribed and never cancelled is out of scope of the 90 days, because there is no cancellation date to count from and this window is not a licence to invent one.
Signups that were never confirmed
Creating an account records your email address before you confirm it, because the confirmation link has to be sent somewhere. If that address is never confirmed — a typo, a signup you thought better of, a link that never arrived — the account is deleted after 30 days, and there is nothing to keep: no subscription, no licence, no content. Confirming the address, signing in, or asking us for a new confirmation email all reset that clock, so the only accounts this reaches are ones nobody came back to.
This window is narrower than the 90-day one in every respect, not just shorter. It applies only where there has never been a subscription, a licence key or an add-on of any kind, and never to an account created by signing in with Google or Apple — those addresses are confirmed by the provider. As above, what the nightly job does today is report rather than erase; the deletion is applied by hand until enforcement is switched on.
Within the window, ask and we will erase it immediately. After it, the erasure is not reversible: there is no recovery path once the records are anonymised, which is the point.
Deleting your account
Ask us to delete the account by emailing privacy@cuesync.live from the address on it. We answer within one month, and what we then run is the erasure described above, in a single transaction: your personal details are anonymised, every device is deactivated, licence keys are revoked, active subscriptions are cancelled with the payment processor, and every session is destroyed. Once it runs it takes effect at once and it is not reversible. The audit history of what happened on the account is retained, without your identity attached, for the periods in the security section above.
Export anything you want to keep before you do this — a Studio project exports as a show file any member can download, and it is the only copy you will have afterwards.
11What Survives an Erasure Request
The right to erasure is not absolute, and a page that implies otherwise is setting up a disappointment. Article 17(3) of the GDPR preserves processing that is necessary for compliance with a legal obligation, or for the establishment, exercise or defence of legal claims. In our case that means:
- Transaction and accounting records. What was bought, when, for how much, and the tax applied. Tax and company law require these to be kept for a fixed number of years, commonly 6 to 10 depending on the jurisdiction, and we cannot delete them on request. They stay, in the narrowest form that satisfies the obligation.
- Records of a dispute in progress. A chargeback, a copyright notice, an abuse investigation or a legal claim keeps the records it concerns until it is resolved.
- Suppression entries. An email address on the suppression list stays there, because removing it is how we would start emailing someone who asked us to stop.
- Backups already taken, until they age out on the cycle described above.
Everything else goes. We do not use a legal-obligation exception as a reason to keep a general profile of you: the surviving records are the specific ones a law names.
12Asking for Earlier Deletion
You can ask us to delete something sooner than this schedule provides, and for anything not covered by the exceptions above we will do it. Write to privacy@cuesync.live from the address on the account, or from an address we can verify, and say what you want removed.
We respond within one month, the deadline Article 12(3) sets. If a request is complex enough to need longer we will tell you inside that period, with the reason, rather than letting it run over in silence. If we cannot delete something, we will say which exception applies and how long the record will live.
The other rights that go with this one — access, correction, portability, objection, and the California-specific rights — are set out in the Privacy Policy and the Do Not Sell or Share page.
13Contact
Questions about this schedule, or about a category it does not cover: privacy@cuesync.live.
CueSyncreviews this page when a retention job changes. The "Last updated" date at the top is the date of the last such review.