💂 Sentry

Updated at 2024-02-15 04:03

Sentry is a error tracking and monitoring service.

It has a generous free tier.

I get to set up Sentry couple of times a year, I keep main concepts here.


The top organizational unit (duh), usually the company.



The main way to manage access.

dev (all developers, a good initial team)


Project is a collection of events, issues, releases and transactions.

Do not have a single project for all services. It will become a mess.

Do not split projects by environment like production vs. development. Sentry has project environments for that.

Project scoping:

  • create a separate project for each repo, but...
  • if a repo has multiple running services, split them into projects
  • if a repo has separated backend and frontend, split them into projects


DSN (Data Source Name) key tells the Sentry SDK where to send events.


DSN is usually stored in environment variables.


Release versions must be unique across all projects in your organization. This value can be the git SHA, or a product identifier with a semantic version.



Environment is a max 64 characters tag that you can use to filter resources.

development, staging, production.

Setting environment is important as performance bottlenecks, and many errors will be different locally, on small staging setup and on the cloud.

you usually have Sentry off locally though

If you deploy to multiple production-like sites, you can use separate environment for each. This is good if they have different release cycles.

production-us, production-eu

Error Tracking

When your application throws / logs an error, it sends an error event to Sentry.

You can also manually record errors.

By default, you get an email notification for each new error.

Performance Monitoring

Transactions is the main performance feature.

A transaction represents a single instance of an activity you want to measure or track, like a HTTP request, database query, or an asynchronous task.

You set it up with a low sampling rate to check later if performance becomes an issue.


free tier:
-  5,000 error events per month
- 10,000 performance units per month

Each recorded error event uses 1 event quota.

Breadcumbs do not count towards the event quota.

A transaction uses one performance unit and a transaction with profiling uses 1.3 performance units.

If you hit error quota, reduce logging level of frequent events.

or, you know, fix those errors 🛠️

If you hit performance quota, reduce transaction sampling rate.

0.1 in production is a good start, but depends on your traffic

Data Scrubbing

Remember to check that both your error events and transactions hide all sensitive data and secrets. Especially double-check cookies you record.

You can either not send the cookies (depends on your Sentry SDK and language) or use "Advanced Data Scrubbing" feature in organization / project.

[Mask] [Anything] from [$http.cookies.My-Access-Token]

Job Monitoring / Cron Jobs

You can also use Sentry to monitor scheduled tasks.

It's nice to get notified if a scheduled task fails to run on schedule.