Dynatrace vs SigNoz: which to choose

Dynatrace or SigNoz: which fits your team

Choose Dynatrace if you want automatic discovery, AI-assisted root-cause analysis and the lowest day-to-day operating effort, and you can accept a committed consumption contract. Choose SigNoz if your priority is OpenTelemetry-first instrumentation that you control, with the core product running in your own environment under an MIT-licensed core. Most teams in a renewal or data residency review are weighing those two priorities, and the answer usually turns on who will operate the platform after go-live.

Dynatrace fits teams that have many services, limited time to instrument them by hand, and a need for dependency mapping and problem detection that works out of the box. OneAgent discovers processes and technologies automatically, and its AI root-cause analysis reduces the triage work an in-house team would otherwise carry. Its Platform Subscription can also be shared across SaaS and Managed deployments, which matters if you already run Managed inside your network. The cost is a multi-year commitment and a rate card you must model against real telemetry volumes before you sign.

SigNoz fits teams that have decided to standardize on OpenTelemetry, want traces, logs and metrics in one application, and need to keep telemetry in infrastructure they operate. Its Community Edition is self-hosted and covers APM, tracing, logs, infrastructure monitoring and alerting, but SAML, anomaly detection and prebuilt integrations sit in paid tiers, and community Slack is the only free support. The decision then turns on three questions: whether your team can run ClickHouse-backed storage, scaling and upgrades, whether you need enterprise-tier features such as SAML, and whether losing OneAgent's automatic coverage is acceptable. Confirm each answer against the current SigNoz pricing page before you commit.

Which option fits which scenario

This table maps common decision scenarios to the option that fits better and the reason, drawn from the documented facts about each product. Read each row as a starting point for your own evaluation, then confirm the points marked for verification against current vendor terms and your own environment. The main takeaway is that the choice often depends on contract timing, data location and how much platform staff you can commit to running the stack.

Scenario	Better fit	Reason
DPS renewal approaching	Depends on contract timing	DPS commitments run typically 1 to 3 years with a minimum annual commitment, so model the remaining term before choosing SigNoz for new workloads.
Team already instrumented with OpenTelemetry	SigNoz	SigNoz is OpenTelemetry-native, and Dynatrace also ingests OTLP, so the same telemetry can feed both during a trial.
Air-gapped or strict data residency	Dynatrace Managed or self-hosted SigNoz	Dynatrace Managed runs in your environment with offline mode. Self-hosted SigNoz keeps data in your infrastructure, but your team runs storage, upgrades and backups.
Need for SAML single sign-on	Dynatrace or SigNoz Teams and Enterprise	SigNoz lists SAML only on its Teams and Enterprise plans, not the Community Edition. Confirm SAML terms for each Dynatrace deployment.
Need for anomaly detection	Dynatrace	SigNoz Community Edition excludes anomaly detection. Confirm which SigNoz paid tier, if any, includes it before relying on it.
Need for SOC 2 or HIPAA compliance evidence	Confirm with each vendor	SigNoz lists SOC 2 and HIPAA as excluded from the Community Edition. Ask Dynatrace and SigNoz for current attestation reports.
Small team with no platform staff	Dynatrace or SigNoz Cloud	Self-hosted SigNoz places install, scaling, upgrades and backups on your team. A hosted option shifts that operating work to the vendor.
Strong platform engineering team, cost-sensitive	Self-hosted SigNoz	The Community Edition is MIT-licensed outside the enterprise directories and has no license fee, though you pay for infrastructure and staff time.
Need for automatic discovery and root-cause analysis	Dynatrace	OneAgent-based discovery and AI root-cause analysis are Dynatrace strengths. Plan for manual instrumentation and dashboards on SigNoz.

Where your telemetry lives and who controls it

Dynatrace and SigNoz differ most in where the data physically sits and who operates the platform. The cards below set out the deployment options on each side, the identity features tied to each plan, and where DeployOpen's compliance work stops and an auditor's begins.

Dynatrace SaaS and Managed

Dynatrace runs as SaaS, or as Dynatrace Managed in an environment the customer operates, and a Dynatrace Platform Subscription can be shared across both. Under Managed, your team carries upgrades, capacity and backups for the cluster. Confirm with Dynatrace which region or environment will hold your data, which components sit inside your network, and how an offline or air-gapped deployment would be licensed before you assume data never leaves your estate.

