How Observability Unified compares

What this page is

A long-form companion to the comparison table on obsunified.com. The landing-page table is terse; each vendor column footnote-links to the matching section here, where every cell carries the source URL and a short excerpt. Use this page to verify a claim, read one vendor's profile, or see what was deliberately not compared. For a two-column Yes / Partial / No view against one vendor, see the per-vendor comparison pages, which add rows for MCP write defaults, MCP links, agent tool calls, CPU profiles, self-hosting, and SSO (ledger), and for release and flag comparison, dependency contention, proof of cause, fix verification, gated remediation, and click to trace (ledger). The four agent evidence rows in the tables below also appear on those pages.

Scope

• Vendors (9): Datadog, Sentry, PostHog, Honeycomb, New Relic, Grafana Cloud (LGTM stack), SigNoz, Uptrace, HyperDX.
• Axes (15): hosting model, pricing model, traces / APM, structured logs, AI / LLM observability, session replay, product analytics, alerting, cross-signal correlation, AI agent access (MCP), compacted evidence for AI agents, agent skills for coding agents, one ID chain from user to agent action, instrumentation gaps, data ownership. The AI agent access (MCP) axis was added and reviewed on 2026-11-10, the four agent evidence axes on 2026-11-11, and the other ten on 2026-10-13.
• Out of scope: infrastructure-only tools (Prometheus, Zabbix, Nagios), incident-response platforms (PagerDuty, Opsgenie), single-signal frontend tools (LogRocket, FullStory, Highlight), legacy enterprise suites (Splunk Observability Cloud, Dynatrace, AppDynamics, Elastic Observability), and cross-vendor performance benchmarks.

How to read the cells

• Each vendor table below lists the claim as reviewed on 2026-10-13 (2026-11-10 for the AI agent access (MCP) row, 2026-11-11 for the four agent evidence rows), the primary source read, and a short excerpt from that page.
• AI agent access (MCP) records whether the vendor ships a first-party Model Context Protocol server, whether the vendor hosts it or you run it, and how write tools are gated where the vendor states it. Where a vendor's page does not say, the cell does not either.
• The four agent evidence rows carry a Yes / Partial / Not marketed† verdict before the claim; the rules for each verdict are in the agent evidence ledger. They ask whether an AI agent can get compacted evidence sized for its context with a way to fetch full records, whether the vendor publishes agent skills for coding agents, whether user, session, backend trace, and agent or LLM records share linking IDs, and whether the product detects where instrumentation is missing.
• Not marketed† means we read the vendor's product index, docs navigation, or sitemap on 2026-10-13 and found no such product. It is not an explicit vendor statement, and it is not a demerit.
• Pricing is volatile. Prices are quoted as shown on the review date and may already have changed.
• Cells are descriptive, not scored. A vendor that does not sell a capability is not worse; it is a different shape of product.

---

Observability Unified

Self-hosted on Cloudflare Workers + D1 + R2, or Node + PostgreSQL + S3-compatible storage (including a zero-clone all-in-one Docker image on GHCR). Ships OTLP/HTTP ingestion for traces, logs, and metrics; structured logs; session replay (rrweb); AI / LLM and agent observability (Agent Action Graph); compressed context retrieval (CCR); AutoSRE causal ontology (change correlation, traffic-normalized cohort lift, noisy-neighbor contention checks, recurring incident memory, counterfactual eval verification, and pre-execution cryptographic remediation grants); usage analytics; alerts; CPU/off-CPU profiles; and a local stdio MCP server that is read-only by default (26 investigation tools; four write tools only when OBS_MCP_ENABLE_WRITES=true) and returns evidence bundles with citations and retrieval refs, all joined through one identity chain (user_id → session_id → interaction_id → trace_id → span_id → action_id). Limitations and what teams need to configure are listed in Where Observability Unified fits.

---

Datadog

Sentry

PostHog

Honeycomb

New Relic

Grafana Cloud

SigNoz

Uptrace

HyperDX

† Inferential negative: not marketed by the vendor on the pages, product index, or sitemaps read on 2026-10-13. Absence is not an explicit vendor statement. See ledger section 4.

---

Where Observability Unified fits

For an incident that spans several signals, Observability Unified connects instrumented records through shared IDs. An AI agent can retrieve a compact evidence bundle through MCP, and an engineer can inspect the same trace and related records in the dashboard. The seeded checkout walkthrough shows both paths. The tables above compare signal coverage, investigation workflows, and deployment options.

What AutoSRE & agentic onboarding add (beyond signal colocation)

Colocating traces, logs, and replays in one database is necessary for agentic debugging, but not sufficient for safe autonomous operations. Recent updates (RFC 0013) add a deterministic causal and governance layer designed specifically for AI SRE and coding agents:

