Retention settings determine how long Coroid keeps the data generated by your work. You can find them under Settings → Data → Data retention.
What gets stored
Running tasks produces more than just pull requests:
- Task and execution history
- Agent transcripts and tool call logs
- Verification runs, check output and findings
- Browser test artefacts
- Notification and delivery history
- Audit events
Most of this data is operational — useful for weeks, rarely for years. All of it represents storage you pay for and a surface area you are responsible for.
Configuring retention
Retention is set per category, as each category has genuinely different useful lifespans. Execution transcripts are valuable while debugging a recent failure but rarely afterwards. Audit events often have a mandated minimum retention period.
Two factors determine the retention window:
- How far back do we realistically need to look? For most operational data, this is weeks.
- What must we retain? Audit and compliance obligations set minimum thresholds you cannot ignore.
Set retention to the longer of these two periods, not to the maximum available value.
Purging
Once data exceeds its retention window, it is purged. Purging is irreversible.
What purging does does not affect:
- your repository, branches, commits or pull requests — these remain with your provider
- Project configuration, context and settings
- Billing records
Purging removes Coroid's operational record of how work was carried out, not the work itself.
Deleted projects
Deleting a project removes its configuration and history from Coroid, and it can be recovered for a limited time before permanent removal. This grace period is governed here.
Retention and audit
Audit events typically have an externally imposed minimum retention requirement. If you export audit events to your own SIEM, you can often meet your retention obligations there — allowing you to use a shorter window in Coroid while staying compliant.
See Settings overview to learn where audit export is configured.