SigNoz self-hosted on Docker or Kubernetes

The self-hosted Community Edition installs with Docker Standalone, Docker Swarm or Kubernetes with Helm. Telemetry is collected by the SigNoz OpenTelemetry Collector and written to ClickHouse, so your team owns the database, storage sizing, retention and backups. Ask who will patch ClickHouse and the API server, and whether your cluster can meet the storage and availability targets you set for production.

SigNoz Cloud regions and BYOC

SigNoz Cloud stores data in US, EU or India data centers on its Teams plan, which keeps data in the region you choose. Enterprise adds SigNoz Cloud Dedicated and BYOC, where SigNoz manages the platform inside your cloud account. Check which region your data will land in, who holds the cloud account credentials, and whether a BYOC deployment changes your data processing agreement.

Single sign-on and SAML plans

SigNoz lists SSO on every plan, including the free Community Edition, but SAML is available only on the Teams and Enterprise plans. Dynatrace identity is set through its own tenant and identity provider configuration. Map each console role to an identity group before cutover, and confirm that the plan you pick supports the SAML flow your identity provider requires.

Compliance readiness versus audit

DeployOpen prepares systems, configuration, access controls and evidence for compliance assessments, including the logging, retention and access records a SigNoz deployment must produce. It does not issue audit reports, attestations or certifications. SigNoz's pricing page says its Community Edition does not include SOC 2 or HIPAA compliance, so ask SigNoz what it can provide for your assessment and have your independent auditor confirm what evidence they accept.

Operating responsibility split

On a SigNoz self-hosted install, your team or a partner owns upgrades, ClickHouse tuning, backups and the collector pipeline. On Dynatrace SaaS, the vendor runs the platform and your team owns instrumentation and configuration. Write the split into the scope before you start, naming who holds on-call for the telemetry stack and who approves each upgrade.

How the two platforms are built

Dynatrace is built around OneAgent, a single agent deployed on hosts and nodes that discovers processes, services and dependencies automatically and injects instrumentation without code changes. Telemetry flows into the Dynatrace platform, which correlates traces, metrics and logs against an entity model it builds from what it finds. Dynatrace also ingests OpenTelemetry data through its OTLP API, including direct export from applications to Dynatrace endpoints, so teams can send OpenTelemetry signals alongside or instead of OneAgent data. The same platform is offered as SaaS or as Dynatrace Managed, which runs in your environment.

Discovery: OneAgent detects services and their relationships with little manual configuration, which is the main reason teams cite for its automatic topology.
OTLP ingest: Traces, metrics and logs from OpenTelemetry SDKs or a Collector can be sent to Dynatrace endpoints over OTLP.
Entity model: Telemetry is mapped to entities such as hosts, processes and services, which drives problem detection and root-cause analysis.
Deployment: SaaS or Managed, with the same consumption subscription shared across both where your contract allows it.
Operations: Agent updates, platform upgrades and data retention are handled by Dynatrace in SaaS, while Managed moves that work to your team.

Before you rely on this model, confirm which signals your workloads need through OneAgent and which can come through OTLP, and check how each path is licensed under your subscription.

What drives the cost of each option

Dynatrace is paid for under a Dynatrace Platform Subscription (DPS), a consumption-based agreement that customers typically sign for 1 to 3 years with a minimum annual commitment. Usage accrues against that commitment on a per-capability rate card, so the bill follows what you consume in each capability, such as APM, logs or infrastructure monitoring, rather than a flat seat count. The Dynatrace documentation on DPS describes the model. When you request a quote, ask for the rate card for each capability you use, the size of the minimum annual commitment, whether unused commitment carries over, and whether the same DPS can be drawn on by both SaaS and Managed deployments. Those terms decide what an early exit from the commitment costs.

SigNoz costs split into three different shapes. The Community Edition is free to license, but you pay for the servers or cluster that run the OpenTelemetry Collector, ClickHouse, the API server and Alertmanager, for storage and retention on that ClickHouse data, and for the staff time that installs, upgrades and backs up the stack. Those costs recur and grow with telemetry volume and retention. SigNoz Cloud is metered: the Teams plan is supplied at $49 a month including $49 of usage, with logs and traces at $0.30 per GB ingested and 15-day retention, and metrics at $0.10 per million samples with 1-month retention, according to the SigNoz pricing page. Confirm current rates there, because the per-GB figure drives the bill more than the base fee. SigNoz Enterprise starts at $4,000 a month, also per the SigNoz pricing page, and you should ask whether that figure covers the dedicated, BYOC or self-hosted option you choose and what support is included.

