Projects & Quotas

A project is one application or service sending data to Tindra. Each has its own DSN, settings, and storage figures. This page covers creating projects, quotas, retention, and the per-project profiling switch.

Projects#

A project maps to one application or service. Each project has its own DSN, event count, and settings.

Create projects from Settings > Projects using New project (or Create project on an empty instance). Give each project a descriptive name that matches the service it represents: api-server, frontend, worker, etc.

Verify a project's setup#

Choose Verify setup after creating a project, or expand an existing project and choose Check setup. The setup page provides the DSN, a fresh tagged test, stored-data checks, and source-map verification. You can rerun it for a new deployment or environment. See Project Setup.

DSN#

Find the project DSN by expanding its entry in Settings > Projects. Copy the complete value into your SDK configuration.

A DSN looks like:

https://your-key@your-hostname.tindra.sh/550e8400-e29b-41d4-a716-446655440000

The final path segment identifies the project. The DSN is an ingestion credential; it is separate from the project-scoped bearer tokens in Settings > Tokens.

Event quotas#

Tindra does not enforce hard per-project quotas by default. All projects on a self-hosted instance share the same Postgres database.

For managed instances, quotas depend on your plan. Check your current usage from Settings > Overview in the dashboard.

Profiling#

Profiling is on for every project by default. To turn it off for one, open Settings > Projects, edit the project, and uncheck Accept profiles from this project.

The profile storage budget is instance-wide, and the retention worker deletes oldest first across every project. One busy service profiling continuously can therefore crowd out everyone else's profiles. This checkbox is the lever against that, and it works without touching the service's SDK config.

Turning it off stops profiles being stored. Errors, transactions, and everything else from that project keep flowing. Profiles already stored stay until they age out. See Profiling.

Retention#

General telemetry age retention is controlled by RETENTION_DAYS (default: 90), globally rather than per project. Cleanup runs at startup, normally repeats hourly, and catches up after five minutes when a pass exhausts its deletion budget. Completed cron history follows this policy too; running check-ins and monitor summaries remain.

Setting RETENTION_DAYS=0 disables general age cleanup only. Log and transaction row caps remain active independently; transaction cleanup also deletes child spans. Profiles follow PROFILE_RETENTION_DAYS and an instance-wide compressed-byte budget. All caps are periodic cleanup policies and may temporarily be exceeded. See Configuration.

Storage figures#

The per-project storage number in Settings > Projects includes stored profiles. Profiles are usually the largest thing a project stores, so turning profiling on will visibly move that figure.

Deleting a project#

Go to Settings > Projects, open the project, and scroll to the danger zone. Deleting a project permanently removes all associated events, issues, and client keys. This cannot be undone.

Multiple environments in one project#

Most teams use one project per service and configure environment in the SDK to separate production from staging. There is no need to create separate projects for each environment.

SENTRY_ENVIRONMENT=production