TL;DR — Use Sentry for errors. Use OpenTelemetry for traces and metrics. Pipe both into the rest of your stack (Grafana, Tempo, Loki, or a SaaS backend) without locking yourself into any single vendor. Set this up before scale, not during an incident.
What each tool is actually good at
- Sentry — error tracking with rich context. Stack traces, breadcrumbs, release tracking, alert routing, performance traces with great UX, user-impact correlation. Best-in-class developer experience for “what broke?”
- OpenTelemetry (OTel) — vendor-neutral instrumentation for traces, metrics and logs. Auto-instrumentation libraries for most language runtimes. Pipe to any compliant backend (Tempo, Honeycomb, Datadog, Dynatrace) without rewriting code.
Our minimum production stack
- Errors: Sentry in every service (Node, RN, Go), with release-version tagging and source maps uploaded in CI
- Traces: OTel auto-instrumentation in every service → OTel Collector → Tempo (or SaaS equivalent)
- Metrics: OTel metrics SDK → Prometheus / Mimir; Grafana dashboards
- Logs: Structured JSON logs (pino on Node, zap on Go) → Loki or Vector → Grafana
- Uptime: Better Stack or Pingdom hitting a /health endpoint that actually tests dependencies
The five rules we hold
- Source maps in Sentry, always. Errors without source maps are not errors, they are mysteries.
- Tag every release. Sentry + OTel both support release tags. Without them you cannot answer “did this start with the deploy?”
- Correlate trace IDs with Sentry events. Sentry’s tracing integration with OTel lets you jump from error to trace in one click.
- Sample traces, not errors. 100% error capture, ~10% trace sampling for most services. Errors are rare; traces are huge.
- Alert on user-impacting symptoms, not internal metrics. Page on “checkout 500s above 1%,” not “CPU above 80%.” The first means a user is suffering; the second is just weather.
What it costs
Sentry’s team plan covers most mid-scale products. Self-hosted Sentry is possible but operational overhead is non-trivial. OTel is free; the cost is the backend you pipe to. For most products under ~10 million events / month, the total observability bill stays under $300 / month and saves much more in faster incident resolution.
The honest scaling moment
Observability sized for “small product” becomes inadequate around 50–100k DAU. At that point trace volume explodes, error noise drowns signal, and dashboards need restructuring around user journeys instead of services. Plan a quarterly observability review the same way you plan database capacity reviews. The cost of skipping it is incidents that take twice as long to diagnose.
Frequently asked questions
Why use Sentry and OpenTelemetry together?
They solve different problems. Sentry is best-in-class for error context — stack traces, breadcrumbs, release tracking, user impact. OpenTelemetry is best for distributed traces, metrics and vendor-neutral instrumentation. Using both means errors stay debuggable while traces stay portable.
Is OpenTelemetry overkill for small teams?
No, if you start with auto-instrumentation. The default Node and Python SDKs cover HTTP, database and queue libraries automatically. Setup is hours, not weeks, and the value compounds as the service grows.
Working on something similar?
T-Square is an independent software engineering studio. We architect, build and operate production-grade systems for learning, AI and custom software products. Talk to a senior engineer if you’d like a second opinion on your architecture or roadmap.