Data Retention and Compliance | Self-hosted error tracking

Why retention control matters

Error data often contains sensitive information: request payloads, user IDs, session details, stack traces with application logic, and sometimes personal data. Keeping it forever increases your attack surface, storage costs, and compliance burden.

At the same time, you may need different retention for different projects. A customer-facing production app might need 90 days for debugging and support. An internal tool or staging environment might be fine with 30 days or less. Regulated industries often have strict maximums.

Self-hosted tools give you the control that SaaS vendors cannot (or will not) offer without expensive enterprise plans. Telebugs makes that control simple and automatic.

How Telebugs handles retention and purging

You control retention policies for your error data. You set the number of days error reports and associated artifacts should be kept. Telebugs runs background jobs that automatically purge old data according to your policy.

• Automatic purging: No manual cleanup required. Jobs run on a schedule and clean up reports, breadcrumbs, context, and related artifacts.
• REST API access: You can read and manage retention settings programmatically if you need to enforce policies from external systems.
• Offline operation: The entire system (including retention logic) works without any outbound connections. Your data never leaves the server.

Releases and sourcemaps are also tied to the same retention system. When a release's data is purged, its associated maps are removed too.

Compliance and privacy angles

Running Telebugs on your own infrastructure gives you strong data sovereignty. This is particularly valuable for:

• GDPR: Data minimization and the ability to delete personal data on request. You control exactly what is stored and for how long. Self-hosting means the data subject rights requests can be handled entirely within your systems.
• CCPA / CPRA and similar US state laws: Similar deletion and minimization obligations. On-prem keeps the data inside your compliance boundary.
• Industry-specific rules (healthcare, finance, government): Many organizations are not allowed (or strongly prefer not) to send error data containing user context to third-party SaaS vendors.
• Internal policies: Even without regulation, many companies have rules about how long debug data can live and who can access it.

Because Telebugs is a focused error tracker (no full APM, no session replay by default, no unnecessary telemetry), the amount of potentially sensitive data collected is already smaller than broader platforms.

Practical examples

A team sets a 90-day retention policy. A background job purges anything older every night. Storage stays predictable and they can prove to auditors that data older than the policy is gone.

A European company handling health-related data keeps everything for the minimum required period and uses the REST API to integrate deletion requests from their privacy portal directly into Telebugs.

A small team on cheap VPS hardware uses short retention (30-60 days) so their SQLite database and disk usage stay small even as they ship new features and see normal error volume.

When this matters most

If privacy, compliance, or cost/storage control are real constraints for your team, retention policies with automatic purging on self-hosted infrastructure is one of the clearest advantages over hosted error tracking services.

Teams that are already self-hosting for data residency reasons get the full benefit without extra work. Teams that are cost-sensitive appreciate that short retention directly reduces infrastructure requirements.

Everything is included with the standard one-time purchase. There are no retention tiers or "enterprise data controls" upsells.

Comparison to self-hosted Sentry

Self-hosted Sentry also lets you configure retention, but the implementation lives inside a much larger and more complex system. Managing retention jobs, storage backends, and cleanup across the many services required by Sentry self-hosted adds operational overhead.

Telebugs keeps retention logic inside the same lightweight single container. The feature is deliberately simple: set a number of days and the system takes care of the rest. This matches the overall philosophy of focused, maintainable error tracking rather than a full observability platform.

Frequently asked questions

Can I set a custom retention period?

Yes. You configure the number of days error data should be kept. Telebugs automatically purges older data according to your policy.

What exactly gets deleted?

Error reports, associated context (request data, breadcrumbs, user info, extras), and related artifacts such as sourcemaps tied to purged releases are removed. Some high-level aggregates used for dashboard counts may be retained longer in summarized form, but the detailed reports are gone.

Can I manually purge data?

The REST API and UI give you control to manage projects and data. For complete manual deletion of specific reports or bulk cleanup outside the normal policy, the API can be used to implement custom scripts or integrate with your existing data subject request workflows.

Does offline mode affect retention?

No. Retention and purging jobs run locally on your Telebugs instance regardless of whether the server has outbound internet access. The entire system is designed to operate fully offline.

How does this help with GDPR?

Self-hosting keeps the data inside your systems so you can respond to access and deletion requests without involving a third party. Combined with retention policies and automatic purging, it supports data minimization and storage limitation principles.

Ready to own your error data lifecycle?

Read the Telebugs manual for retention configuration and API details, or get Telebugs and set the policies that match your compliance and operational needs.