How to choose an observability platform in 2026: 12-point checklist

Choosing an observability platform used to mean picking the tool with the longest feature list. In 2026 almost every serious vendor covers metrics, logs, traces and some form of AI assistance, so feature lists no longer separate good choices from expensive mistakes. What does separate them: how the pricing model behaves as you grow, whether your instrumentation stays portable, where your data lives and how fast the platform helps your engineers find a root cause at 3 a.m.

This guide is a vendor-neutral, 12-point checklist for evaluating observability tools. You can use it as the skeleton of an observability RFP, as a scoring sheet for a shortlist or simply to ask better questions in your next vendor call. It ends with a proof-of-concept plan and a weighted scoring table you can copy.

Before you compare: define the job of the observability platform

Most failed tool evaluations fail before the first demo, because nobody wrote down what problem the new platform should solve. Spend half a day on three inputs:

• Use cases ranked by value: incident response for customer-facing services, capacity planning, SLO reporting, security investigations, cost allocation, AI and LLM workloads. Rank them; a platform that is excellent at your top three beats one that is average at ten.
• Current volumes: number of hosts and containers, metric time series, log volume per day in GB, spans per day, number of users who need access. If you do not know these numbers, collect them first; every pricing discussion depends on them.
• Constraints: data residency, regulatory frameworks (GDPR, DORA, NIS2, sector rules), procurement rules, existing contracts and their end dates, and the team capacity available for migration.

If your team is still debating what observability means beyond dashboards, align on a shared definition first; our primer on what observability is is a good starting point for that conversation.

The 12-point observability platform buyer's checklist

Each point below contains the question to ask, why it matters and what a good answer looks like. Treat the points as categories in your scoring table later.

1. Pricing model and cost predictability

Observability pricing falls into four broad models, and most vendors combine several of them:

• Per host or per node: predictable for static VM fleets, harder to forecast with autoscaling and short-lived containers. Ask how hosts are counted (peak, average, high-water mark) and what counts as a host in Kubernetes and serverless.
• Per GB ingested or indexed: scales with data volume. Ask whether you pay for ingestion, indexing, storage or all three, and whether data you drop at ingest is free.
• Per signal or per event: you pay per million log records, spans or metric data points. This maps cost directly to telemetry, which makes it easier to see which service generates which bill.
• Per user or seat: common for full-access licenses. Watch out for incentives to keep engineers out of the tool, which defeats the purpose of observability.

To estimate cost, convert your volumes into each vendor's billing unit. An illustrative approach: count log records per day rather than GB (if you only know GB, measure your average record size; many structured logs land between a few hundred bytes and about one kilobyte), count spans per day from your tracing sampling rate, and count active metric time series multiplied by scrape frequency for data points. Then build a spreadsheet with three rows: today, 2x and 3x volume. A model that looks cheap today but grows faster than your traffic is a risk, not a saving.

2. OpenTelemetry support and lock-in

Instrumentation is the most expensive part of any observability rollout to redo. Ask whether the platform ingests OTLP natively for traces, metrics and logs, whether it follows OpenTelemetry semantic conventions without proprietary renaming and whether you can export your data in an open format at any time. A platform that requires its own SDKs or agents for core features creates switching costs that show up years later. If you are new to the standard, read what OpenTelemetry is before the vendor calls.

3. Data residency and GDPR

Telemetry contains personal data more often than teams expect: IP addresses, user IDs in URLs, email addresses in log messages. Ask in which regions data is stored and processed, which sub-processors are involved, whether there is a bring-your-own-cloud option and whether PII can be masked before it is stored. Get the data processing agreement early; legal review often takes longer than the technical evaluation.

4. Security certifications and access control

Request current reports, not logos: ISO 27001, SOC 2 Type II and, for German public sector or regulated industries, BSI C5. Check SSO and SCIM, role-based access down to the field or dataset level, audit logs and whether customer data is used to train AI models.

5. Signal coverage and correlation

Every platform shows metrics, logs and traces. The real test is correlation: can you go from an alert to the slow trace, from the trace to the logs of that exact request and from there to the host or pod, without copying IDs between tabs? Add profiles, real user monitoring and synthetic checks if they are on your use-case list.

6. AI and root-cause analysis

AI features range from chat interfaces over documentation to investigations that correlate topology, changes and anomalies. Ask the vendor to show the evidence behind an AI conclusion, not just the conclusion. A good assistant cites the traces, metrics and deployments it used, so an engineer can verify the answer in under a minute.

7. Scale and cardinality

High-cardinality attributes such as customer ID, tenant or pod name are what make telemetry useful for debugging. Ask whether cardinality affects price, query speed or retention, and what happens when a team accidentally ships a label with millions of values.

8. Query language and data access

Engineers will spend hours in the query interface. Check whether it supports familiar languages such as PromQL or SQL, how a non-expert builds a query and whether queries are available through an API and CLI for automation.

9. Retention and data tiering

