Sentry: see production errors with readable traces, safe payloads and one alert you can trust

What an error tracker needs to be useful

An error tracker is only as good as four things around it. The stack traces must be readable, which for browser code means source maps that match the deployed files. Each event must carry a release and an environment, so you can tell which version failed and where. The payload must be safe, with passwords, tokens and personal data removed before it leaves your application. And the alert must be quiet enough that someone reads it. Sentry's documentation covers each, and the guides here go through them in the order a team usually meets them.

• Readable traces: Debug IDs and uploaded maps for a production build.
• Release and environment: environment defaults to production; if release is not set the SDK tries to infer one, but Sentry recommends setting it by hand.
• Safe payload: filter in the SDK with before_send, and use server-side rules as a second layer.
• A quiet alert: filters and a channel the team actually watches.

Defaults to check before launch

The Python options reference gives the defaults that matter. The environment is production unless you set it, so a staging deployment that forgets to set it reports as production. The release is not required: if you do not set it, the SDK tries to configure one itself, from the SENTRY_RELEASE environment variable or an inferred git commit SHA. The documentation still recommends setting it manually, to guarantee that the release is in sync with your deploy integrations. Errors are sampled at 1.0 by default, so every error is sent until you lower it, and at lower values events are picked at random, which means a rare error can be missed. Tracing is off unless you set a sample rate. The send_default_pii option defaults to None, and the sensitive-data page says it will be phased out in favour of a newer option, so read the page for your SDK version.

• Set environment and release explicitly in every deployment.
• Decide on sampling deliberately and write down why.

What an error tracker does not do

It does not fix the errors it finds, rank them for your business or tell you who should respond. It cannot capture an error from a process that dies before it can send, or from a network path that is blocked, and sampling can drop events. It is not a log platform, an uptime check or a performance monitor, although the same vendor may sell those. Treat it as one view of production, and write down what it does not cover. Whether you may send error data to a third party at all is a decision for you under your own policies, and we do not give legal advice.

• Keep a short list of what the tracker does not cover, next to the settings summary.

Ask for the right work

Error tracking set up on one application, with readable traces, release and environment, filtered fields and one alert, proven by a deliberate test error, is priced from a published test price of £595 and accepted by the events and the notification you can inspect. Structured logs with a request ID and one alert for one service start from £695. The project that joins the two, so one test failure can be followed from the alert to the error to the log lines, starts from £1,650 after a proposal. Prices are untested hypotheses, nothing is charged until terms are agreed in writing, and we have not delivered these jobs for a client before. You create and hold the tracker account and tokens. Send the stack in general terms and where notifications should go, never tokens or event data.