Sentry access & error tracking

How Sentry catches application errors, how organisation roles and DSNs work, and how to keep personal data out of your error reports.

Sentry records errors and performance problems from a running application — the stack trace, the browser or server involved, and what the user was doing. It's the difference between "a customer says checkout is broken" and knowing exactly which line failed, how often, and since when.

Quick summary

Invite people from Settings → Members and assign the lowest role that works. Each project has a DSN — the identifier the app sends errors to. A DSN is not a password, but it isn't a secret either. The setting that matters most is data scrubbing: error reports can capture personal data unless you configure them not to.

How Sentry is organised

Organisation — the billing and access boundary.

Team — a group of people, used to control which projects they see.

Project — one application or service, with its own DSN and alert rules.

Issue — many occurrences of the same error, grouped so one broken function doesn't produce ten thousand separate notifications.

Roles

Role	Typical capability
Owner	Everything, including billing and deleting the organisation
Manager	Manage all teams and projects, and manage members
Admin	Manage projects, add and remove teams, edit global integrations
Member	View most data, and act on issues (assign, resolve)
Billing	Manage payment, subscription, and legal and compliance details

Two wrinkles worth knowing. On Business and Enterprise plans the Admin role can no longer be assigned to new people — it has been replaced by a team-level Admin role, and anyone who already holds Admin keeps it. Those finer team-level roles (Team Contributor and Team Admin) only exist on Business and Enterprise plans.

A project can only be reached by the teams it belongs to, so a contractor on one service needn't see errors from the rest of your estate. That only holds if you turn Open Membership off in Settings → General Settings: it's on by default, which lets any member join any team by themselves.

The DSN

The DSN is the endpoint your application sends events to. For a browser application it is visible in the page source — unavoidably, since the browser must know where to send errors.

A public DSN is normal

A DSN allows sending events, not reading them. Nobody can read your errors with it. Sentry's own position is that DSNs are safe to keep public. The realistic abuse is someone flooding your project with junk events and consuming your quota. You can create, rate-limit, rotate and revoke keys under Project Settings → Client Keys (DSN) — though per-key rate limits themselves are only available on Sentry's Business and Enterprise plans.

Keeping personal data out

This is the setting most often overlooked. Error reports naturally capture request bodies, headers, cookies, and local variables — which can mean passwords, tokens, card details, or health information landing in a third-party service.

Check data scrubbing is still on. Sentry enables it by default and recommends leaving it that way. It strips values that look like card numbers, plus anything whose name or content matches its built-in list (password, secret, passwd, api_key, apikey, auth, credentials, mysql_pwd, privatekey, private_key, token, bearer). The settings are under Security & Privacy, in the "Data Scrubbing" section, at either organisation or project level.

Add your own field names to "Additional Sensitive Fields", and use Advanced Data Scrubbing for anything that needs a rule rather than a name. The built-in list doesn't know your domain-specific fields.

Stop IP addresses being stored if you don't need them — they're personal data in most privacy regimes. Note that Sentry still derives rough location from the IP even with that setting on; removing the location too takes an Advanced Data Scrubbing rule.

Review what's actually stored. Open a real captured event and read it. This is the only reliable way to find out what you're sending.

Know how long it's kept. Retention comes with your Sentry plan rather than being something you set — errors are kept 30 days on the Developer plan and 90 days on Team, Business and Enterprise. Check Sentry's current figures if a retention limit matters to your obligations.

Error tracking is a data processor

If your application handles personal data, your error tracker probably receives some of it. That makes it a processor under privacy law, needing a data processing agreement and a mention in your privacy notice. For regulated data, scrub aggressively. See data privacy basics and GDPR basics.

Getting value from it

Alert on new and regressed issues, not on every event, or the alerts get ignored.
Route alerts to a channel people actually watch.
Tag releases so you can see which deploy introduced a problem.
Triage regularly. An issue list nobody reads is the same as no error tracking.

Common questions

How is this different from server logs?

Logs are a flat stream you have to search, usually with short retention. Sentry groups identical errors, tracks how often each occurs and who's affected, tells you which release introduced it, and notifies you. Logs tell you what happened; error tracking tells you what's wrong.

Will it slow the application down?

Error capture is cheap, and Sentry's SDKs send 100% of error events by default. Tracing is the part with real cost: capturing a single trace involves minimal overhead, but doing it on every page load or API request can add noticeable load, which is why Sentry has you set a sample rate for it rather than capturing every transaction.

We're getting flooded with the same error.

Sentry groups occurrences into one issue, so the count rises rather than the list. If a known and harmless error is drowning out real problems, you can drop it in the SDK before it's sent, or switch on a filter under Project Settings → Inbound Filters — which can match on error message, release, IP address and a list of common noise sources. Either way it saves quota: filtered events don't consume it.

Who should own the Sentry organisation?

You. It contains diagnostic data about your application and, potentially, fragments of your users' data. We work inside your organisation as members.

Need a hand?

If you're stuck, email support@chykalophia.com and we'll help. Include your website address and a screenshot if you can.