Open-source alternative to Splunk Observability Cloud: the short answer
If your renewal, a pricing change, a data residency requirement or lock-in has pushed you to look at Splunk Observability Cloud, the short answer is that OpenTelemetry, Prometheus, Grafana and Loki can cover metrics, traces and logs on infrastructure you run yourself, with gaps you should price in before you commit. OpenTelemetry handles instrumentation and collection, Prometheus stores and queries metrics, Loki stores logs and Grafana provides dashboards and alerting. Tempo or Jaeger is typically added for trace storage, since the sibling monitoring pages cover that choice. Observability Cloud is listed on Splunk's pricing page as a separate product that correlates metrics, traces and logs in one place, so it is not the same thing as the Splunk platform. Moving off it does not automatically move your Splunk Enterprise or Splunk Cloud Platform contracts, and you should check those separately.
The open stack is a set of components, not one vendor product. Each component has its own license, release cycle and operator. OpenTelemetry Collector is Apache-2.0, Prometheus is Apache-2.0, and Grafana, Loki and Tempo moved from Apache 2.0 to AGPLv3 in April 2021, so confirm that AGPLv3 terms work for your legal team before you embed them in a product. Gaps to confirm early include Prometheus's stated focus on reliability over precision, which makes it a poor fit for exact per-request billing, and the fact that single-node Prometheus storage is not clustered or replicated. Grafana's SAML and SCIM provisioning are limited to Grafana Enterprise and Grafana Cloud, so check your identity requirements against the Grafana authentication documentation.
DeployOpen plans, implements, hardens, integrates and supports this stack inside your own cloud accounts, data centers or air-gapped networks. We do not sell a license for these components, and the cost you carry is infrastructure, storage and the staff who operate them, which we size in a written scope before work begins. Your first decision is which signals must move on day one and which can run in parallel. Ask your team to inventory every Observability Cloud dashboard, detector and data source, and mark which ones depend on Splunk-specific features. That inventory becomes the basis for a fixed-scope plan and a parallel-run period.
Which Observability Cloud capabilities map to open-source components
This table maps the main Splunk Observability Cloud capabilities to open-source components and marks where coverage is partial. Use it as a checklist against your own Splunk account, since feature names and packaging vary by subscription. The main takeaway is that metrics, traces, logs and dashboards have direct open-source equivalents, while detectors, service-level views and some access features need extra work.
| Capability | Open-source component | Coverage and what to confirm |
|---|---|---|
| Metrics ingestion | Prometheus pull model, OpenTelemetry Collector for push | Prometheus scrapes HTTP targets and supports a push gateway for short-lived jobs. Confirm which Splunk metric sources you rely on, such as OTLP or vendor integrations, and check each has a Collector receiver. |
| Long-term metrics storage | Prometheus local storage plus remote write to external storage | Local storage is single-node and not replicated, with default retention of 15 days. Long retention needs a remote storage system, which is an extra component to size and operate. |
| Traces | OpenTelemetry Collector with Tempo or Jaeger | Tempo and Jaeger are not covered by the supplied sources for version or feature detail, so confirm sampling, search and retention needs against their documentation. Trace SDK support is stable in most languages. |
| Logs | OpenTelemetry Collector with Loki | Loki is the log backend here. Confirm query language needs and log volume, since Splunk SPL searches will need to be rewritten in LogQL or another approach. |
| Telemetry pipeline and processing | OpenTelemetry Collector (agent and gateway modes) | Covers receive, process and export. Core component stability varies, so check each component README before using it in production. |
| Dashboards | Grafana | Direct coverage for dashboards and provisioning. Dashboards built in Splunk must be rebuilt, and provisioning or Git Sync can keep them as code. |
| Alerting | Prometheus alerting rules with Alertmanager, plus Grafana alerting | Alertmanager covers grouping, inhibition and silences. Splunk detectors with complex logic may need manual translation, and Grafana HA needs extra setup to avoid duplicate notifications. |
| Service discovery | Prometheus service discovery and static configuration | Prometheus finds targets through service discovery or static configuration. Confirm your cloud or Kubernetes discovery sources are covered by Prometheus integrations. |
| Authentication and SSO | Grafana authentication (LDAP, OAuth, Entra ID, Okta, auth proxy, JWT) | SAML, team sync, active sync and SCIM are Grafana Enterprise or Grafana Cloud features. Confirm whether your identity provider flow needs one of the non-Enterprise options. |
| Access control and team roles | Grafana roles and teams, Collector authenticator extensions | Role-based access in Grafana depends on edition for team sync. Confirm each Splunk role and team boundary you need to reproduce. |
| Operational data store | Grafana with MySQL or PostgreSQL | SQLite is not suitable for production. Plan a managed or self-run MySQL 8.0 or PostgreSQL 12 or later database and its backups. |
Which open-source building blocks fit which teams
Observability Cloud bundles metrics, traces and logs into one product, so the replacement is a set of separate components that you choose and connect yourself. Each card below covers one building block, when it fits, and the trade-off your team will carry. Read them together, because the collector, storage and front end decisions shape each other.
Prometheus for metrics
Prometheus pulls metrics over HTTP from targets found through service discovery or static configuration, and PromQL is its query language. It fits teams that already scrape Kubernetes or host exporters and want alerting through Alertmanager. The trade-off is that its local storage is a single node that is not clustered or replicated, so long-term retention needs remote write to an external store. Confirm that store, its retention cost and its query path before you retire any Observability Cloud dashboards.
OpenTelemetry Collector as ingestion layer
The Collector receives, processes and exports telemetry from many sources, and it can run as an agent beside services or as a gateway. Using it as the single entry point lets you change backends without re-instrumenting applications. Check the stability level of each component you rely on, since core components have mixed maturity, and check that your SDK languages support logs, because log SDK maturity varies more than traces.
Loki for logs
Loki stores log streams with labels, which keeps ingestion simple but means queries against unlabeled content are slower than full-text indexing. It suits teams whose logs are already tagged by service, namespace and environment, and who want logs queried next to metrics in Grafana. Loki is licensed under AGPLv3 since the 2021 relicensing, so confirm with your legal team whether running it as a modified service triggers source disclosure obligations.
Tempo or Jaeger for traces
Trace storage is the piece most often left out of a first design. Tempo is licensed by Grafana Labs under AGPLv3 and pairs with Grafana for trace-to-log and trace-to-metric navigation. Jaeger is an alternative when you want a separate trace UI or a different storage backend. Decide which one by testing trace search with your real sampling rate, because storage volume depends on sampling far more than on the tool.
Grafana as shared front end
Grafana queries Prometheus, Loki and Tempo from one interface, so operators and developers share dashboards and alerts. It is licensed under AGPLv3 since 2021, and SAML, SCIM and team sync are limited to Grafana Enterprise and Grafana Cloud. High availability needs two or more servers behind a load balancer on MySQL or PostgreSQL, not SQLite. Check your identity provider requirements early, because the open edition supports OAuth and LDAP but not SAML.
Running the open stack alongside Splunk during the transition
Dual export sends the same metrics, traces and logs to Splunk Observability Cloud and to the self-hosted stack at the same time, so dashboards, alerts and trace views can be compared on live data before anyone relies on the new platform. The usual place to do this is the OpenTelemetry Collector, which can receive telemetry once and export it to more than one destination. Running both paths doubles the egress, the collector capacity and the on-call attention for the overlap period, so the cost of this phase is mostly the work of keeping two systems accurate.
- Single receiver, two exporters: Configure one Collector pipeline with two exporters so applications change only once, and confirm that each exporter's queue and retry settings are sized for the destination it feeds.
- Matched resource attributes: Check that service names, environment labels and host identifiers are identical in both backends, or every comparison will show false gaps.
- Sampling parity: Compare trace sampling rules on both sides, because differences in head or tail sampling will make request counts look different even when the platforms agree.
- Alert shadowing: Run new Prometheus and Grafana alert rules in notify-only mode and log their firing history against the existing Splunk detectors.
- Secret handling: Keep exporter credentials in the Collector configuration through the authenticator extensions and a secrets store, not in plain files.
Before cutover, ask your team to write down which dashboards and alerts are authoritative, and confirm the outcome of each comparison with the people who receive the pages.
Many teams move observability first and keep Splunk Enterprise Security or the Splunk log indexes for security monitoring for longer. In this split, the OpenTelemetry Collector is still the right place to fan out data, but security logs may continue to go only to Splunk while application telemetry goes to Prometheus, Loki and Grafana. The main risk is that the same event ends up in two places with different retention, access rules and owners, which is hard to explain during an audit.
- Clear data ownership: Record which sources belong to the security team and which belong to platform or application teams, and avoid sending the same security log to both platforms unless someone owns both copies.
- Retention per stream: Set Loki and Prometheus retention to match what your investigations and compliance records require, and confirm those values with the teams that answer audit requests.
- Access control: Grafana authentication options differ by edition, so confirm which single sign-on features your Grafana edition provides before granting access to telemetry that includes user identifiers.
- Trace context in logs: Make sure log records carry trace identifiers, so engineers can move from a Grafana trace to matching logs without leaving the stack.
- Exit criteria: Agree in writing which Splunk searches or dashboards must be retired before its license scope is reduced.
Ask your Splunk account team and your security lead to confirm which data is still required in Splunk for detection and compliance, and document that decision with the date it was made.
Teams that run Splunk Universal Forwarders on servers face a second migration on top of the backend change. Each forwarder is configured on the host, and replacing it means choosing a collector per data type, deploying it, and confirming that the same files, event sources and fields arrive in the new backends. The OpenTelemetry Collector can take over many metric and log sources, but it is not a one-to-one replacement for every forwarder input, so the inventory of inputs is the first task.
- Input inventory: List every monitored file, Windows event channel, scripted input and forwarded port per host, and mark which ones the OpenTelemetry Collector receiver covers and which need another agent.
- Parallel running: Keep forwarders sending to Splunk while the new collector sends to the open stack, then compare event counts for each source over a period you agree in advance.
- Field and timestamp checks: Verify that parsed fields, time zones and multiline events match, since differences here often break dashboards without causing obvious failures.
- Agent footprint: Measure CPU and memory of the new agents on representative hosts, and check which of them run under the privilege level your security policy allows.
- Fleet management: Decide how collector configuration is pushed and versioned across hosts, because forwarder deployment tools will not manage the new agents.
For the agent-level comparison and side-by-side patterns, see the sibling page on replacing the Splunk Universal Forwarder. Confirm the sources and the forwarder versions in your own estate before planning the rollout.
Moving dashboards, alerts and telemetry without a gap
The sequence builds the new telemetry path first, proves it matches the old one in parallel, and cuts over only after signals, dashboards and alerts have been checked against each other.
Inventory signals, dashboards and alert rules
The observability owner and the service teams list every metric, trace and log stream sent to Splunk Observability Cloud, every dashboard and detector, and who receives each alert. Record the source system, the owner and the consuming dashboard for each item in a shared sheet. The step is done when every production service has an entry and each dashboard or alert has a named owner who has confirmed it is still needed. Unused items are retired here, not migrated.
Stand up the OpenTelemetry Collector and Prometheus
The platform team deploys the OpenTelemetry Collector as an agent beside services or as a gateway, and configures receivers and exporters for the signals in the inventory. Prometheus is deployed to scrape the metrics endpoints, with service discovery or static targets set per environment. Because Prometheus local storage is single-node and not replicated, the team decides in advance how long-term data will be kept and whether remote write to external storage is needed. Done when test telemetry from one service appears in Prometheus and in the Collector's own health metrics.
Provision Grafana data sources and dashboards as code
The team defines Prometheus, Loki and any trace backend as data sources, and rebuilds dashboards as JSON or YAML files loaded by Grafana provisioning, stored in Git and reviewed like other code. Production Grafana uses MySQL or PostgreSQL for configuration rather than SQLite, since SQLite is not suited to production. Dashboards are rebuilt from the inventory, not copied by hand. Done when a fresh Grafana instance built from the repository shows the same dashboards with data from the new sources, and no dashboard depends on a manual change made in the UI.
Rebuild alert rules and Alertmanager routing
Each Splunk Observability detector is rewritten as a Prometheus alerting rule expressed in PromQL, then routed through Alertmanager, which handles grouping, inhibition and silences. Alertmanager is run as a cluster where high availability is needed, and Prometheus is configured to point at every Alertmanager instance rather than a load balancer. Each rule is tested against recorded or synthetic conditions, and the on-call paging path is verified end to end. Done when every migrated alert has a documented threshold, a receiver, and a test that fired it and reached the intended team.
Run both platforms in parallel
For a defined period agreed by the team and its approvers, Splunk Observability Cloud and the new stack receive the same signals and evaluate the same conditions. The team compares metric values, trace coverage and log lines, and records every difference with its cause, such as sampling, label naming or timestamp handling. Prometheus documents that it favors reliability over precision, so small differences in aggregated values are expected and must be accepted or fixed explicitly. Done when the differences are all explained and each open gap has an owner and a decision.
Handle historical data and confirm what can be exported
Historical metrics, traces and logs are not moved automatically. The team confirms with the Splunk administrator which data can be exported, using the methods described in the sibling export page, and which retention periods the business needs for audits or incident reviews. Data that must be kept is archived in the format the export supports, and the archive is tested by reading it back. Done when the retention decision is signed off, the archive location is documented, and the reader has confirmed the export limits in their own Splunk environment.
Cut over and retire the Splunk signals
Once parallel runs show the agreed differences only, teams switch their dashboards, alerts and on-call links to the new stack, and the Collector stops sending to Splunk. Splunk ingestion is kept available for a rollback window that the team sets in advance. Cutover is recorded in the inventory, and each service owner confirms that their alerts fired correctly after the switch. Done when no detector or dashboard in the inventory still points at Splunk, and rollback has been tested.
The operations work that comes with a self-hosted stack
The recurring work in this stack is upgrades, and the cadence is the first thing to plan for. Prometheus begins a new minor release cycle every 6 weeks, and a minor release generally stops receiving bug fixes after those 6 weeks, so a team running an ordinary minor line must upgrade on that rhythm. Teams that want fewer moves can follow the long-term support line instead. According to the Prometheus release cycle page, the current LTS line is 3.13, supported until July 31, 2027, and LTS releases receive bug fixes for one year. Grafana follows its own rhythm: major releases once a year, minor releases every other month, and patch releases at least monthly, with each minor release supported for 9 months. Confirm which line you will run, then book a standing monthly patch window for both Prometheus and Grafana and an annual planning slot for Grafana major versions.
Grafana needs a database decision before go-live. The default SQLite store does not scale for production, so MySQL 8.0 or later or PostgreSQL 12 or later is required for production and high availability. Highly available Grafana runs two or more active-active servers behind a load balancer on that shared database, and the high availability docs warn that alerting needs extra configuration to avoid duplicate notifications and that Grafana Live has limitations in that mode. Prometheus is different: its local storage is not clustered or replicated, so each Prometheus server is managed like a single-node database. Alertmanager can run as a cluster, and Prometheus should list every Alertmanager instance rather than sit behind a load balancer. Ask your platform team to write down the failover behavior for each component before you move dashboards that people depend on.
Collector and retention work is where the stack's maturity varies most. Trace APIs and SDKs are stable in most languages, but log SDK maturity varies and core Collector components carry mixed stability levels, so check each component's README in the version you deploy. Prometheus retains data for 15 days by default, configurable by time or size, and long-term retention needs a remote write target. Size storage from your own series count, scrape interval and retention target, and confirm the figures with a load test in your environment rather than with a generic estimate. Security hardening covers the Grafana settings the security hardening docs list, including secure and SameSite cookies, a Content Security Policy, and authentication on the metrics endpoint, plus Collector authenticators for OIDC on receivers. Keep these reviews on the recurring calendar.
What does replacing Splunk Observability Cloud cost and take?
What are the main cost drivers when replacing Splunk Observability Cloud with open source?
The software itself carries no license fee, so the cost sits in four components: infrastructure, storage, implementation and the staff who run the stack. Prometheus, the OpenTelemetry Collector, Grafana and Loki are all open source, and Prometheus has no paid enterprise edition. Infrastructure covers the compute for collectors, Prometheus, Loki, Grafana and Alertmanager, plus any load balancers and databases. Storage is driven by how many series, log lines and traces you keep and for how long. Implementation is a one-time cost for instrumentation, dashboards, alert rules and migration. Staff time recurs for upgrades, on-call and capacity work. Ask any quote to split these four lines so you can see what recurs.
Can a small team run an open-source observability stack on its own?
A small team can run a basic stack alone if it already operates Linux, containers and databases and accepts that monitoring becomes an internal service. The work is manageable in a narrow scope, such as a few services with metrics and dashboards. It gets harder with traces, long log retention, high availability and many teams. Prometheus local storage is not clustered or replicated, so a single node needs its own backup and failure plan. Grafana production use needs MySQL or PostgreSQL, and high availability needs two or more servers behind a load balancer. Confirm internally who owns upgrades, alert quality and on-call before deciding who builds it.
What skills and access does the internal team need for this work?
The internal team needs skills in instrumentation, Linux and container operations, query languages and database administration. Instrumentation means adding OpenTelemetry SDKs or agents to services, and trace SDKs are stable in most languages, while log SDK maturity varies. Operations means running Prometheus, Alertmanager, the Collector and Grafana, and reading PromQL well enough to write alert rules. Platform work includes storage sizing, TLS, authentication and backups. Access requirements include deployment rights in the target environment, service account rights for the monitored systems and a change process for alert routing. Teams should also plan for the Grafana and Prometheus release cycles, since older minor releases stop receiving fixes.
How long does replacing Splunk Observability Cloud take?
The duration depends on scope, and no fixed number applies to every environment. The main drivers are the number of services to instrument, how many dashboards and detectors must be rebuilt, the volume of traces and logs and whether you run in parallel with Splunk for a period. A metrics-only move with a small set of dashboards is much shorter than a full move with traces, logs, alert routing and compliance evidence. Ask for a timeline in the written scope, broken into discovery, build, parallel running and cutover, and confirm which of these depends on your change approval cycle.
Is Grafana Cloud a cheaper alternative to Splunk Observability Cloud?
Grafana Cloud is a hosted alternative rather than a self-hosted one, and its listed tiers set the cost frame. The pricing page lists a free tier, a Pro tier with a 19 US dollar monthly platform fee plus usage, and an Enterprise tier with a minimum commitment of 25,000 US dollars per year. Usage charges depend on the volume you send, so model your metrics, logs and traces before comparing. Cloud removes the operations work but keeps data in a vendor's environment, which matters for data residency. Self-hosted Grafana and Loki are licensed under AGPLv3, so run the license review that fits your organization before choosing either path.
What should a fixed-scope quote from DeployOpen include?
A fixed-scope quote follows from written scope, so ask for the scope, deliverables and timeline before any fee. Request the inventory of services, hosts and clusters in scope, the signals to cover (metrics, traces and logs), and the target architecture for the Collector, Prometheus, Alertmanager, Loki and Grafana. Ask which dashboards, alert rules and notification channels will be rebuilt, how data retention and backup are handled, and how security settings such as authentication and TLS are hardened. Confirm the handover items, the documentation delivered and whether ongoing support or upgrades are covered by a separate retainer. DeployOpen does not publish a price list.
Does DeployOpen certify or audit the observability stack for compliance?
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. For an observability stack, useful evidence includes access logs for the dashboards, retention settings, backup test records, change records for alert rules and authentication configuration. Ask your auditor which of these they expect before the engagement starts, and include that evidence in the written scope so the work is planned around it.
Where the open stack needs extra components or has gaps
The open stack covers most of what Splunk Observability Cloud does, but several gaps sit in licensing tiers, language maturity, storage design and high availability behavior. Each card below names one gap and the check to run against your own requirements before you commit to a design.
Enterprise-only SAML and SCIM
Grafana's authentication docs say LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy and JWT work in every edition, while SAML, team sync, active sync and SCIM provisioning are limited to Grafana Enterprise and Grafana Cloud. If your identity policy requires SAML sign-on or automated user provisioning, the open edition will not meet it without a paid tier or a gateway in front. Confirm which identity method your audit scope requires, then price Grafana Enterprise against that need.
Uneven OpenTelemetry log SDK maturity
OpenTelemetry trace APIs and SDKs are stable in most languages, including Go, Java, Python and .NET, but log SDK maturity varies more and several languages are still in development. Application teams that rely on OpenTelemetry for logs may need a bridge from an existing logging library or a fallback to a shipper such as Fluent Bit. Check the status page for each language in your estate before you set log collection as a single pattern.
Mixed component stability in the Collector
Core OpenTelemetry Collector components carry mixed stability levels, and each component's README states its level. A pipeline built on a beta receiver or processor can change configuration between releases, which adds upgrade testing to the operations plan. Inventory every receiver, processor and exporter in your configuration, record its stability level, and pin the distribution version you test against.
Prometheus is not for exact counts
The Prometheus documentation says it values reliability over precision and is not a good fit where 100% accuracy is required, such as per-request billing. Metrics that drive invoices, regulatory reports or financial reconciliation need a different source of truth or a counting path outside Prometheus. Decide which of your dashboards and alerts are approximate by design, and keep exact counting in an audited system.
Single-node Prometheus storage
Local Prometheus storage is not clustered or replicated and should be operated like any single-node database. Long retention, high availability and cross-site queries need remote write to an external long-term store, which becomes another component to size, secure and back up. Ask who owns the remote storage, how it is replicated, and what happens to alerting when a Prometheus server is lost.
Grafana HA and alert deduplication
Grafana high availability uses two or more active-active servers behind a load balancer on a shared MySQL or PostgreSQL database. The docs note that Grafana Live has limitations in HA and that alerting needs extra configuration to avoid duplicate notifications. Test live panels and alert routing on a multi-node setup before production, and confirm that Alertmanager grouping and inhibition cover the duplicate paths you introduce.
When keeping Observability Cloud is still the better choice
Keeping Splunk Observability Cloud is the better choice when your team has little appetite for operating telemetry components itself, or when the value you get from the product depends on vendor-specific features you have not yet verified in your own environment. A self-hosted stack built on OpenTelemetry, Prometheus, Loki and Grafana is a set of separate components. Each one needs versions tracked, upgrades scheduled, storage sized and on-call coverage. If nobody on your platform or SRE team wants that work, a managed service may cost less in attention even when the license line looks higher on paper.
The second case is less obvious. Before you commit to a migration, confirm that every capability your teams rely on has an equivalent. Splunk lists Observability Cloud as a separate product that correlates metrics, traces and logs in one place, so check how your teams use that correlation today. Ask the vendor which detectors, dashboards, trace analysis views and alert routing features your engineers actually open each week, and whether any of them depend on proprietary behavior. Confirm the same for any integrations, such as incident tooling or single sign-on, that you would have to rebuild.
A practical step is a capability test against your own workloads before deciding. Pick a representative service, instrument it with the OpenTelemetry Collector, send metrics to Prometheus and logs to Loki, and rebuild the three or four dashboards and alerts that matter most in Grafana. Record which tasks took unexpected effort, which features had no direct equivalent and how long your team spent on each. Use those results to ask a managed provider for a written scope and to decide whether the operating model suits your organization. Either outcome is a valid decision if it rests on evidence from your own environment.
How DeployOpen scopes and delivers an observability migration
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Open-source alternative to Splunk Observability Cloud, that means mapping your current metrics, traces and logs to an OpenTelemetry, Prometheus, Loki and Grafana stack that runs in your cloud account, data center or air-gapped network.
How we scope
- Inventory of Splunk Observability Cloud sources, dashboards, detectors and alert routes, with each item marked as one to one, needs an extra component, or has no direct equivalent.
- Written scope listing which services, environments and telemetry types are in the migration, and which Splunk features are out of it.
- Agreed deliverables and timelines in writing before work starts, since most engagements are fixed-scope and priced from that scope.
How we build
- Deploy OpenTelemetry Collectors as agents or gateways, with receivers, processors and exporters configured for your sources and tested against sample telemetry.
- Set up Prometheus, Alertmanager, Loki, Tempo or Jaeger storage and Grafana with provisioned data sources, dashboards and alert rules kept as code.
- Test authentication, network paths, retention settings and alert routing, and apply Grafana and Collector hardening guidance to the deployed systems.
How we hand over
- Documentation of the architecture, configuration files, data flows, retention policies and the upgrade and backup procedures for your team.
- Side-by-side validation that dashboards, alerts and telemetry from both platforms agree before any Splunk feed is switched off.
- A handover session with your platform and on-call engineers covering day-to-day operations, runbooks and how to request changes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so component versions and security patches keep pace with releases.
- Backups and upgrade planning for Prometheus, Grafana and Collector components, scoped in the same written agreement as the migration.
- Ask us to confirm which support tier, response expectations and out-of-scope items apply before signing, since these depend on your written scope.
