Error Tracking and Monitoring

Errors are inevitable. How you track and respond to them matters.

Error Tracking Systems

Sentry

Strengths: Excellent UI, easy SDK integration, good stack trace processing, free tier available
Best for: Most teams, especially those wanting quick setup
Considerations: Can become expensive at scale, source code not open source

Rollbar

Strengths: Good Ruby/Python/JS integration, collaborative features
Best for: Teams already using Rollbar or with specific language needs
Considerations: Less popular than Sentry, smaller ecosystem

BugSnag

Strengths: Good reliability, release stage tracking, feature flag integration
Best for: Enterprises, teams with specific reliability needs
Considerations: Pricing model can be complex

Choosing an Error Tracker

Consider these factors:

Language/framework support: Does the SDK exist for your stack?
Ease of setup: How quickly can you get errors flowing?
Alerting capabilities: Can you set up meaningful alerts?
Integration: Does it work with your other tools (Slack, PagerDuty, Jira)?
Cost: Free tier → enterprise pricing as you scale
Data retention: How long are errors stored?
Privacy: Does it handle PII appropriately?

Monitoring vs. Error Tracking

Monitoring

What it answers: "Is the system working?" (known knowns)

What it tracks:

System health metrics (CPU, memory, disk)
Service availability (up/down)
Performance metrics (latency, throughput)
Resource utilization

Typical tools: Prometheus + Grafana, Datadog, New Relic Infrastructure

Alert on: Known thresholds, known failure patterns

Error Tracking

What it answers: "What exactly went wrong?" (unknown unknowns)

What it tracks:

Application errors with stack traces
Error frequency and trends
Affected users/sessions
Release context (which deployment introduced the error)
User impact (how many users affected)

Typical tools: Sentry, Rollbar, BugSnag

Alert on: Error rate spikes, new error types, user-impacting errors

The Integration Pattern

Best practice: Combine monitoring and error tracking.

Dashboard shows: System health metrics (monitoring)

Alerts fire: When metrics indicate issues OR error rate spikes (both)

Error details appear: In error tracker when alerts fire

Example workflow:

Prometheus detects latency p99 exceeds threshold
Alert fires to #ops Slack channel
Team checks dashboard: CPU normal, memory normal, latency high
Team checks Sentry: New error type "DatabaseTimeoutException" appearing
Team investigates: Slow database query causing timeouts
Team resolves: Adds index, latency normalizes
Team confirms: Error rate returns to normal, alert clears

Error Severity Levels

Define severity levels so responders know urgency:

P0 (Critical): System down, significant user impact. Immediate response required.
P1 (High): Major functionality degraded, many users affected. Response within 1 hour.
P2 (Medium): Limited functionality degraded, some users affected. Response within 4 hours.
P3 (Low): Minor issue, few users affected, workaround available. Response within 24 hours.

Key: Define these with your team and stick to them. Inconsistent severity levels undermine the whole system.

The Incident Response Workflow

1. Detect

Alert fires → Team notified → Situation assessed.

2. Triage

Is this a real incident? What's the scope? What's the severity?

3. Investigate

Check dashboards, error tracker, logs. Identify root cause.

4. Resolve

Implement fix or workaround. Deploy if necessary.

5. Post-Mortem

Document: What happened? Root cause? Impact? Action items? Prevention?

Key: Post-mortems are for system improvement, not blame. Blame culture kills learning.

6. Close

Confirm resolution. Clear alerts. Update documentation if needed.

The Honest Truth

Error tracking without a response process is frustrating. Error tracking with post-mortems without blame culture is how teams improve. The goal isn't zero errors—that's impossible—but learning from errors and building more resilient systems.

Published June 1, 2026 · 9 min read