Ask every vendor to model the same telemetry: average GB of logs and traces per month, metric sample counts, retention in days and the number of hosts or services. Then ask what each figure becomes if volume doubles, because consumption pricing and storage growth are the main cost drivers on both sides. For the self-hosted path, ask your own platform team to estimate compute, storage, backup and on-call hours, since no supplied figure covers these for your environment. Dual-shipping OTLP during a trial lets you measure real ingest volume before you sign a DPS commitment or a SigNoz plan.

Cost components on each side

A Dynatrace vs SigNoz cost comparison is a set of separate line items, not one price. Some are paid to a vendor, some to your own staff and cloud accounts, and some only once during migration. Use the cards below to build a like-for-like quote request on both sides.

DPS subscription and rate card

Dynatrace Platform Subscription is consumption-based: you sign an agreement of typically 1 to 3 years with a minimum annual commitment, and usage accrues against it on a per-capability rate card. Ask which capabilities are on the rate card, how overage is billed, and whether unused commitment rolls over. Also confirm whether the commitment can be shared across SaaS and Managed deployments. This is the largest recurring line on the Dynatrace side.

SigNoz Cloud or Enterprise fees

If you choose a hosted SigNoz option instead of running it yourself, the bill is a plan fee plus usage. SigNoz Cloud Teams includes a base amount of usage, while logs and traces are billed per GB ingested and metrics per million samples, with retention limits that differ by signal. Enterprise, including BYOC and Dedicated, is quoted from a higher monthly starting point. Ask which data center region applies and how retention is extended.

Self-hosted compute and ClickHouse storage

Running SigNoz yourself means paying your cloud or data center for the Collector, API server, Alertmanager, query services and ClickHouse nodes. Storage and retention are the main drivers: ingest volume, cardinality, compression and the retention period set how much disk and replication you need. Ask your team to size a test run with your real trace and log volume, and to price replicas and backups separately from compute.

Collector operations and scaling

The OpenTelemetry Collector runs as an agent beside services or as a gateway that accepts data from many sources, and it needs configuration, rollout, certificate and version management. Gateway capacity, queueing and authentication extensions add operating work. Check which Collector components you rely on, since stability levels vary by component, and budget the time to test them before each upgrade.

Upgrades, backups and patching

SigNoz ships releases on a regular cadence, and the Collector publishes its own release line with signed artifacts, checksums and SBOMs. Each upgrade needs a staging test, a rollback plan and a backup of ClickHouse data and configuration. Enterprise self-hosting moves these tasks to your team, while managed options move them to the vendor. Ask any implementation partner to define who performs each task and how often.

Staff time and instrumentation rebuild

Migration is mostly people time: replacing OneAgent with OpenTelemetry instrumentation service by service, dual-shipping OTLP while the DPS commitment runs, and rebuilding dashboards and alerts. Your staff time, any implementation partner fees and the testing effort are one-time costs, while ongoing on-call and platform ownership recur. Request a fixed-scope estimate that lists services, dashboards and alert rules, and the named roles each task needs.

What moving from Dynatrace to SigNoz involves

The sequence turns OneAgent coverage into OpenTelemetry instrumentation that feeds SigNoz in parallel with Dynatrace, then retires Dynatrace only after SigNoz dashboards, alerts and checks match what the team relies on. Each step has a written output so the cutover decision rests on evidence.

