Can OpenTelemetry replace Sentry?

The question, as it keeps getting asked

A developer named Paul asked on X in May 2026: “what do you use in place of sentry, self-hosted opentelemetry stack?” A few days later, a longer reply from another account read: “you’d be crazy to try to replace sentry with some home grown alternative. It’s not as simple as just clickhouse and some vibe coded dashboards.”

Both are right about different parts of the same problem. The question is the right one to ask. The answer is that you can replace some of what Sentry does with a pure OpenTelemetry stack, you cannot replace all of it, and the gap is exactly the part that takes the most engineering time to build. This guide is what to say back when someone proposes “let’s just use OTel.”

What OpenTelemetry actually is

OpenTelemetry is the joint output of two Cloud Native Computing Foundation projects, OpenTracing and OpenCensus, that merged in 2019. It defines three things.

A wire format. OTLP, the OpenTelemetry Protocol, specifies how spans, logs, and metrics are encoded for transmission over gRPC or HTTP. The Sentry SDK has its own envelope format. OTLP is the broader-ecosystem counterpart that almost every observability vendor now accepts as input.

A set of SDKs. The Go, Python, JavaScript, Java, .NET, Ruby, PHP, Rust, and C++ SDKs implement the same core API for creating spans, recording events, and exporting data. The auto-instrumentation libraries (otelhttp, otelsql, the JVM agent, and so on) hook into common frameworks the way Sentry SDK integrations do.

A reference data pipeline. The OpenTelemetry Collector is a single binary that receives OTLP, applies processors (filtering, sampling, batching, attribute transformations), and forwards to one or more backends. Most production OTel deployments run a collector tier between applications and storage.

What OpenTelemetry is not: a backend. The Collector receives data and routes it. It does not store the data, index it, query it, alert on it, or render it. Storage and query are exporter targets, and the choice of target has to be made for every OTel deployment.

The four signals, and which ones map to Sentry

OpenTelemetry’s data model has three pillars (traces, logs, metrics) with a fourth signal type, profiles, currently in beta. A Sentry-equivalent product needs the data from the first three plus a layer on top.

Traces. A trace is a tree of spans across services. The exception data lives as a span event on the span where the exception was raised, with the exception.type, exception.message, exception.stacktrace, and exception.escaped attributes following the semantic conventions. This is the raw material for what Sentry calls an “issue.” The OTLP for error tracking guide on this site has the per-attribute breakdown.

Logs. Logs in OpenTelemetry are timestamped records with attached attributes and an optional trace context. They are how the OTel ecosystem captures application log lines and correlates them with traces. A Sentry issue’s breadcrumbs map roughly to logs that share a trace ID.

Metrics. Counters, gauges, and histograms. Sentry uses these internally for things like error-rate-per-release. In a DIY OTel stack you compute them downstream from the trace data, or you instrument the service to emit them directly.

Profiles. The profiling signal type is in beta in OTLP as of mid-2026. The product layer for profiles is still split across Pyroscope, Parca, and a handful of vendor-specific tools. Sentry has its own profiling product. urgentry does not ship profiling today; the continuous profiling in 2026 guide has the rest of the landscape.

The first three signal types give you the data Sentry stores. What they do not give you is the product layer.

What the product layer actually contains

If you point a Go service at a vanilla OTel Collector that exports to ClickHouse, you get spans in ClickHouse. You can write a SQL query that returns all the spans with an exception event in the last hour. You cannot do any of these things without writing more code on top:

• Click an exception and see every other time it happened, grouped by stack-trace fingerprint.
• Mark a class of exceptions as known and stop being alerted about them.
• See which release introduced a new exception type and link it back to the deploy.
• Get a single notification when a previously-resolved issue starts occurring again.
• Assign a teammate to a specific bug and watch it move through a workflow.

These are not querying problems. They are product problems. They require a grouping algorithm, an issue state machine, an alert rules engine, a notification routing layer, a UI for triage, and a deduplication store that survives restarts. Each of them is months of engineering work. Sentry’s open-source release contains all of them. urgentry implements them in a single Go binary against SQLite. A bare OpenTelemetry stack contains none of them.

The X reply quoted at the top captures the same idea in fewer words: “it’s not as simple as just clickhouse and some vibe coded dashboards.” The vibe-coded-dashboard part is the product layer.

Building blocks of a DIY OTel-as-Sentry replacement

If you really want to assemble it yourself, the minimal set of pieces looks roughly like this:

