Project Setup
Connect an application, confirm a stored test event, and check tracing, profiling, and source maps from one project setup page.
Open setup for your project
Create a project in Settings > Projects, then choose Verify setup. For an existing project, expand its entry and choose Check setup. You can also open /setup on your Tindra instance and select a project, or go directly to /projects/your-project-slug/setup.
An unconnected project's dashboard can show the same setup panel. You can return to setup later to test a new deployment or environment.
Configure the SDK
Use Copy DSN to copy this project's complete ingestion address. Configure the running application with that value, including its public key, hostname, and project identifier. A bearer API token is not a DSN.
The setup panel provides browser JavaScript and Node.js snippets. For other platforms, use the SDK guides to install and initialize the SDK, then send the tagged test described below. If the app already initializes Sentry, keep that initialization and add the test capture after it.
Confirm a fresh test event
- Choose Start setup check to generate a check for this project.
- Select the appropriate SDK and use Copy snippet, then run it in your application. The snippet attaches a
tindra_setupevent tag containing the check ID. - Keep the setup page open while Tindra waits for the matching event. Flush pending SDK events before a short-lived process exits.
- Wait for Test event received, then choose View event to inspect the stored occurrence.
For an SDK without a generated snippet, capture an exception with tindra_setup set to the check ID shown on the page. Apply the tag to that test event's scope and remove it when finished. An ordinary test exception without the marker can confirm that the project receives errors, but it will not complete this particular check.
Confirmation requires a matching event stored for this project within the check's 24-hour window. An earlier event, unrelated traffic, or an HTTP success response from the ingestion endpoint does not complete it. The issue link may appear shortly after confirmation while grouping finishes.
Choose Start a new test to generate a fresh check and snippet. If the check has expired or is no longer available, use the offered restart button and run the new snippet; reusing an old marker will not confirm the new check.
Read the data checks
Errors, transactions, and profiles have separate storage milestones. Transactions, profiles, and source maps are optional, so you can finish basic error setup without enabling them.
| State | Meaning and next step |
|---|---|
| Not yet received | No storage milestone or recent queue observation is available for this data type. Send the appropriate SDK data. |
| Queued | Tindra accepted data into its ingestion queue, but storage has not been confirmed. Check again shortly. |
| Received | This project has stored data of this type. Inspect the first/last stored times and the available example link. |
| Needs attention | A recent rejection needs checking. Expand the section for the reason and observation time; other items may have succeeded. |
| Disabled | Profile ingestion is disabled for this project. Enable it in project settings if you want profiles. |
These checks cover the whole project across environments and investigation time filters. Storage milestones survive telemetry retention, so Received can remain after the example event, transaction, or profile expires. It confirms past storage, not continuous delivery from every deployment. Run a fresh tagged check to test the app you are working on now.
For transactions, enable SDK tracing and complete a request or page load. Temporarily sampling all traces in development can help verify delivery; choose an appropriate production rate afterward. For profiles, enable Accept profiles from this project, install the SDK's profiler, and allow a sampled transaction or continuous profile chunk to finish. See Profiling if no linked transaction appears.
Nothing arriving?
Start with the running application's SDK request or debug output. The setup page cannot report requests that failed before Tindra identified the project, and database failures can also prevent diagnostics from being recorded.
| Symptom | What to check |
|---|---|
| No request leaves the app | Confirm SDK initialization, environment settings, event sampling, and capture filters. Flush before process exit. |
| Network failure or HTTP 401 | Check the complete DSN, public key, hostname, proxy routing, and blocked browser requests. |
| HTTP 413 or a size warning | Reduce the payload or attachments and check the proxy's request-size limit. |
| HTTP 429 or an event-limit warning | Check instance usage, quotas, and rate limits. Retry after the limit permits traffic; repeatedly sending the test will not bypass it. |
| Invalid envelope or compression warning | Check the SDK version, custom transport, and proxy compression settings. Send a standard SDK envelope. |
| Buffer full | Wait briefly and retry. If it continues, inspect server load and database writer logs. |
| Storage failure or persistently queued data | Check database connectivity and writer logs, restore normal operation, then run a fresh test. HTTP acceptance alone does not guarantee persistence. |
| Invalid or disabled profiling data | Check the project profiling switch, SDK integration, profile format, and duration. |
| Setup status unavailable | Retry the status check and inspect the server/API response. Do not interpret an unavailable status as evidence that no data arrived. |
See Configuration for instance limits and Shared Filters if setup confirms storage but a list looks empty.
Verify source maps from a built app
Open Source maps under Data checks after sending an exception from your built JavaScript application. A generic setup snippet establishes delivery, but its stack may not exercise the bundled files you want to verify.
Enter the exact Tindra event ID and choose Verify source maps. Use the UUID in the issue link's event_id parameter, rather than the issue ID or the SDK's event ID. Leaving the field empty uses the project's latest error, which may belong to another environment or build.
The result shows the event release, generated frame locations, matching URLs, and any resolved original source locations. An upload count means maps exist; Verified means the checked frames actually resolve. If a map is missing or mismatched, a user with project-management permission can choose Upload a source map, supply the event's release and matching generated-file URL, then choose Upload and verify.
See Source Maps for build settings, CI uploads, limits, and the meaning of each verification result.
Monitor ingestion health
Use Ingestion Monitoring for authenticated Prometheus scrapes, queue and write metrics, and a recovery checklist when accepted data is not appearing. Pending in-memory data is not part of a database backup.