Docs
Sentry Error Monitoring
Sentry automatically catches errors in our services and alerts the engineering team. It works together with Kubernetes: Sentry reports the problem, and Kubernetes protects customers from bad releases. See Kubernetes (EKS) overview.
Together with Kubernetes health checks, Sentry helps engineering detect failures quickly and roll back unsafe deploys — keeping customer-facing disruption low while customer data remains on secured RDS.
- Catches errors automatically, with the full stack trace
- Shows which release caused each error
- Alerts engineers right away
- Set up once, then copied to every new service
Why we use Sentry
Errors and bugs will always happen. We want to find them before customers do. Sentry helps us:
- Detect errors automatically.
- Report them to engineers instantly.
- Trace each error to the exact version that caused it.
- Reduce support tickets about outages, so engineers spend less time telling customers when things will be fixed.
Settings (V1)
| Variable | What it does | Value |
|---|---|---|
SENTRY_BACKEND_DSN |
Connects the service to our new Sentry project | <new DSN> |
SENTRY_ENV |
Separates production and staging errors | production |
SENTRY_RELEASE |
Tracks which version is running | v1.0.0 |
Store the DSN in a Kubernetes Secret.
Setup steps
-
Create a new Sentry project and copy its DSN.
- Save the DSN in a Kubernetes Secret.
- Set
SENTRY_ENVandSENTRY_RELEASE. - Copy the existing Sentry code into the new service, then update the DSN, service name, and environment tag.
- Deploy and check that events show up in Sentry.
