An exception is not a log line

Your application raised a NoMethodError in production. What happens next depends entirely on which tool receives it.

In the log aggregator it becomes an event with a backtrace in a field, sitting among a million other lines. Someone finds it when they go looking, which they do after a user complains, which is after it has been happening for three days.

Error tracking is the tool for that gap. It receives exceptions, groups the identical ones together, counts them, tells you which are new, and notifies someone the first time each one happens.

flowchart TB
  E["Exception raised"] --> L["Log aggregator: one event among millions"]
  E --> S["Error tracker: grouped, counted, ranked"]
  L --> F["found when someone looks"]
  S --> N["notified the first time it happens"]
  S --> C["is it new? is it worse? how many people?"]

What grouping buys

One bug produces one exception per occurrence. If a background job fails a thousand times overnight, a log aggregator has a thousand events and an error tracker has one issue with a count of 1,000.

That is the whole difference, and it changes what you can ask:

• Is this new, or has it been happening for a month?
• How many distinct users hit it?
• Did it start at the deploy on Tuesday?
• Is it getting worse?

None of these are answerable from a stream of individual events without aggregation you would have to build. Error tracking is that aggregation, with a Rails-shaped opinion attached.

Where it sits

This is the fourth observability tool in this series, and the boundaries between them matter more than the tools:

The overlaps are real and not wasteful. Your error rate metric says 2% of requests fail; the error tracker says those failures are three distinct bugs, one of which is new since this morning. The metric alerts, the tracker tells you what to fix.

What arrives with an exception

An error tracker captures far more than the exception itself, and that context is most of its value:

• The exception and its backtrace, with your application frames distinguished from gem frames.
• The request: URL, method, parameters, headers.
• The user, if you tell it who they are.
• The release, so an issue can be tied to a deploy.
• Breadcrumbs: the trail of events leading up to the failure, such as queries run, requests made and log lines written.

Breadcrumbs are the part that surprises people the first time. A NoMethodError on nil tells you nothing on its own; the same error with the last five queries and the parameters that produced it is usually enough to reproduce without asking the user anything.

What this course covers

1. An exception is not a log line (this lesson).
2. Installing and configuring Sentry.
3. Grouping, fingerprints and noise.
4. Context: making an error reproducible.
5. Triage: what to do with a thousand issues.
6. Incident response.
7. Putting it together: error tracking for this application.

The examples use Sentry because it is the common choice for Rails and because its configuration names the concepts clearly. Everything transfers: the tools differ in interface and pricing, not in what they do.

Key takeaways

• An error tracker groups identical exceptions into one counted issue; a log aggregator keeps them as separate events.
• Grouping is what makes "is this new?", "is it worse?" and "how many users?" answerable at all.
• Metrics alert that something is wrong; error tracking says which distinct bugs are behind it.
• Captured context (request, user, release and breadcrumbs) is usually what makes an error reproducible.