Your app breaks for a user and you hear about it last. Error monitoring catches crashes and exceptions as they happen, groups them, and tells you what broke and where, so you can fix it before more users hit it.
| Item | Value |
|---|---|
| SDK setup size (Sentry’s quickstart pitch) | five lines |
| Install route in Sentry’s wizard examples | one command |
| Sentry’s tracing sample-rate example | 1.0 = 100% of transactions |
| Initialization order in Sentry’s React example | first import in the app entry point |
| Signals Sentry says are connected by the same trace | errors, logs, replays, spans, profiles, metrics |
These figures come from vendor pages by Sentry and OneUptime. Vendor details can change, so check the source before you rely on them.
What error monitoring does and why it matters
Error monitoring is the practice of automatically capturing the exceptions, crashes and failed operations in running software and turning each one into a report you can act on. Instead of waiting for a customer to write in, your code reports the failure the moment it happens. The goal is a short path from “something broke” to “this line, in this release”.
The report matters more than the alert. A stack trace, the release it came from and the request involved give you a place to start looking instead of a vague complaint. Without that detail, even a fast notification leaves you guessing.
A useful error report usually answers these questions:
- What failed: the exception type and its message.
- Where it failed: the stack trace, down to file and line.
- Which build and environment it came from: release, commit, production or staging.
- Who or what was affected: the request, the user or the background job.
- What happened just before: recent logs, clicks or calls leading up to the failure.
Teams use the words exception tracking, crash reporting and error monitoring loosely, and the explainer on what is exception tracking sorts out where they overlap. In practice the terms point at the same job: collect failures, keep the context, and make them easy to triage.
Error monitoring rarely lives alone. Sentry’s product menu, for example, lists error monitoring next to logs, session replay, metrics, tracing, profiling, cron monitoring and uptime monitoring, according to the Sentry page. OneUptime’s documentation groups exception tracking in the same way, placing it beside the logs, traces and metrics explorers, as the OneUptime docs show.
Logs still matter, and the comparison of error monitoring vs logging shows why most teams keep both. Logs record what your code chose to say. An error monitor records what went wrong whether your code said anything or not.
The payoff shows up in four places:
- Detection: you learn about a failure from a report, not from a support thread.
- Diagnosis: the stack trace and context shorten the hunt for the cause.
- Release safety: a new error spike after a deploy points straight at the change.
- Prioritisation: counts and affected users help you decide what to fix first.
How an error monitor gets into your code
Most monitors work through an SDK: a small library you add to the app, configure with a project key, and let hook into the runtime’s error handlers. Sentry pitches its setup as “Monitor in five lines” and says there are no agents to install, per its product page. That is a vendor claim, but it matches how SDK-based tools generally behave: a package, an init call, done.
The install step is usually a single package manager command. Sentry’s page shows “pip install –upgrade sentry-sdk” for Python and “npm install @sentry/node” for Node, and it also shows a wizard that handles setup for frameworks such as Next.js with one command.
A sensible first setup follows these steps:
- Add the SDK package for your language or framework.
- Initialise it with your project key as early as possible in startup.
- Set the environment name and the release identifier so reports are labelled.
- Trigger a deliberate test error from a safe place.
- Check that the error arrives with a readable stack trace and the right labels.
Order matters in step two. Sentry’s React example carries the comment “Sentry initialization should be imported first!”, and its .NET example says to initialize the SDK as early as possible, such as in the Main method. An error thrown before the monitor starts has nobody listening, so late initialization means silent gaps.
The same .NET example sets a debug option the first time you configure it, to see what the SDK is doing. A verbose mode like that is handy while you confirm events are flowing. Treat it as a setup aid and decide deliberately whether it belongs in production.
Browser and mobile apps follow the same pattern with a different runtime underneath. The SDK wraps global error handlers, captures what it can, and ships events to a collector over the network. Backend services do the same through middleware or framework hooks.
The context that makes an error fixable
A bare exception message is rarely enough. Sentry’s page describes wanting to “map every incident to the release, PR, and owner” automatically, which captures the idea well: each error should lead to the change that introduced it and the person who can fix it.
The context worth attaching to each event includes:
- Release and commit: so you can tell a regression from an old problem.
- Environment: so staging noise never mixes with production.
- Owner or team: so the report lands with someone who can act on it.
- User or session reference: so you can reproduce the path, without storing more personal data than you need.
- Related logs and traces: so you can see the surrounding activity.
Connected signals make this much easier. Sentry says errors, logs, replays, spans, profiles and metrics are all connected by the same trace, so you can move from an exception to the slow request or session around it. Even if you use a different tool, the principle holds: an error that links to its trace is faster to understand than one that stands alone.
That same context is what any assisted debugging depends on. Sentry describes its AI debugger, Seer, as using logs, commits, traces and the stack trace. Whether a person or a tool reads the report, the quality of the answer follows the quality of the context.
Readable stack traces for front-end code
Front-end code is usually minified before it ships, so a raw stack trace points at a line in a bundle nobody wrote. A source map translates those positions back to your original files and lines. OneUptime’s documentation lists Source Maps among its observability topics, which reflects how common this need is.
The guide to source maps error tracking explains why the maps must match each release you deploy. If they do not, your traces look right but point at the wrong code.
One bug, many events
A single bug can fire many times as users hit the same path. If every event became its own ticket, the list would be unusable. Monitors therefore combine events that share a cause into one issue, and the details of that process are covered in error grouping and deduplication.
Grouping is never perfect. Sometimes unrelated errors merge, and sometimes one bug splits into several issues. Review your grouping rules when counts look suspiciously high or suspiciously low.
How do you track errors in production?
Production differs from development in ways that change the setup. You have real traffic, real privacy obligations and a bill that grows with volume. The walkthrough on how to track errors in production goes step by step, and the points below are the core of it.
- Label every event with an environment and a release.
- Filter known noise, such as bots, browser extensions and expected network failures.
- Scrub sensitive values before events leave your servers.
- Decide how long to keep data and how much you will ingest.
- Assign an owner to each service so reports have a destination.
Vendor documentation treats these controls as first-class features. OneUptime’s docs list drop filters and scrub rules, data retention, telemetry usage and ingestion budgets as separate topics, according to its documentation menu. If a tool you evaluate has no answer to volume, retention and privacy, expect trouble later.
Sampling is the other lever. Sentry’s Python sample sets “traces_sample_rate” to 1.0 to capture 100% of transactions for tracing, and adds a recommendation to adjust that value in production, as the Sentry page shows. Note that this setting applies to performance traces, not to error events. Capturing everything is a fine default while you learn, but a busy service needs a deliberate rate.
Releases deserve special care. OneUptime’s docs include a topic on deploys and changes, which fits the habit of marking each deploy in your monitor. With deploys marked, a jump in errors lines up with the change that caused it, and you can see at a glance whether a fix really worked.
What to do with errors you cannot fix right away
Some errors come from third-party scripts, flaky networks or old clients. You will not fix all of them, and you do not need to see them forever. Mark them as ignored or low priority with a written reason, so the next person does not rediscover the same noise.
Alerts without the noise
An alert that fires for every event teaches your team to ignore alerts. Better rules fire on issues, not events, and only when someone must act. The guide on how to set up error alerts covers the mechanics, and the page on how to reduce alert fatigue explains what happens when the rules are too loose.
A practical set of alert rules starts like this:
- Notify when a brand-new issue appears in production.
- Notify when a previously resolved issue comes back after a release.
- Notify when the rate of an issue climbs well above its normal level.
- Route each alert to the owning team’s channel, not a shared firehose.
- Review rules after each incident and tighten the ones that cried wolf.
Monitoring platforms build this logic in different ways. OneUptime’s docs list alert states and severities, alert episodes and grouping rules, and alert rules and settings as distinct topics, per the OneUptime documentation. Grouping related alerts into an episode is one way to turn a burst of notifications into a single page.
Where the alert goes matters as much as when it fires. Sentry’s page mentions GitHub, Slack, Jira and Linear as places its context reaches. Sending an alert to the chat channel your team already watches, with a link to the issue, beats an email nobody opens.
Finally, give every alert an outcome. Either someone fixes the cause, someone tunes the rule, or someone deletes it. An alert that stays and changes nothing is a cost you pay on every page.
Error monitoring next to APM, logs and debugging
Error monitoring answers “what broke?” Application performance monitoring answers “what is slow?” The comparison of apm vs error monitoring looks at where the two overlap and where they do not.
The line is getting blurry, because products bundle both. Sentry’s page talks about catching slow queries and request timeouts in the same platform as errors, and OneUptime’s docs list traces and profiling alongside exceptions. You can start with errors and add performance data later without changing tools.
Here is how the main signals divide the work:
- Error monitoring: unexpected failures, with stack traces and release context.
- Logs: the narrative your code writes about what it is doing.
- Traces and APM: the path and timing of a request through your services.
- Session replay: what the user saw and did before the failure.
A monitor tells you where to look. It does not replace the skill of working out why. The broader guide to debugging techniques covers the habits that turn a report into a fix, such as reproducing the issue, narrowing the cause and checking the fix against the original failure.
Framework details matter too. If your stack is Ruby on Rails, the guide to ruby on rails debugging shows how these ideas apply to that framework’s conventions.
A short checklist to get started
- Pick a tool that supports your language and framework.
- Install the SDK and initialise it before anything else runs.
- Label events with environment and release.
- Upload source maps if you ship minified code.
- Scrub sensitive fields and set sensible retention.
- Start with a few alert rules routed to owners.
- Review the issue list weekly and close the loop on each alert.
Adding a monitor does not make errors disappear. It makes them visible and ordered, which is what lets a team fix the right ones. Revisit the setup whenever your architecture, traffic or team changes.
Frequently asked questions
What is error monitoring?
Show answer
Error monitoring is the automatic capture of exceptions and crashes in running software, with enough context to diagnose them. Each report usually includes a stack trace, the release and environment, and details about the request or user involved.
Do I still need logs if I use an error monitor?
Show answer
Yes. Logs record what your code chooses to say, including normal activity, while an error monitor records unexpected failures even when nothing was logged. Many platforms connect the two, so you can open the logs around an error.
Should I capture every error?
Show answer
Not forever. Capturing everything is useful while you learn what your app does, but busy services benefit from filters, sampling and retention limits. Keep the errors that signal real user impact and ignore the noise on purpose.
Why do my stack traces look unreadable?
Show answer
Minified front-end code points at bundle positions, not your source files. Uploading source maps for each release lets the monitor translate those positions into original file names and lines.
How do I avoid being flooded with alerts?
Show answer
Alert on issues instead of single events, and notify only for new issues, regressions and meaningful spikes. Route alerts to the owning team and review the rules after every incident.
