Monitoring & Observability (Tools)

In one line: Sentry for errors, PostHog for analytics, Better Stack for uptime + logs. Reach for Datadog / Honeycomb / OpenTelemetry when you outgrow the basics.

In plain English

This page is the tools for observability. For the concepts (logs vs. metrics vs. traces, SLOs, alerting), see Chapter 3 Phase 11.

Errors

Tool	Notes
Sentry	Default for almost everyone. Free tier is generous.

Sentry catches exceptions, deduplicates them by stack trace, alerts you on new errors, and shows you which release and which users were affected.

Logs

Tool	Notes
Datadog	Enterprise.
Better Stack / Axiom / Logtail	Modern, developer-friendly.
Grafana Loki	Open-source, self-host.

Metrics

Tool	Notes
Datadog	Enterprise.
Grafana + Prometheus	Open-source, self-host. Dominant standard.

Traces

Tool	Notes
Datadog APM	Enterprise.
Honeycomb	Excellent for distributed systems.
Jaeger / Tempo	Open-source.

Standard

• OpenTelemetry (OTel) — Vendor-neutral instrumentation. Send to any backend.

Product analytics

Tool	Notes
PostHog	All-in-one, open-source. Includes analytics, replay, flags.
Mixpanel / Amplitude	Mature.

Feature flags

Tool	Notes
PostHog	Bundled.
Statsig	Strong on experimentation.
LaunchDarkly	Enterprise standard.

Incident management

Tool	Notes
PagerDuty	Enterprise.
Opsgenie
Incident.io	Modern, developer-friendly.
Better Stack On-call	Bundled with Better Stack.

Highlight: the 5-minute observability stack for a beginner

Sign up for these three free tiers and you have professional-grade observability in 5 minutes:

1. Sentry — exception tracking.
2. PostHog — product analytics + feature flags.
3. Better Stack — uptime monitor + log aggregation.

Total cost: $0 for most personal projects. Setup time: 15 minutes including reading the docs. This setup will catch 95% of production issues you'll hit early on.

Common mistakes

Where people commonly trip up

• Adding Sentry only to the frontend (or only to the backend). Half your errors go missing. Wire Sentry into both the browser bundle and the server runtime; trace IDs in the SDK then link the two halves of an incident.
• Logging PII, tokens, or full request bodies. It looks helpful in dev and becomes a GDPR liability the moment it lands in your log provider. Redact before logging — most observability SDKs have a beforeSend / scrubber hook for exactly this.
• Going straight to Datadog on a new project. Datadog is excellent and expensive — and most of what makes it valuable doesn't matter until you have many services. Sentry + PostHog + Better Stack covers 95% of early needs at $0. Graduate to Datadog when your platform team can justify the line item.
• Alerting on every error. A pager that fires 30 times a day stops being a pager. Alert on user-facing impact (SLO burn, 5xx rate, queue depth), not on every individual exception Sentry catches. Errors go into a dashboard; symptoms go to PagerDuty.
• Treating logs, metrics, and traces as interchangeable. Logs are events ("user X did Y"), metrics are aggregates ("p95 latency = 200ms"), traces are causality chains ("this request touched these 5 services"). You need all three; using logs to build dashboards or metrics to find a single bug is the painful way around.
• Instrumenting with a vendor SDK instead of OpenTelemetry. Two years later, you want to switch from Datadog to Honeycomb, and now you're rewriting every dd.trace(...) call. OTel-first lets you swap backends without touching code.

Page checkpoint

Checkpoint Quiz

Did observability tools stick?

Required

What's next

→ Continue to Code Quality & Dev Tools — linters, formatters, pre-commit hooks, monorepo tools.