Skip to content

Features

Know who an error actually affected

One error thrown a thousand times by a single bot and one error hitting a thousand customers are different problems. Identify users in the SDK and Buglapse counts and lists the people behind every issue.

All Buglapse features

User tracking

People, not just event counts

  • Affected users per issue

    Every issue shows the number of distinct users it touched, next to the number of events — the first thing to look at when choosing what to fix.

  • A page for every user

    Open a user to see their recent errors and traces. When a customer writes to support, you can see what went wrong for them before asking.

  • Search by user

    Use the user filter in search to find everything a specific account ran into.

  • You decide what is sent

    Only the fields you pass to the SDK are stored. Secrets are masked on the server, and IP addresses can be hashed on plans with advanced data scrubbing.

How it works

Identify users in one call

  1. 1

    Call setUser after login

    Pass an id, and optionally an email, a username or a name. Every field is optional.

  2. 2

    Add fields as you learn them

    Calling setUser again merges into what is already known instead of replacing it, so an email can be added later.

  3. 3

    See users in the dashboard

    Issues show their affected users, and the Users page lists everyone the project has seen, most recently active first.

auth.ts
import { setUser } from '@buglapse/browser'

setUser({ id: user.id, email: user.email })

In detail

How users are identified

Matching events to a person

From the moment setUser is called, the user is attached to every event sent afterwards: errors, logs, spans and sessions. Buglapse matches events to the same person by id first, then by email. Extra fields you pass, such as a plan or a company name, are kept and shown on the event. In Node.js a user can be set for a single request, so concurrent requests never mix their users up.

Privacy controls

Server-side scrubbing masks passwords, tokens, card numbers and keys in every event before it is stored, whichever SDK sent it. A project can add its own sensitive field names and mark fields that must never be scrubbed. The user id, email, username and name are the identifiers Buglapse relies on and are kept as sent — so pass an internal id rather than an email if you would rather not store personal data.

On each plan

Compare all plans
On each plan
Free Pro Team
Errors & issues14 days30 days90 days
Custom data scrubbing rules, IP hashingNot includedIncludedIncluded

FAQ

Common questions

Still have questions?

Drop us a line — we'll help with setup, plans or self-hosting.

Contact us

or email hello@buglapse.com

What about visitors who are not logged in?
If setUser is never called, events are attributed by the request IP address, so anonymous visitors are still counted as separate users.
Which user fields can I send?
An id, an email, a username and a name are used for matching and display. Any other field is preserved and shown on the event.
Can I avoid storing personal data?
Yes. Send only an internal id, turn on IP hashing where your plan includes it, and add your own field names to the scrubbing rules of the project.

See also

Error tracking

Every error grouped into one issue with a readable stack trace, breadcrumbs, the steps to the error and the affected users.

Learn more: Error tracking

Ready to see what's happening in your app?

Create a project on the free plan and send your first event in a couple of minutes.

Still have questions? Email hello@buglapse.com