1. Traffic-normalized cohort attribution (v_new vs. v_old): Instead of blaming an old release that happens to serve 90% of traffic during a 10% canary rollout, get_change_blast_radius compares per-request error rates across service.version, vcs.commit.id, and feature_flag.variant cohorts with a minimum sample-size gate (N >= 50 default, configurable via minSample).
2. Noisy-neighbor contention vs. code regression: Cross-checks whether co-hosted or downstream database/cache spans slowed down across unaffected callers at the same time (shared_degradation_new_version_aggressor vs. shared_degradation_external_cause), preventing false rollbacks during infrastructure saturation.
3. Orthogonal epistemic model (relationshipCertainty $\times$ causalProofTier): Separates link provenance (exact, inferred, heuristic) from causal proof (unverified_locus, corroborated_candidate, cohort_rate_isolated, counterfactual_verified). A stack trace touching a modified file is an exact structural link (touched_same_code_path), but only reaches corroborated_candidate and cannot self-authorize an autonomous production rollback.
4. Paired counterfactual verification: Upgrades findings to counterfactual_verified only when linked to an eval_case with a failing baseline run (passed = 0) and $K \ge 1$ passing candidate runs (passed = 1, configurable via requiredTrials) on the identical input_payload_hash.
5. Pre-execution CAS remediation gate & 1-click approval queue: The collector acts as a stateful policy gate rather than a direct infrastructure actuator: side-effecting proposals (rollback_deploy, toggle_feature_flag, open_code_pr) submitted via propose_remediation_action with CAS preconditions (expectedCurrentState) either earn a single-use 5-minute grantToken or wait in the dashboard's Autonomous Review (/#/autonomous-review) 1-click human approval queue. Your external agent or CI/CD runner claims the grant (claim_remediation_grant), executes the rollback/flag-toggle/PR, and reports completion, arming the collector's post-remediation watchdog (evaluateRemediationWatchdogs).
6. Zero-friction AI agent onboarding: Ships machine-readable docs (/llms.txt, /llms-full.txt), a 3-Tier Application Compatibility Matrix, non-interactive CLI scaffolding (pnpm dlx @obsunified/cli create --yes), and an explicit Autonomous vs. Human Intervention contract.

What teams need to take care of to enable AutoSRE

AutoSRE's trace fault localization works out-of-the-box on any OpenTelemetry spans, but to unlock cohort blast radius and change correlation, teams (or their onboarding AI agent) should wire three lightweight inputs:

• Runtime release lineage on spans: In the JS/TS SDKs (@obsunified/telemetry-sdk, @obsunified/analytics-sdk, @obsunified/sdk), pass environment, serviceVersion, commitSha, and configDigest to initObservability(...) and <AnalyticsProvider> (or set OBS_ENVIRONMENT, OBS_SERVICE_VERSION, OBS_COMMIT_SHA, OBS_CONFIG_DIGEST). In non-JS OpenTelemetry SDKs (Python, Go, Rust, Java, .NET, PHP, Ruby, Elixir, Swift, Kotlin), set the standard OpenTelemetry resource/span attributes (service.version, deployment.environment.name, vcs.commit.id, obs.config.digest).
• Feature-flag evaluations: In the JS/TS SDKs, call recordFeatureFlag(flagKey, variant, { providerName }) when evaluating flags; in non-JS OpenTelemetry SDKs, attach feature_flag.key and feature_flag.variant (or obs.feature_flags.<key>) to the active span.
• Release & config change events: Emit a change event from your CI/CD deploy step via pnpm dlx @obsunified/cli changes record --service <name> --version <ver> --commit-sha <sha> --touched-paths <files> (or POST /v1/changes).

Trade-offs and current limitations

That is a shape, not a verdict; the trade-offs are real:

• Maturity: early-stage software optimized for single-team deployments rather than complex enterprise organizations.
• Authentication and access control: single-password or bearer token authentication. Enterprise SSO, SAML, and fine-grained RBAC are not implemented.
• Protocols: ingestion is OTLP/HTTP only. gRPC exporters should be fronted with a standard OpenTelemetry Collector.
• Native mobile replay: rrweb session replay requires a browser DOM; native iOS/Android/React Native apps are supported for backend traces, logs, AI calls, and HTTP usage events, but not DOM replay.
• Query and dashboarding: analyses emphasize AI-assisted investigation, root-cause narratives, and trace traversal rather than arbitrary query builders (PromQL, NRQL, SQL panel editors).
• Storage and retention: D1 is subject to database size limits; high-throughput or long-retention workloads should use the PostgreSQL adapter with retention pruning.

Buyer guidance (editorial)

• Enterprise controls, broad integrations, per-host budgeting: Datadog or New Relic.
• Errors, replay (including mobile), and traces without running infrastructure: Sentry.
• Product analytics first, with replay, logs, and now tracing alongside: PostHog.
• Deep trace analysis and agent timelines on a wide-event store: Honeycomb.
• OSS, OTel-native, ClickHouse-shaped pricing: SigNoz, HyperDX, or Uptrace (HyperDX is the only one of the three with session replay).
• Composable LGTM stack you can scale per signal: Grafana Cloud or self-hosted Grafana.
• Everything in one self-hosted telemetry graph built for agentic debugging, compact CCR evidence bundles, and governed AutoSRE change correlation: Observability Unified, with the limitations above.

---

How we keep this honest

• Every cell is cited and dated. Each vendor section carries the source URL and an excerpt read on the review date. If the excerpt no longer matches the source, the claim is wrong by construction; tell us.
• The ledger is public. docs/comparison-full-audit-2026-10-13.md records, for all 90 cells, the historical claim, the verdict (TRUE 59 / PARTIALLY_TRUE 12 / OUTDATED 9 / FALSE 1 / UNVERIFIABLE 9), the corrected claim, the final URL read, and the excerpt. The AI agent access (MCP) row has its own 2026-11-10 ledger (9 cells, all TRUE, none inferential). The four agent evidence rows have their own 2026-11-11 ledger (36 cells: 35 TRUE, 1 UNVERIFIABLE). The earlier 2026-10-11 ledger, which recorded 0 of 90 cells verified, is preserved unchanged.
• Negatives are never inferred from silence alone. The nine "Not marketed†" cells list exactly what was read.
• The method is reproducible. The runbook is in apps/docs/scripts/COMPARISON_AUDIT.md. This pass was done manually (runbook Option B), one page at a time, with no multi-agent workflow.
• We score ourselves too. See Where Observability Unified fits.

Right of reply

If you work on one of these products, or you spot a stale or wrong cell, open a Comparison correction issue with the cell, the current and correct claim, and a vendor source URL. Accepted corrections are logged below.

Corrections log