Inventory services and OneAgent coverage
Platform engineering and service owners list every application, host and database that OneAgent monitors today, along with the Dynatrace dashboards, problem detection rules, alerting profiles and SLOs each team depends on. Compare that list against what Dynatrace auto-discovers, because some services may be covered only by automatic discovery and will need explicit instrumentation. The output is a service register with owner, language, runtime, current Dynatrace views and a note on which telemetry each service must keep. Confirm with your Dynatrace administrator which configuration can be exported as Monaco files so that alerting logic is captured before anything changes.
Instrument services with OpenTelemetry SDKs
Development teams add OpenTelemetry SDKs or auto-instrumentation to each service, starting with the services that have the clearest owners. Check the OpenTelemetry status page for your language before committing, since trace APIs and SDKs are stable in most languages, while log SDK maturity varies and some languages are still in development. Where a language or framework has gaps, plan manual spans and metrics for the critical paths. The output is a set of services emitting traces, metrics and logs with consistent resource attributes, verified in a non-production environment.
Deploy the OpenTelemetry Collector and SigNoz
Platform engineers install a self-hosted SigNoz instance using one of the documented install paths, then deploy OpenTelemetry Collectors as agents beside services or as a gateway that receives data from many sources. Configure the Collector to export OTLP to SigNoz, and to export to Dynatrace in parallel, so the same telemetry reaches both backends. Secure receivers and exporters using the Collector's authentication extensions and follow the configuration best practices. The output is a running pipeline where a sample trace and metric appear in both systems with matching identifiers.
Dual-ship telemetry during the DPS term
Run both pipelines side by side for the full overlap period while Dynatrace remains under its Platform Subscription. Compare trace counts, error rates, latency percentiles and log volumes between the two backends for each service to find dropped spans, missing attributes or sampling differences. Track consumption in Dynatrace so the overlap does not generate unplanned charges beyond what the commitment covers. The output is a per-service reconciliation report signed off by the service owner. Ask your Dynatrace account team how DPS consumption is metered during dual shipping before the overlap starts.
Rebuild dashboards and alerts in SigNoz
Recreate each Dynatrace dashboard in SigNoz using the Query Builder, PromQL or ClickHouse SQL, depending on what the team already knows. Rebuild every alert from the inventory, including thresholds, notification routing and deduplication, because SigNoz uses Alertmanager for grouping and notification. Anomaly detection and automatic root-cause analysis are not reproduced automatically, so each problem class that Dynatrace detected without configuration needs a written, manually tuned alert or a documented gap. The output is a dashboard and alert catalogue mapped one to one against the Dynatrace inventory, with named gaps and owners.
Validate alerts and cut over
Run controlled tests that trigger each alert in staging and production-like conditions, then confirm that notifications reach the same on-call channels with correct severity. Ask the on-call leads to review the gap list and accept or fund compensating controls for each missing capability. Switch dashboards, runbooks and on-call routing to SigNoz only after the service owners sign off, and keep Dynatrace read-only for a defined fallback window. The output is a signed cutover record listing tested alerts, accepted gaps and the owner of each runbook.
Decommission Dynatrace agents and contract
Remove OneAgent from hosts and services once their telemetry is confirmed in SigNoz, and archive the exported Monaco configuration and dashboard definitions in your own repository. Confirm with the Dynatrace contract owner which commitment terms, data retention periods and export rights apply at the end of the agreement, since historical telemetry usually stays in Dynatrace. Document the final state of the SigNoz deployment, including upgrade and backup responsibilities for your team. The output is an inventory showing zero OneAgent installations, an archive of configuration, and a written statement of what history was retained or lost.

Questions buyers ask before switching

How much effort does a switch from Dynatrace to SigNoz take?

The effort depends mostly on how many services run OneAgent, how many custom dashboards, alerts and automations you rely on, and how much of Dynatrace's automatic discovery your teams use today. Instrumenting applications with OpenTelemetry is per service work, so a fleet of many small services takes longer than a few large ones. Dynatrace's OTLP ingest lets you send the same traces, metrics and logs to both platforms during a trial, which reduces the risk of a cutover but adds work while both run. Ask any implementation partner for a written inventory of services, dashboards, alerts and integrations before agreeing a fixed scope.

How long does a migration to SigNoz usually take?

No duration is fixed by the facts available here, so the timeline is set by your own inventory and your Dynatrace contract. The main drivers are the number of services to re-instrument, how many dashboards and alert rules must be rebuilt, the size of the self-hosted ClickHouse deployment you plan, and how long you run both platforms in parallel. Your Dynatrace Platform Subscription commitment is typically one to three years with a minimum annual commitment, so many teams plan the cutover around that term. Confirm the schedule in writing with whoever delivers the work.

What does the work need from our own engineering team?