[applications] → [OTel Collector pool] → [storage] → [query / UI] → [alerts]
                                              │
                                              └→ [grouping layer]  ← the part nobody ships

Ingest. OpenTelemetry Collector in a load-balanced pool. Two or three instances cover most teams, with the gateway/agent split if you have very large numbers of source services.

Storage. ClickHouse for traces (the most common pick), or Tempo if you prefer the Grafana stack. Loki for logs. Mimir or Prometheus for metrics. Storage is the cost line item that grows fastest with event volume. At 100M events per month a ClickHouse trace store runs roughly 10 to 50 GB per day depending on retention, sampling, and average span size.

Query. Grafana for visualization, plus direct SQL access for ad-hoc work. Honeycomb’s BubbleUp and Datadog’s APM views are not in the open-source toolbox. You build the equivalent views yourself in Grafana panels.

Grouping. The part nobody ships open source. Sentry’s grouper is roughly 8,000 lines of Python that fingerprint stack traces, normalize variable names, and merge similar messages. You either reimplement it, accept that you do not have grouping (and triage every event individually), or send the data through a product that has grouping built in.

Alerting. Grafana Alerting handles “threshold crossed” rules. It does not handle “this is a new exception type we have never seen before” without custom panel logic that depends on the grouping layer existing.

Issue workflow. Linear, Jira, or a small custom app, wired to the alerting webhook.

That is four to six tools to integrate plus the grouping gap. Most teams that go down this path end up running 0.25 to 1.0 FTE of platform engineering time on the stack itself, and the figure tends to drift upward over time as the build accumulates custom panels and alert rules.

The cost framing that gets quoted

A recurring X post compares the line-item math directly: “Datadog logs: $0.10/GB. Self-hosted Loki: ~$0/GB after a small VPS. Observability bills are 70-90% framework choice.”

The storage math is right. The math leaves out the engineer-hours, which for an in-house OTel stack are the dominant cost for any team under about twenty engineers. The error-tracking cost calculator on this site has the worked numbers across three traffic profiles.

The short version: a packaged product, whether Sentry self-hosted or urgentry or GlitchTip, beats the DIY OTel stack on total cost of ownership until your event volume is high enough that the SaaS bill alone is more than a senior engineer’s loaded salary. The crossover point sits somewhere between 20M and 200M events per month, depending on how much of your engineering team you would otherwise spend on observability ops.

When DIY OTel does win

There is a class of teams where building on raw OTel is the right call. If you are already running ClickHouse for product analytics, already have Grafana with on-call rotations wired to it, and your error volume is in the hundreds of millions per month: the marginal cost of adding a trace exporter is small, and the marginal benefit of a packaged tool is small. The product layer you would buy is something you have already built for adjacent reasons.

The same logic applies if your data-residency requirements rule out every SaaS option, your team includes specialists who already operate large OTel deployments, and you accept that grouping will be a custom build. At that volume you have probably already built the grouping equivalent for product analytics events.

For everyone else, the calculation is whether half an FTE of platform engineering plus the missing grouping algorithm is worth not paying for a packaged tool. For small teams, the numbers do not pencil out.

The middle path most teams end up on

Most teams want both. They want the product layer for errors, because errors are where you need an inbox and a workflow and a known-issues list. They also want OTel for the broader telemetry stack, because OTel is where the rest of observability is going.

urgentry’s position is to accept both on the ingest side. The Sentry SDK envelope arrives at /api/{project}/envelope/. The OTLP traces, logs, and metrics arrive at the standard OTel ports: 4317 for gRPC, 4318 for HTTP. The same backend stores both. The grouping, the issue inbox, and the alert rules apply to errors that arrived through either path.

# OTel Collector exporter pointing at urgentry
exporters:
  otlphttp/urgentry:
    endpoint: https://errors.yourdomain.com
    headers:
      # urgentry accepts the OTel exporter without auth headers
      # when reached from your private network; add auth here for
      # public ingest.

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/urgentry]

That setup is also the answer to the original X question. You can run a self-hosted OpenTelemetry stack for traces and logs and metrics, and you can send the trace stream to whatever long-term storage suits your team. For the errors-and-issues-workflow slice, point one of the exporter pipelines at a product that has the grouping built in. urgentry on a small VPS, GlitchTip, or Sentry self-hosted on the larger infrastructure footprint all fill that slot. None of them require you to give up the OTel data path.

The wrong answer is “we will build the grouping ourselves.” Almost nobody who starts that project finishes it. The right answer is to keep OTel as the wire format and buy (or self-host) the product layer separately.

Frequently asked questions