When you hear about production errors from customers: build the view in this order

1. Capture the exceptions at all

The first gap is that errors reach no one except through the server's own log or a customer complaint. Connect an error tracker to one application so unhandled exceptions are captured, set the environment and release explicitly and prove it with a deliberate test error from a production-style build in a non-production environment. Do not wait for a real failure to find out whether capture works. This is the smallest useful step, and it is a bounded job for one application.

• A test error appears in the tracker with the release and environment you set.
• The application still serves requests when the tracker is unreachable.

2. Make the traces readable

If the traces show minified code, capture is not yet useful. Check that the build injects identifiers, that the maps are uploaded in the same production build and before errors occur, and that the files served carry the matching identifier. The source-maps guide goes through the order of checks. Prove readability with the same test error: it should show your file and line.

• Compare the identifier in the served file with the one the tracker expects.

3. Make the payload safe before launch

An error event can carry request details, user fields and local variables. Decide what must never leave the application, filter it at the source with the SDK hook, and test the filter with invented secrets in the request, in an exception message and in a local variable. Server-side rules are a second layer and apply only to new events. Whether you may send error data to a third party at all is your decision under your own policies.

• Test with invented values, never real ones.

4. Add one alert someone reads

An alert that fires on everything is muted within a week. Start with one rule, for new issues in the production environment, sent to the one channel the team watches. Check how events group into issues, because one fault that appears as many issues defeats a new-issue alert. The alert and grouping guide covers both, including merging and fingerprints.

• Test the rule with a deliberate error, and check that a repeat does not create a second issue.

5. Join the alert to the log lines

When an alert fires, the next question is what else that request did. That needs structured logs and a request identifier on every line, and the same identifier attached to the error event. The logging guide shows how to set it where the request starts and how to test two requests at once. The project that joins the two proves that a person who did not build it can follow one test failure from the alert to the log lines.

• Test with concurrent requests to catch identifiers that cross.

Paid routes, by size

Error tracking on one application, with readable traces, filtering and one alert, has a published test price of £595. Structured logs with a request ID and one alert for one service start from £695 after a quote. The joined project starts from £1,650 after a proposal. Prices are untested hypotheses, nothing is charged before sign-off on a fixed job, we have not delivered these jobs for a client, and none promises that every error is captured, a response time or availability. You hold the accounts, tokens and production values. Send the stack in general terms and where notifications should go, never tokens or event data.