Which open-source alternative to Datadog fits your situation
For most teams replacing Datadog, the best fit is a self-hosted stack built on the OpenTelemetry Collector, with Prometheus or Grafana Mimir for metrics, Grafana for dashboards, and either Jaeger or SigNoz for traces. This combination keeps the telemetry format vendor-neutral and moves storage and query control into your own infrastructure. Whether it is the right choice depends on what is forcing the decision: a renewal, a pricing change, a data residency requirement or lock-in to proprietary agents and backends. Datadog runs as a hosted service in separate regional sites, including US1, US3, US5, EU1, AP1, AP2, UK1, US1-FED and US2-FED. Datadog's documentation states that each site is completely independent and data cannot be shared across sites, so if your residency rules require a specific region, confirm which site your organization is on and whether any telemetry, including logs and traces, leaves that region. The Datadog Agent is open source under Apache-2.0 for its user space components, but the Datadog backend and UI are not, so the part you can read and fork is the collection layer, not the platform where your data is stored, queried and alerted on.
The practical lever is that Datadog accepts OpenTelemetry data through the Datadog Agent with its DDOT Collector, through a standard OpenTelemetry Collector pipeline exporting over OTLP, or by direct OTLP ingestion. If your services already emit OTLP, you can keep that instrumentation and point it at a self-hosted Collector instead, which makes the move mostly a backend change. Before you commit, inventory which services still depend on Datadog-specific tracers, custom metrics or proprietary tags, because those will need rework. Ask your team to confirm which of these paths their current Datadog setup uses and whether the Collector configuration can be reused for a parallel run during cutover.
Which open-source options replace Datadog's core use cases
Datadog bundles infrastructure metrics, traces, logs and dashboards into one hosted product. A self-hosted replacement splits those jobs across separate components, each with its own license, operator and failure mode. The cards below map each job to an open-source component and note where it fits and what to verify before committing.
OpenTelemetry Collector
The Collector is a vendor-neutral pipeline that receives, processes and exports telemetry. It is not a backend, so it stores nothing and answers no queries. Use it as the single entry point for applications and hosts, then fan out to Prometheus, Jaeger and a commercial endpoint during a cutover. Check which receivers, processors and exporters your teams need, and who will maintain the collector configuration as a versioned artifact.
Prometheus for infrastructure metrics
Prometheus is an Apache-2.0 CNCF monitoring system that scrapes metrics over HTTP and queries them with PromQL. It fits host, container and service metrics and the alerting rules that Datadog monitors usually cover. It can receive OTLP metrics when started with --web.enable-otlp-receiver. Its local storage is designed for recent data, so long retention needs a separate store. Confirm your cardinality profile before moving custom metrics across.
Grafana with Mimir for dashboards
Grafana provides dashboards, alerting and exploration across Prometheus, Jaeger and log stores. Mimir adds horizontally scalable long-term storage for Prometheus metrics. Both are AGPL-3.0-only: Grafana moved from Apache-2.0 in 2021, starting with Grafana 8.0. Self-hosting them is allowed, but legal review should confirm that modifications and network-served use fit your policies. Plan for an operator who owns upgrades, retention and query performance.
Jaeger for distributed tracing
Jaeger is an Apache-2.0 distributed tracing backend and a CNCF graduated project. Jaeger v2 is built on OpenTelemetry Collector components, which simplifies running collector and storage together. It covers the trace-search and service-dependency work of Datadog APM. It does not cover log management or metric dashboards, so pair it with Grafana. Confirm the storage backend you choose, since trace volume drives its sizing.
SigNoz as a single platform
SigNoz is an OpenTelemetry-native platform covering metrics, traces and logs in one interface, which reduces the number of components to operate. Its license is open core: code outside the ee/ and cmd/enterprise/ directories is MIT, while code inside them falls under a separate enterprise license. Verify which features you need sit in the MIT portion, and review the enterprise terms before depending on them. Check its maturity against your required Datadog features such as synthetic monitoring and anomaly detection.
Datadog Agent source code
The Datadog Agent is open source: its user space components are Apache-2.0 and its eBPF code is GPL-2.0. This lets you audit and build the agent, but it does not give you a self-hosted backend. Datadog's hosted service, UI and query layer remain proprietary, so dashboards, monitors and stored data still live in Datadog. Treat the open agent as a transition tool that ships data to Datadog, and plan a separate backend before you remove the commercial endpoint.
How each Datadog capability maps to self-hosted tools
This table maps each main Datadog capability to the self-hosted open-source tools that usually cover it, with gaps marked. Read the gap column first, because synthetics, real user monitoring and many integration catalog items need separate tools or custom work, and every feature should be confirmed against current project documentation.
| Datadog capability | Open-source option | Coverage and gaps |
|---|---|---|
| Infrastructure metrics and host monitoring | Prometheus with node_exporter, OpenTelemetry Collector hostmetrics receiver | Strong coverage for hosts and Kubernetes metrics. Confirm exporter availability for each system you run. |
| Container and Kubernetes monitoring | Prometheus with kube-state-metrics, Grafana dashboards | Covers cluster and workload metrics well. Autodiscovery and tagging differ from the Datadog Agent, so plan relabeling rules. |
| APM distributed tracing | Jaeger or SigNoz, fed by OpenTelemetry SDKs and Collector | Tracing is covered by both. Confirm which trace storage backend fits your volume and retention needs. |
| APM service maps | SigNoz, or Jaeger with Grafana trace views | Gap to confirm: service maps are built in to SigNoz. With Jaeger, expect more assembly work and check current dependency graph features. |
| Log management | SigNoz, or Grafana Loki with the OpenTelemetry Collector | Gap to confirm: logs need a dedicated store, and Loki or SigNoz each have different query and index models. Plan retention separately. |
| Dashboards | Grafana, with SigNoz dashboards for trace and log views | Grafana covers metrics dashboards well. Datadog dashboards do not export directly, so expect a rebuild. |
| Alerting and monitors | Grafana Alerting, Prometheus Alertmanager | Strong for metric alerts. Log and trace alerts depend on your backend, so confirm each monitor type before cutover. |
| Synthetic checks | Blackbox exporter, or a separate synthetic testing tool | Gap: no single open-source tool matches Datadog Synthetics. Expect separate tooling or custom scripts. |
| Real user monitoring | OpenTelemetry browser instrumentation, or a dedicated RUM tool | Gap: RUM usually needs separate tooling or custom work. Confirm session replay and frontend error needs. |
| Security monitoring and cloud integrations | Wazuh or Falco for security events, cloud exporters for AWS, Azure and GCP | Gap: Datadog's integration catalog is broad. Inventory your integrations and confirm an exporter or custom collector exists for each. |
How the parts fit together in a self-hosted stack
The core of a self-hosted replacement for Datadog is a single OpenTelemetry Collector that sits inside your network and receives all telemetry before anything is stored. Applications instrumented with OpenTelemetry SDKs, and hosts still running the Datadog Agent, send OTLP to the Collector. The Collector then fans out by signal: metrics go to Prometheus or Mimir, traces go to Jaeger or SigNoz, and logs go to a log store you choose and operate. Keeping the Collector as the single fan-out point means a backend can be swapped later without touching every service. If you already have Datadog OTLP exporters, you can repoint them at the Collector's OTLP endpoint in the same way, so the change happens in one configuration layer rather than in each application. Confirm the exporter settings your current Datadog OTLP configuration uses, since Datadog's OpenTelemetry documentation describes several ingestion paths and each needs a different change.
The trust boundary sits at the Collector. Everything upstream of it, including application workloads, Agent hosts and any service account they use, is inside your network and is where you decide what data leaves at all. Traffic from the Collector to the storage backends should stay on private addresses, with mutual TLS between components and access to Grafana restricted through your identity provider. Decide early which attributes carry personal data, such as user identifiers in span tags or query text in logs, and filter or hash them in the Collector's processors before they reach storage. Data residency is the reason many teams keep this boundary on their own infrastructure: Datadog runs in separate regional sites that do not share data, so a self-hosted stack lets you choose the location and retention policy directly. Ask your security team to document where each component runs, who can read each store, and how long each signal is kept.
What a self-hosted Datadog replacement costs over several years
This table compares the recurring and one-time cost components of staying on Datadog with those of running OpenTelemetry, Prometheus, Grafana and a trace backend yourself. Read each row for who is paid, whether the cost recurs, and which driver moves it most. No Datadog or DeployOpen prices appear here, so use the rows to build the questions you send in a quote.
| Cost component | Who is paid or what carries the cost | One-time or recurring | Main cost drivers |
|---|---|---|---|
| Datadog subscription and usage billing | Datadog, under your agreement, for hosts, ingested logs, indexed logs, custom metrics and APM usage | Recurring | Host count, log volume and retention, custom metric cardinality, APM span volume, and the number of regional sites you run |
| Compute for collectors and storage backends | Your cloud provider or data center team for the VMs or Kubernetes nodes running the OpenTelemetry Collector, Prometheus, Mimir or Jaeger | Recurring | Samples per second, active series, span throughput, query load and replication factor |
| Object storage and long-term retention | Your storage provider for metric blocks, trace data and log indexes kept beyond short local retention | Recurring | Retention period, data volume per day, compression behavior and the number of copies kept for resilience |
| Software licensing | No license fee for Apache-2.0 components such as OpenTelemetry Collector, Prometheus and Jaeger. Grafana and Mimir are AGPL-3.0-only, so confirm with counsel what your use requires. SigNoz enterprise directories need a separate license. | Recurring only if you buy enterprise features or support | Which open core features you need, and whether you modify and distribute AGPL components |
| Implementation and dashboard rebuild | Your platform engineers, or a partner under a fixed-scope written agreement such as DeployOpen's, for collector pipelines, dashboards, alerts and runbooks | One-time | Number of Datadog dashboards, monitors and integrations in use, and how many teams own them |
| Agent-to-OpenTelemetry migration and dual-running | Your application and platform teams, plus the infrastructure for running Datadog and the new stack in parallel | One-time for the cutover, with temporary recurring cost while both stacks ingest | Length of the parallel run, duplicate telemetry volume, and the number of services still on the Datadog Agent |
| Support and internal skills | Your staff time for on-call and upgrades, and any paid support or retainer you choose for the self-hosted stack | Recurring | Team size, on-call coverage expectations, upgrade frequency and retainer scope |
| Data residency and regional hosting | Your own infrastructure in the region you choose, instead of a Datadog regional site | Recurring, and set during design | Which regions must hold telemetry and whether logs contain personal data that changes retention rules |
What you give up when you leave Datadog and how teams compensate
Moving from Datadog to a self-hosted stack swaps a managed, integrated product for components you assemble and operate yourself. Each card below names one capability you lose or take on, the workaround teams usually use, and what to confirm before you commit.
Vendor-managed anomaly detection
Datadog's built-in watchdog-style detection flags unusual behavior without you writing the rules. On a self-hosted stack, you typically rebuild this with Prometheus alerting rules, recording rules for baselines, or a separate anomaly engine. Expect to tune thresholds per service, since no vendor model arrives preconfigured. Confirm with your team which alerts must survive cutover and which ones you can retire.
Fewer prebuilt integrations
Datadog ships many turnkey integrations with dashboards and monitors already included. Self-hosted, you rely on community exporters, OpenTelemetry Collector receivers, or your own scrape configs, and each one needs validation against your versions. Inventory every integration you use today, then check whether a maintained receiver exists for it. Plan time for the ones that do not.
One unified UI across signals
Datadog correlates metrics, logs and traces in one interface, so an engineer can move from a latency spike to the trace and log lines behind it. Open-source setups split these across Grafana, Jaeger and a log store, unless you choose an OpenTelemetry-native platform such as SigNoz. Correlation depends on consistent trace IDs and shared resource attributes in your telemetry. Test that path end to end before you retire the Datadog view.
Managed SLAs and vendor support
With Datadog you buy uptime commitments and a support contract for the platform itself. In a self-hosted model, availability of the monitoring stack becomes your responsibility, and external support is a separate contract with a vendor, a support company, or DeployOpen under a written scope. Ask any provider which response times and escalation paths they commit to in writing. Do not assume a community project carries a support obligation.
Operating storage, upgrades and capacity
Datadog absorbs ingest scaling, retention tiers and version upgrades. Self-hosting moves those into your team's calendar: Prometheus or Mimir capacity planning, backup and restore tests, component upgrades, and on-call coverage for the pipeline itself. This is usually the largest recurring cost in the move, so count engineer hours for it, not only hardware. Ask whether your platform team has the skills and rota to own it.
License review for AGPL components
Several strong open-source options use copyleft licenses that change obligations if you modify and offer them as a network service. Grafana and Grafana Mimir are AGPL-3.0-only, and the Grafana relicensing from Apache-2.0 took effect in Grafana 8.0. Jaeger and Prometheus are Apache-2.0, and SigNoz has an MIT core with an enterprise directory under separate terms. Have legal review how each component is used, modified and exposed internally or to customers before you standardize on it.
How to move from Datadog to a self-hosted stack step by step
This sequence moves Datadog metrics, traces, logs and alerting onto a self-hosted stack in controlled stages, so each stage can be checked against the Datadog data it replaces before the subscription is retired. Each step has a defined output that gates the next.
Inventory hosts, services, dashboards, monitors and log pipelines
Platform engineering and service owners list every Datadog-monitored host, containerized workload, service, dashboard, monitor, notebook and log pipeline, and record which team owns each one. Start by confirming which Datadog site your organization uses, since the Datadog documentation states that each regional site is completely independent and data cannot be moved or shared between sites. Plan the target stack inside the same jurisdiction and account boundaries your data residency rules require. The step is done when every item has an owner, a criticality rating and a named replacement target, and the list has been reviewed by the on-call leads.
Export dashboard and monitor definitions to Grafana and Prometheus
Engineers export dashboard and monitor definitions through the Datadog API or their infrastructure-as-code tooling, then translate them into Grafana dashboards and Prometheus alerting rules. Expect manual rework: Datadog query syntax, tag semantics and monitor thresholds do not map one to one onto PromQL, and some monitor types, such as anomaly or composite monitors, need a redesign rather than a copy. Confirm with your Grafana and Prometheus versions which alerting features your team depends on. The step is done when each monitor has a written equivalent or a documented decision to retire it, and the translated rules load without errors in a test environment.
Deploy the OpenTelemetry Collector and move agents to OTLP
The platform team deploys the OpenTelemetry Collector in the target environment with receivers for OTLP and Prometheus scrape targets, and exporters for Prometheus or Mimir (metrics), Jaeger or SigNoz (traces) and the log backend you selected. For Datadog-side collection, choose between keeping the Datadog Agent with its DDOT Collector, running a standard Collector pipeline that exports OTLP to Datadog during the transition, or sending OTLP directly to Datadog. Application teams then switch their SDK exporters to OTLP. The step is done when a test workload produces traces, metrics and logs in the self-hosted backend with the expected resource attributes.
Pilot one non-critical service end to end
Choose one service with moderate traffic, a clear owner and at least one dashboard and one monitor already in Datadog. Instrument it with OpenTelemetry, route its telemetry through the Collector to the self-hosted backend, and rebuild its dashboard and alert in Grafana. Document every gap you find, such as missing tags, sampling differences or log parsing changes, and fix the pipeline configuration rather than the dashboard alone. The step is done when the owner signs off that the self-hosted view answers the same operational questions as the Datadog view for that service.
Run dual-shipping with a comparison period
Configure the Collector to send the same telemetry to Datadog and to the self-hosted stack at the same time. During the comparison period, the team checks that metric values, trace counts, log volumes and alert firing behavior agree within the tolerance the owners agreed in advance. Dual-shipping increases ingest on the Datadog side, so confirm with Datadog how the extra volume affects your bill before enabling it for all services. Define the length of the comparison period with the engineering and operations leads, based on how often your system experiences the peak loads and incidents you need to see. The step is done when all in-scope services show documented agreement and no unexplained gaps remain.
Cut over alerts and on-call routing
Move paging for each service from Datadog monitors to the Grafana or Prometheus alerting path, updating notification policies, escalation chains and on-call integrations one service at a time. Keep the Datadog monitor active but silenced or routed to a log-only channel for a short overlap, so that a missed page can be detected. Test each escalation path with a controlled alert before the cutover is final. The step is done when every production page reaches the on-call rota from the self-hosted stack, the test alerts were acknowledged, and the owners have confirmed the runbook links point to the new dashboards.
Decommission Datadog agents and retire the subscription
Once all services report through the self-hosted pipeline and the overlap period has closed, remove the Datadog Agent from hosts and containers, revoke API and application keys, and export any historical data you need for retention or audit before access ends. Check your contract for the term end date and notice requirements with your Datadog account team, and confirm what happens to data retained on the Datadog side after termination. The step is done when no Datadog agents report, the keys are revoked, the exported records are stored in your own environment, and the contract termination is confirmed in writing.
Which option fits by reason for leaving Datadog
Datadog runs separate regional sites, and its documentation states that each site is completely independent and data cannot be shared across sites. If your requirement is that telemetry stays in a specific country or cloud region, the question is which site your data lands in today and whether that site meets your obligations. A self-hosted stack moves the storage and query path into infrastructure you choose, so the region is set by your own deployment.
- Collector placement: Run the OpenTelemetry Collector inside the region so traffic never leaves it before storage.
- Storage location: Place Prometheus, Mimir, or ClickHouse-backed SigNoz storage in the same region and account boundary.
- Backups and replicas: Confirm that snapshots and disaster recovery copies also stay in the permitted regions.
- Support access: Decide who can reach the cluster from outside the region, since remote troubleshooting can move data too.
Before committing, confirm with your legal and privacy team which telemetry fields count as personal data, and map each one to a region in the design.",
Datadog pricing depends on the products you enable and the volume and retention you configure, so cost often grows as teams add hosts, logs and custom metrics. A self-hosted stack shifts that spend to infrastructure you own, where storage and retention become your engineering decisions. Mimir suits long-term, high-cardinality metrics, while SigNoz keeps traces, metrics and logs in one place. Neither removes the work of sampling and retention design.
- Metrics at scale: Mimir is AGPL-3.0-only and horizontally scalable, which helps when you need long retention for Prometheus data.
- Single-pane storage: SigNoz is open core, with code outside the ee/ and cmd/enterprise/ directories under MIT, so review which features sit in the enterprise license.
- Sampling and filtering: Use Collector processors to drop noisy spans and logs before they reach storage.
- Hidden recurring costs: Budget for compute, storage growth, upgrades and on-call time, which recur every month.
Ask any implementation partner for a quote that separates one-time build work from recurring infrastructure and support, and compare it against your current Datadog invoices line by line.
Teams that need telemetry shaped for internal systems often find that a fixed vendor catalog limits them. The open components are built to be extended: OpenTelemetry provides the Collector and SDKs for custom receivers, processors and exporters, Prometheus exposes a scrape model and PromQL, and Grafana builds dashboards and alerts on top of those sources. The trade-off is that you own the code you write and must maintain it through upgrades.
- Custom exporters: Write exporters or use the OpenTelemetry Collector pipeline to route data to internal systems.
- Metric shaping: Use Prometheus recording rules and relabeling to build the series your teams query.
- Dashboards as code: Keep Grafana dashboards and alert rules in version control so changes are reviewed.
- Tracing depth: Jaeger v2 is built on OpenTelemetry Collector components, which keeps the tracing pipeline consistent with the rest of the stack.
Confirm which Datadog integrations your teams depend on and whether each one has an OpenTelemetry receiver or Prometheus exporter that you can maintain.
In regulated environments, the monitoring stack often holds production logs and access records, so it falls inside audit scope. Self-hosting gives you direct control over access control, audit logging and retention settings, but it also makes you responsible for proving those controls work. DeployOpen prepares systems, controls and evidence for compliance assessments, while independent auditors and certification bodies issue any attestations or reports.
- Access control: Use your identity provider for Grafana and the query tiers, and restrict who can change alert rules and data sources.
- Audit logging: Enable logs for administrative and query actions, and forward them to a tamper-resistant store.
- Retention settings: Set retention per data class so telemetry is kept only as long as your policy requires.
- Evidence collection: Record configuration baselines and change history that an auditor can sample.
Ask your auditor which control evidence they expect for monitoring systems before you design the stack, since the expected evidence shapes the setup.
Questions teams ask before moving off Datadog
How much effort does moving off Datadog take?
The effort depends mainly on how many services, hosts and dashboards you run, and on how many of them already emit OpenTelemetry data. Teams that still rely on the Datadog Agent and its integrations need to replace collection, while teams already sending OTLP mostly need to point exporters at a new backend. Other drivers include the number of alert rules, the saved queries and dashboards that people depend on, the log pipelines with custom parsing, and how many on-call runbooks link to Datadog views. Ask any partner to inventory these four areas before quoting, because they set most of the work.
Can our own engineers migrate off Datadog without outside help?
Many teams can, provided they have someone who owns the OpenTelemetry Collector configuration, someone who can rebuild dashboards in Grafana, and someone who can own Prometheus or Mimir storage sizing and upgrades. The harder parts are usually not the installation but the ongoing operation: retention planning, high-cardinality metrics, access control, backups and alert tuning. Outside help is most useful for a fixed scope such as the collector design, the migration of a defined set of dashboards and alerts, or hardening and documentation. Decide which of these your team has the time and skills to run after handover.
How long should a parallel run last during cutover?
There is no fixed duration, and any figure you are given should be treated as a planning assumption rather than a rule. A parallel run lasts until the self-hosted stack has covered the signals and alerts your on-call and compliance processes need, and until the team has compared results for a full range of normal and peak load. Key factors are how often your services deploy, how many alert rules must be proven equivalent, how long your longest audit or incident review window is, and how quickly Datadog costs can be reduced once a service has moved. Agree the exit criteria in writing before the run starts.
Do our existing OpenTelemetry instrumentation changes need to be rewritten?
Usually not for application code. Datadog documents three ways to accept OpenTelemetry data: through the Datadog Agent with its DDOT Collector, through a standard OpenTelemetry Collector pipeline exporting over OTLP, or by direct OTLP ingestion. Applications instrumented with OpenTelemetry SDKs emit the same OTLP data regardless of backend, so the main change is in the collector or exporter configuration. Applications still using Datadog-specific tracing libraries or custom metric names will need changes, and naming conventions should be checked so dashboards and alerts map cleanly. Confirm each item against the current Datadog OpenTelemetry documentation for your language versions.
How do we keep telemetry data inside a specific region?
Self-hosting gives you direct control of where telemetry is stored, because the storage, collectors and dashboards run in your own cloud account, data center or air-gapped network. Datadog runs in separate regional sites, including US1, US3, US5, EU1, AP1, AP2, UK1, US1-FED and US2-FED, and its documentation states that each site is completely independent and data cannot be shared across sites. With a self-hosted stack, you must confirm the region for each component, including backups, object storage used by long-term metrics, and any remote write or external alerting path. Document these locations as part of your data flow inventory.
Does the open-source Datadog Agent give us a backend we can run ourselves?
No. The Datadog Agent source code is open, with user space components under Apache-2.0 and eBPF code under GPL-2.0, but the Datadog backend and UI are not open source. The Agent sends data to Datadog's hosted service, so it cannot replace the storage, query, dashboarding or alerting that Datadog provides. A self-hosted replacement needs a separate backend, typically Prometheus with Mimir for metrics, Grafana for dashboards, and Jaeger or SigNoz for traces, fed by the OpenTelemetry Collector. Review the licenses of each component before adoption, since Grafana and Mimir are AGPL-3.0-only.
What does a fixed-scope engagement need from our side?
A fixed-scope engagement needs written scope, named owners and access to the systems involved before work starts. DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing. Your side should provide an inventory of hosts, services, dashboards, alert rules and log sources, the cloud accounts or networks where the stack will run, decisions on retention and regional placement, and a sign-off contact for each cutover step. Ongoing support, upgrades and continuous testing are available as retainers, and a quote follows from the agreed scope.
How DeployOpen scopes, migrates and supports the replacement
DeployOpen plans and builds self-hosted monitoring inside your own cloud accounts, data centers or air-gapped networks, starting from a written scope. Engagements are fixed-scope, so deliverables, timelines and responsibilities for moving off Datadog are agreed in writing before work begins.
How we scope
- Inventory hosts, containers, APM services, log sources and Datadog monitors, dashboards and notebooks that must be rebuilt
- Record which Datadog site your data lives in and confirm where the replacement must store it
- Agree in writing which telemetry moves first, which runs in parallel and what retires at cutover
How we build
- Deploy the OpenTelemetry Collector, Prometheus, Grafana and a trace backend such as Jaeger or SigNoz in your environment
- Configure dual shipping so the Datadog Agent or OTLP pipeline feeds both platforms during cutover
- Test alert routing, dashboard parity and retention settings against the agreed scope before sign-off
How we hand over
- Document architecture, configuration, data flows, access controls and the cutover runbook for your team
- Deliver the rebuilt dashboards and alert rules with a record of which Datadog equivalents were matched or left as gaps
- Provide evidence of monitoring controls for your compliance team, noting that independent auditors issue any attestation
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Retainers can cover Collector and component upgrades, backups and changes to instrumentation as services evolve
- Ask for the support scope, response expectations and upgrade process in the written quote