Your team needs to own the application changes, because OpenTelemetry instrumentation runs inside your services and build pipelines. Platform engineers need to deploy and operate the SigNoz OpenTelemetry Collector and ClickHouse, which SigNoz documents for Docker Standalone, Docker Swarm and Kubernetes with Helm. Security and compliance staff should review where telemetry is stored, who can query it and how access is granted. Operations staff must also take on upgrades, backups and scaling, which SigNoz lists as the customer's responsibility in its self-hosted enterprise model.

Can our team run the switch alone without outside help?

A capable platform team can run a small switch alone, especially if it has already used OpenTelemetry and Kubernetes. Larger estates usually benefit from an outside implementation partner for the Collector design, dashboard and alert rebuild, hardening and backup setup. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms inside your own infrastructure under fixed-scope agreements, with ongoing support available as a retainer. Whichever route you take, agree the scope, deliverables and handover in writing before work starts.

Does SigNoz include SAML or anomaly detection without the enterprise tier?

No. The SigNoz pricing page says the free, self-hosted Community Edition does not include SAML, SOC 2 or HIPAA compliance, anomaly detection or prebuilt integrations. SAML is available only on the Teams and Enterprise plans, while SSO is listed on every plan, including Community. If you need SAML or anomaly detection on a self-hosted deployment, you should confirm with SigNoz which plan covers it and what it costs, since Enterprise starts at $4,000 a month according to the SigNoz pricing page. Also check whether your identity provider can handle SSO through the options available on the Community Edition.

What happens to our historical Dynatrace data after the switch?

Most collected telemetry history stays in Dynatrace, and it is generally not carried over to SigNoz. Dynatrace's configuration can be downloaded as Monaco configuration-as-code files, and its API gives access to metrics and entities, so you can keep a record of setup and some metric data. Decide early which dashboards, SLO definitions and alert logic you need to keep, and export them before the subscription ends. Plan a retention window for any data you need for audits or incident reviews, and confirm with Dynatrace what export options your contract includes.

What drives the cost of self-hosting SigNoz compared with the Dynatrace commitment?

Dynatrace costs are driven by its Platform Subscription, which is consumption-based against a per-capability rate card with a minimum annual commitment. SigNoz self-hosted has no license fee for the Community Edition, so your costs are the infrastructure for the Collector and ClickHouse, storage and retention settings, staff time for operations and upgrades, and any support contract you choose. SigNoz Cloud Teams starts at $49 a month including $49 of usage, with logs and traces at $0.30 per GB ingested and 15-day retention, according to the SigNoz pricing page. Ask for a quote that separates one-time migration work from recurring infrastructure and staff costs.

How DeployOpen helps evaluate and move to SigNoz

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Dynatrace vs SigNoz, we start with a written scope that tests SigNoz against your real services, telemetry volumes and compliance requirements before any cutover decision is made.

How we scope

Inventory which services, hosts and user journeys currently depend on Dynatrace OneAgent and Dynatrace dashboards
Define which OpenTelemetry signals, retention periods and environments SigNoz must cover in the pilot
Agree in writing which Dynatrace features are out of scope, including anomaly detection and SAML needs
Confirm with SigNoz which edition, license terms and support tier match your identity and compliance requirements

How we build

Deploy a self-hosted SigNoz instance with its OpenTelemetry Collector in your Docker, Swarm or Kubernetes environment
Dual-ship OTLP telemetry from pilot services to Dynatrace and SigNoz so both backends can be compared side by side
Rebuild priority dashboards and alerts in SigNoz's Query Builder, PromQL or ClickHouse SQL, and test alert routing
Configure Collector authentication and secure transport following OpenTelemetry configuration best practices

How we hand over

Document the architecture, data flow, sizing assumptions, upgrade steps and backup procedures for your team
Provide a gap register listing Dynatrace capabilities SigNoz does not replace, with an agreed owner for each
Run knowledge transfer sessions so your engineers can operate SigNoz without relying on our staff
Deliver evidence of configuration and testing that your internal or external auditors can review

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover
Track new SigNoz and OpenTelemetry Collector releases and plan upgrades in your change process
Re-run security testing of the SigNoz deployment and its ingest endpoints on an agreed schedule
Quote follow-on work from a written scope, since DeployOpen does not publish a price list

Dynatrace vs SigNoz