User Debugging

Follow an application user through their errors, logs, traces, and page loads while keeping the same investigation filters.

Start with an affected user#

1. Open an issue and find the current event's user context.
2. Choose Issues, Traces, or Logs in that user card to investigate the same identity on another page.
3. Keep the project, environment, and time range focused on the reported problem using the shared filters.
4. Open Performance > Browser to inspect that user's captured page loads, or Queries, Caches, and Jobs to investigate work inside their transactions.

You can also open the user selector on a telemetry page and search by identity, username, email, or name. It offers recent users from the selected projects. Search is case-insensitive, but selecting a result filters telemetry by its exact identity, including case.

With a user selected, Transactions shows individual traces instead of grouped endpoint statistics, and Browser shows individual page loads with their available Web Vitals. Transaction operation and release controls are hidden in this mode. Clear the user chip to return to aggregate views.

A log's Trace link opens the matching stored transaction when one is available. The selected user's span views match the identity on the containing transaction, so attach user context to the transaction rather than relying on a custom span attribute.

How Tindra identifies a user#

These are people using your application, separate from the team accounts that sign in to Tindra. Sending user context does not create a Tindra login or consume an additional team seat.

Tindra takes the first nonempty, unfiltered value in this order:

Surrounding whitespace is removed and numeric IDs become strings. IP addresses do not establish user identity. For structured logs, the corresponding attributes are user.id, user.username, user.email, and user.name. A custom attribute such as userId does not substitute for user.id.

User records are indexed per project, but the selected identity is applied across all selected projects. Use the same stable identity in your frontend and backend to follow someone across both. An event with id=customer-42 and a log with only an email will not automatically match, even if they describe the same person. Conversely, unrelated applications that both use id=42 can match together when both projects are selected.

Attach and clear SDK context#

Set the authenticated user's ID before capturing their telemetry, and clear it on logout or when a reused request or job context stops belonging to that user. Keep server-side context isolated to the current request or job so concurrent work cannot inherit another person's identity.

Use your SDK's user API instead of placing the ID in arbitrary tags or extra data. The language guides include examples:

• Laravel and PHP
• JavaScript and Node.js
• Python, Ruby, and Go

An opaque ID is enough; email, name, and IP address are optional. Verify that your SDK version carries scoped user context into each signal you enable, especially structured logs.

Missing users or activity#

The picker is scoped by project, but its recent-user index is not limited to the selected time range or environment. A person can therefore appear in the picker while having no matching results in the current view.

If activity is missing, check the selected projects, time, and environment, then inspect the stored event or log attributes for the actual identity. Check tracing and logging setup and sampling as well. A captured error does not guarantee a transaction or log was also sent, and older records may lack user context that the SDK never supplied.

PII scrubbing runs before user indexing and can remove or alter identity fields, including IDs. [Filtered] is not a usable identity. If an ID is removed while a username remains, that username becomes the fallback identity. Use consistent privacy rules across related projects, and do not assume the user index anonymizes values that remain after scrubbing.