Ask for default retention per signal, the price of longer retention and whether you can keep hot data for days and cheaper archived data for months. Compliance requirements for audit logs often differ from what debugging needs.

10. Integrations and migration effort

List the 20 technologies that matter most to you (cloud services, databases, queues, Kubernetes, CI/CD, incident tools) and verify each one, rather than trusting an integration count. Estimate migration effort in person-weeks: agents, dashboards, alerts, runbooks and training.

11. Operations and workflow fit

Check alerting, SLOs, on-call integrations and whether dashboards and alerts can be managed as code. A platform that cannot be versioned in Git will drift.

12. Total cost of ownership and commercial terms

License cost is only one line. TCO includes ingestion and storage, engineering time for operating agents and pipelines, migration effort, training and the opportunity cost of slow incident resolution. Also check contract terms: commit levels, overage rules, true-ups and exit clauses.

How to estimate total cost of ownership

A simple TCO model has four blocks. Keep the assumptions visible so stakeholders can challenge them:

1. Platform fees: volumes converted to each vendor's units at 1x, 2x and 3x, including retention and add-ons you will actually need.
2. Operating effort: hours per month for agent upgrades, Collector or pipeline operation, index management and capacity planning, multiplied by a loaded engineering rate.
3. One-off migration: re-instrumentation, dashboard and alert migration, parallel run costs (you will pay two vendors for a few weeks) and training.
4. Risk and value: harder to quantify, but write it down: expected change in time to detect and resolve incidents, and the cost of lock-in if you need to switch again.

Two practical tips: ask vendors to price your spreadsheet, not their reference customer, and model what happens if you filter 30 to 50 percent of low-value logs at ingest. Platforms that charge little or nothing for dropped data reward good data hygiene.

A 2–4 week proof-of-concept plan

A proof of concept should answer your top questions with your own data. A structure that fits into two to four weeks:

1. Week 0, preparation: choose two or three representative services, ideally one with known performance issues. Define five to eight success criteria from the checklist above, with owners.
2. Week 1, ingest: send telemetry through OpenTelemetry where possible so the same instrumentation can feed every candidate. Measure time to first useful trace and the effort per service.
3. Week 2, daily work: rebuild the three most important dashboards and five critical alerts. Let on-call engineers use the platform for real questions.
4. Week 3, incident drill: replay or inject a realistic failure (slow dependency, bad deployment, memory leak) and time how long each team needs to find the root cause.
5. Week 4, cost and security review: compare measured volumes against pricing, complete the security questionnaire and collect structured feedback.

Keep the evaluation fair: same services, same time window, same scenarios for every vendor.

Scoring table for your observability RFP

Weight each criterion according to your priorities (weights should add up to 100), score each vendor from 1 to 5 and multiply. The example weights below fit a mid-sized engineering organization with GDPR requirements; adjust them to yours.

Criterion	Weight	What a 5 looks like	Vendor A	Vendor B
Pricing model and predictability	12	Cost scales linearly with telemetry; dropped data is cheap or free
OpenTelemetry and portability	12	Native OTLP for all signals; export anytime
Data residency and GDPR	10	EU region or own cloud; PII masking at ingest
Security and certifications	8	Current ISO 27001 and SOC 2 Type II reports; field-level access
Signal correlation	10	Alert to trace to log to host in a few clicks
AI and root-cause analysis	8	Answers with verifiable evidence
Scale and cardinality	8	High cardinality without penalties or slow queries
Query language and API	6	PromQL or SQL support; full API and CLI
Retention and tiering	5	Flexible retention per signal
Integrations and migration effort	8	Your top 20 technologies verified in the PoC
Operations and as-code workflows	5	Dashboards, alerts and SLOs in Git
TCO and commercial terms	8	Lowest 3-year TCO at 3x volume; fair exit terms

Treat any criterion your organization considers mandatory, such as EU data residency, as a knock-out before scoring, not as a weight.

Questions to put in every observability RFP

• Please price our volume sheet at 1x, 2x and 3x, including retention and all features we listed.
• Which data do we pay for if we drop or sample it at ingest?
• Which features require proprietary agents or SDKs instead of OpenTelemetry?
• How do we export all our data, in which format and at what cost?
• In which regions is data stored and processed, and who are your sub-processors?
• Is customer data used to train AI models?
• What migration support do you provide, and who pays for the parallel run?

Independent comparisons help you prepare for these conversations; you can find side-by-side overviews of common platforms in our observability platform comparisons.

Where Obseria fits

We built Obseria around the criteria above, so it is fair to tell you how it answers them. Obseria is OpenTelemetry-native, with OTLP export at any time. Pricing is per signal with no host or seat fees, filtered data costs only ingestion and every feature is included. Data can stay in the EU, in the UK or in your own cloud account, and our certifications and reports are listed on the security and trust page. If you are moving from another tool, our migration team helps plan the parallel run. The fastest way to score us against your checklist is a 14-day free trial with your own telemetry.