Sentry

Visit Website

Introduction

Sentry captures exceptions, groups the ones that share a stack trace, and shows the release, the user, and the breadcrumbs that led up to the failure. SDKs exist for browsers, mobile apps, and most backend languages. The same project can record traces and, on supported SDKs, session replays and cron check-ins. It is an observability tool that sits next to tests: CI can create a release, and production tells you which release started throwing.

The server source is published at getsentry/sentry. Current server releases use Sentry’s Functional Source License, which converts to Apache-2.0 after a delay. That is source-available, not a “clone it and sell it tomorrow” grant. Most SDKs are Apache-2.0 or MIT. Almost everyone uses sentry.io rather than operating the server. Self-hosting is documented and heavy.

Features

1. Error grouping: Events with the same stack become one issue, with a count, a first-seen release, and a last-seen time. You triage the issue, not every event.
2. SDKs: JavaScript, Python, Java, .NET, Go, Ruby, PHP, mobile, and game engines. The SDK uploads source maps or debug files so frames are de-minified.
3. Releases and commits: A release name ties an issue to the deploy. Suspect commits are only as good as the release metadata you send.
4. Tracing: Spans link a slow request across services that share a trace id. This overlaps APM tools; Sentry’s strength is still the error, with the trace as context.
5. Session replay and breadcrumbs: Frontend SDKs can record what happened before the exception, including console and network breadcrumbs. Replay has its own quota.
6. Alerts: Email and chat alerts on a new issue, a spike, or a threshold. The free developer plan’s alert channel is email.
7. Cron and uptime-style monitors: A missed check-in opens an issue. That is closer to a heartbeat than to a browser synthetic.
8. Test and CI hooks: A failing end-to-end job can report to Sentry, and a release can be marked from the same pipeline that ran the tests. Sentry does not run the tests.

Pros

1. The issue list is actionable: Grouping plus “resolved in the next release” matches how teams already talk about bugs.
2. SDK coverage is wide: One vendor can take the browser error and the API exception without a custom collector.
3. Source maps are a solved path: Upload them in CI and stack traces point at TypeScript lines instead of a bundle.
4. Developer plan is actually free: One user, error monitoring, tracing, and email alerts, with no credit card. It is a single-seat plan, not a team plan.
5. SDKs are open source: You can read what is collected before you ship the SDK into a privacy-sensitive app.

Cons

1. Quotas are the product: Errors, spans, replays, and attachments are metered. A chatty captureException in a loop becomes a bill, or dropped events, depending on plan.
2. Self-hosting is a platform: The server expects Postgres, Redis, object storage, and several workers. sentry.io exists because that stack is not a side task.
3. License of the server: FSL is not the same as the MIT SDKs. Read the license if you intend to run a modified server as a service for others.
4. Noise without ownership: An unfiltered issue stream trains people to ignore Sentry. Inbound filters, sample rates, and “resolved” discipline are part of the install.
5. Not a test tool: It will not click through a checkout. It tells you the checkout threw after you shipped. Pair it with the runner that covers that path before release.

Usage and Links (Example)

Browser:

npm install @sentry/browser

import * as Sentry from "@sentry/browser";

Sentry.init({
  dsn: "https://[email protected]/0",
  environment: "production",
  release: "[email protected]",
});

Use the DSN from the project settings. Send release from CI so the issue names the deploy. For source maps, call the Sentry CLI or the bundler plugin in the same job that builds the assets. Do not put a secret auth token in the browser bundle; the DSN is a public write key, the auth token is not.

Resources:

• Sentry website
• Sentry docs
• Pricing
• GitHub: getsentry/sentry

Pricing

From sentry.io/pricing:

1. Developer: $0. One user. Error monitoring and tracing, email alerts, a limited number of custom dashboards, and MCP access are listed on the plan. Data volume is capped; the live quota table is on the pricing page and changes.
2. Team: Starts at $26 per month when billed annually with the default prepaid data. Adds seats and more prepaid errors, spans, and replays. Month-to-month costs more than the annual figure.
3. Business and Enterprise: Higher data, more seats, and support. Business is not given a single number on the snippet of the pricing page this entry used; read the calculator before you quote it internally.
4. Self-hosted: No Sentry license fee under the Functional Source License terms, and a large infrastructure bill if you run it yourself.

Prepaid data you do not use is the other failure mode: the Team plan’s $26 assumes a default bundle. Extra events are the line that moves the invoice.

Recommended for?

1. Application teams who need a shared inbox of production exceptions with stack traces.
2. Frontend releases that can upload source maps and want the error tied to a commit.
3. A solo project, on the free Developer plan, as long as one seat is enough.
4. Not as a substitute for tests. Use Sentry to see what testing missed, and keep the test runner in CI.

Conclusion

Sentry is the default error inbox for a reason: grouping, releases, and SDKs that are easy to drop in. Start on the free Developer plan if one seat is enough, and treat the Team plan’s $26 as a prepaid-data bundle rather than an all-you-can-eat seat. Sample noisy events before they sample your budget. The server is source-available under FSL; the practical product for most teams is sentry.io.