Previously: Breaking Free: Avoiding Vendor Lock-In with Open Observability Standards (2024) OpenTelemetry (OTel) graduated as a CNCF project in May 2026. It's now the observability standard. Vendors everywhere support OTLP ingest. The instrumentation lock-in problem was supposed to be solved.
It isn't.
The mechanics shifted. You're less likely now to be trapped by a proprietary collection/instrumentation agent you can't rip out, and more likely to be trapped by dashboards you can't export, pricing you can't predict, an AI layer that only works inside one platform's walled garden, or autonomous workflows that can't leave the vendor. The lock-in got quieter. It didn't go away.
This is the 2026 version of the vendor lock-in conversation we started in the 2024 Breaking Free blog. Here's what the traps look like now, which open standards protect you, and what to look for in a platform that won't hold you hostage.
The instrumentation layer is (mostly) solved #
The instrumentation layer is (mostly) solved
The instrumentation lock-in problem that defined the early 2020s is largely behind us.
OpenTelemetry is now stable across all three signals: traces, metrics, and logs. The SDKs for Java, Go, Python, Node.js, and .NET are production-grade. Auto-instrumentation covers most common frameworks without a line of code. And the OpenTelemetry Collector has become the de facto data pipeline for telemetry, a vendor-neutral layer that sits between your services and wherever you send data.
In practice, if you're instrumenting a new service today with OTel, switching backends really is as simple as updating an endpoint. No re-instrumentation. No agent replacement. That promise has been delivered. The collection of telemetry has now been standardized.
The risk now is teams that haven't made that migration yet, still running proprietary collection/instrumentation agents, still tied to vendor SDKs. If that's you, this is the highest-leverage move you can make for long-term flexibility. You don't need to switch observability vendors to do it. You just need to move to OTel.
Tools like OTelBin (open source, built by Dash0) make it easier to configure and validate your Collector pipelines visually before you deploy them. The Dash0 Operator for Kubernetes automates telemetry collection from your cluster entirely, and because it exports via the OpenTelemetry Protocol (OTLP), it works with any vendor that can ingest OpenTelemetry data, not just Dash0.
If you're not sure where to start, an AI coding agent can help. Dash0's agent skills make that more reliable. AI agents are useful for adding instrumentation, but without OTel-specific knowledge they'll make the same mistakes any developer would: wrong attribute names, missing semantic conventions, misconfigured pipelines. The agent skills package that expertise directly into Claude Code, Cursor, and other compatible agents. Ask yours to instrument a service, set up a Collector pipeline, or review your telemetry for semantic convention compliance, and it already knows the right patterns across several languages. The same openness applies in reverse. The Dash0 MCP Server lets Claude Code, Cursor, and other MCP-compatible tools query your telemetry directly, over the same open protocol, not a proprietary plugin API.
Where lock-in still lives #
Where lock-in still lives
Your dashboards
Your dashboards
Dashboards are a quiet trap. They're not hard to build, they're hard to rebuild. After a year of iterating, you've got hundreds of panels tuned to your services, your alert thresholds, your team's mental model of what "healthy" looks like. That institutional knowledge doesn't export.
Most platforms store dashboards in proprietary formats. Some offer JSON export, but the JSON only works inside their ecosystem. Moving means starting from scratch.
The answer here is Perses, the CNCF sandbox dashboarding project. Dashboards defined in Perses are portable. You can deploy them alongside your code, check them into Git, and carry them with you if you ever switch platforms. Dash0 uses Perses natively, so your dashboards travel with you if you switch.
Your alerts
Your alerts
Same problem, different format. Hundreds of alert rules, tuned over years, expressed in a platform-specific domain-specific language (DSL). Migrating them is a manual, error-prone project that most teams postpone indefinitely, which is exactly what vendors are counting on.
Prometheus alerting rules are the open standard here. PromQL-based alerts are portable, community-supported, and well-documented. Projects like Awesome Prometheus Alerts give you a library of battle-tested rules you can adopt without writing from scratch. If your alerts live in code and ship with your services, they belong to you, not the platform.
Dash0 takes this further. Spam filters, recording rules, and notification channels are all manageable as code via the Dash0 CLI, Terraform provider, and Kubernetes Operator. And the Integrations Hub now ships with more than 100 pre-built check rules for Kubernetes, AWS RDS, Istio, Argo CD, and more, with pre-configured thresholds, so you're not starting from scratch on day one.
The query language
The query language
Proprietary query languages are a soft lock-in, but a real one. Every analyst, every SRE, every developer who learns your vendor's query syntax is building a skill that doesn't transfer. When you're evaluating a switch, "we'd have to retrain the whole team" is a real objection that kills migrations.
Prometheus Query Language (PromQL) is the widely adopted standard for metrics querying. It has a massive community, extensive documentation, and transfers directly to any Prometheus-compatible platform. If your team knows PromQL, they're not locked in. That knowledge works everywhere.
Dash0 uses PromQL for metrics and a unified Query Builder across metrics, traces, and logs, giving you one interface for everything. For teams newer to PromQL, the visual query builder lets you construct queries without writing syntax, and Automatic PromQL Explanations, accessed via the graduation cap button on any query, gives a plain-language breakdown of what a query does inline. And if your team already knows SQL, Dash0 has full SQL querying for logs, spans, and web events.
Your profiling data
Your profiling data
Continuous profiling is the newest signal joining traces, metrics, and logs, and it's walking into the same lock-in trap the other three already worked through. Profiling has historically lived in standalone tools with proprietary formats, disconnected from the rest of your observability stack.
pprof, the profiling format that originated at Google, is the open standard here, already the de facto interchange format for CPU and memory profiles across the industry, and notably more durable right now than OTel's own Profiles signal, which only reached public alpha in March 2026 and isn't yet recommended for production workloads. This year Dash0 acquired Polar Signals, the company behind the open source Parca continuous profiling project and widely regarded as building the deepest continuous profiler on the market, including continuous GPU profiling for CUDA workloads on NVIDIA hardware, down to individual GPU kernels. That technology is being integrated into Dash0 natively via SignalStore. Once that's done, profiling will sit on the same open footing as your traces, metrics, and logs.
The pricing model
The pricing model
This one is less technical but just as dangerous. Multi-year contracts and volume-based pricing with no visibility into what's driving costs are structural lock-in mechanisms. You may want to leave, but the exit is too expensive. Look for monthly subscriptions, transparent per-signal pricing, and real-time cost visibility broken down by service, team, or environment. OpenTelemetry's semantic conventions make that last part possible: when your data has consistent labels, you can actually see what's costing you and act on it.
For the core observability platform, Dash0 uses a [consumption-based model](https://www.dash0.com/pricing) with no base subscription fee: you pay per million spans, log records, or web events ingested and stored, or per million metric data points, at published rates with no hidden multipliers. It ships [Cost Forecast dashboards](https://dash0.com/docs/dash0/miscellaneous/cost-control/install-forecast) that break down spend by signal type, service, and namespace, and a [monthly budget](https://www.dash0.com/changelog/monthly-budget) you can set as a hard cap, so a spike in telemetry can't turn into a surprise invoice. [SignalControl](https://www.dash0.com/signalcontrol), included with every account, filters, samples, and aggregates telemetry at ingestion, before it's stored, so you're not paying to store data you'll never look at. ([Darkplane's AI Coding Insights](https://www.dash0.com/docs/dash0/darkplane/overview) is the exception: it's priced per user, not by data volume, since the value there is visibility into your team's AI coding activity, not telemetry.)
### [**Your visibility across the stack**](#your-visibility-across-the-stack)
Your visibility across the stack
One underrated form of lock-in is getting comfortable with a platform's way of connecting the dots: the specific way it links a slow trace to the underlying infrastructure metric that caused it, or surfaces the log line that explains an anomaly. When that correlation logic is proprietary, you're not just paying for storage. You're paying for a mental model that doesn't transfer.
Dash0's correlation runs on SignalStore, a single OpenTelemetry-native data layer holding every signal type: logs, metrics, traces, profiles, and web events. Every signal shares one pipeline. Nothing needs translating between them. That's what makes cross-signal correlation possible, instead of a proprietary layer stitching everything together after the fact. Dashboards, alerts, and Agent0 all query the same data. None of them work from a separate copy that could be out of date or missing something the others have.
On top of SignalStore sits the service map. It gives you a resource-centric view of how your services interact, visualizing connections across metrics, logs, spans, and alerts in a single graph. It's built on open, portable OTel semantic conventions, not a black box.
## [**The new frontier: AI lock-in**](#the-new-frontier-ai-lock-in)
**The new frontier: AI lock-in**
Here's where the conversation has moved most since 2024.
AI isn't just embedded in observability platforms anymore. It's autonomous now, performing root cause analysis and running agentic workflows that diagnose and fix incidents without a human. Genuinely useful, but a new surface for lock-in.
The risk is AI coupled to a vendor's proprietary schema. You're not just dependent on them for storage anymore, you're dependent on them for intelligence, and its reasoning never leaves their platform. The fix is open standards at the data layer. If the AI reasons over OTel-native data, its output can in principle be reproduced anywhere that ingests the same data. Worth asking directly, does the AI layer depend on proprietary formats, or does it operate on standard OTel signals? The answer tells you how portable your investment really is.
Dash0's answer is Darkplane and Agent0. Darkplane tracks cost, adoption, and productivity across your AI coding tools, like Claude Code, Cursor, GitHub Copilot CLI, and OpenAI Codex, reading it all as native OTel telemetry, not a proprietary format.
Agent0 correlates telemetry, reads your codebase, reaches external tools via MCP, and generates fixes as pull requests. That telemetry is open and structured, so any coding agent could use it, not just Agent0. Agent0 also doesn't lock insights inside the UI. It generates portable artifacts you own, dashboards in Perses, alerts in PromQL, runbooks in Markdown, code in GitHub.
Software is now built by AI and run by AI. Automations covers the running half. Triggered by Slack messages, GitHub events, failed checks, or schedules, Agent0 investigates and acts on its own, often fixing problems before anyone notices, and can call out to your own tools through MCP. Pre-built templates cover common workflows, or write your own in natural language. Your agents can act on your telemetry without being locked into Dash0.
What to actually look for #
What to actually look for
When evaluating an observability platform through the lens of lock-in, the checklist is short:
- Instrumentation: Are they OTel-native, or do they ask you to run their agent? Is OTLP the primary ingest path?
- Dashboards: Are they stored in a portable, open format (Perses)? Can you export and redeploy them outside the platform?
- Alerts: Are they PromQL-based? Can they live in your Git repo and deploy with your infrastructure?
- Query language: Is it PromQL or something proprietary? Is existing community knowledge transferable?
- Pricing: Monthly or annual lock-in? Can you see cost broken down by service and environment in real time?
- AI: Does the AI layer operate on OTel-native data, or does it require proprietary formats to function? Does it generate portable artifacts like alerts and dashboards, or just insights you can't take with you?
- Security and compliance: Is the platform SOC 2 Type II certified? GDPR compliant? These matter when your telemetry data includes sensitive system and user information.
A platform that scores well across all of these isn't just easier to leave. It's also easier to adopt, easier to maintain, and easier to extend as your stack evolves.
Final thoughts #
Final thoughts
OpenTelemetry solved the instrumentation problem. The remaining lock-in vectors (dashboards, alerts, query languages, pricing opacity, and increasingly AI) are all addressable with the same philosophy: open standards, portable formats, data you own.
The goal isn't to make it easy to leave your observability vendor. The goal is to make sure that staying is always a choice, not a trap.
Dash0 is built on OpenTelemetry, Perses, and PromQL, open standards all the way down. Start a free trial**or book a demo**to see what that looks like in practice.
Frequently asked questions #
Frequently asked questions
Frequently asked questions
Frequently asked questions
Is OpenTelemetry enough to avoid vendor lock-in?
Is OpenTelemetry enough to avoid vendor lock-in?
Not entirely. OTel solves instrumentation lock-in, switching backends becomes as simple as updating an endpoint. But dashboards, alert rules, query languages, pricing models, and AI layers can still trap you. OTel is a necessary starting point, not a complete solution.
#### [**How do I keep my dashboards portable when switching observability platforms?**](#how-do-i-keep-my-dashboards-portable-when-switching-observability-platforms)
Use Perses, the CNCF sandbox dashboarding project. Dashboards defined in Perses can be deployed alongside your code, checked into Git, and carried with you if you switch platforms. Dash0 uses Perses natively, so your dashboards are never an asset that stays behind.
#### [**Are PromQL-based alert rules portable across observability platforms?**](#are-promql-based-alert-rules-portable-across-observability-platforms)
Yes. PromQL alert rules are community-supported, well-documented, and work on any Prometheus-compatible platform. If your alerts live in code and ship with your services, they belong to you regardless of which observability vendor you use.
Can AI features in observability platforms create vendor lock-in?
Yes, if the AI operates on proprietary data models. An AI layer that only works with one platform's schema creates a new form of lock-in. The protection is AI built on open standards, in other words OTel-native data with OTLP as transport and semantic conventions as the schema.
What portable artifacts does Agent0 generate?
What portable artifacts does Agent0 generate?
Agent0 generates Perses dashboards and PromQL-based alert rules from natural language. Because these formats are open standards, the output isn't tied to Dash0 so you can take it with you if you ever switch platforms.
How can I see which services are driving my observability costs?
Dash0 ships Cost Forecast dashboards that break down spend by service, namespace, and signal type in real time. OpenTelemetry semantic conventions make accurate cost attribution possible: consistent attribute names across your telemetry mean costs can actually be traced to their source.
What should I check when evaluating an observability platform for lock-in risk?
Check seven things: OTel-native ingest (OTLP), dashboards in an open format like Perses, PromQL-based alerts, a standard query language, consumption-based pricing with real-time cost visibility, AI that operates on open standards, and SOC 2 Type 2 certification.