Dynatrace Threat Observability

Name: Dynatrace Threat Observability
Brand: Dynatrace
Rating: 5.1 (4329 reviews)

Leader

Cloud done right.

Est 2005|Valuation $18.4B|Raised $2.1B

LinkedIn 413K|Website|Web traffic 1.3M|FTEs 5,200|HQ Boston, Massachusetts, US

MarketsSecurity Information and Event Management (SIEM)Observability Platform

Dynatrace Threat Observability screenshot

Published May 16, 2026

01Common complaints

1) Organizations that primarily require full-featured SIEM/XDR outcomes (log-centric detection engineering, UEBA, mature SOC case management, and extensive detection content) may prefer established SIEM/XDR platforms and integrate Dynatrace for runtime context. 2) If the security team cannot adopt DQL, Grail, and the associated automation and query workflows, the benefits of Threat Observability will be limited. 3) If strict cost predictability is required for very high ingest volumes and retention needs, and variable cost models are unacceptable, alternative vendors or contractual guarantees should be considered. 4) If the primary need is specialized network performance monitoring rather than integrated observability and security context, a dedicated network monitoring solution may be more appropriate.

Deal disqualifiers (poor fit)

- Organizations seeking a turnkey SIEM with extensive out-of-the-box detections and mature SOC case management without investment in a new query language or workflows; such organizations may favor Microsoft Sentinel/Defender, Splunk Enterprise Security, or Elastic Security for primary detection engineering needs and then integrate runtime context from Dynatrace. - Teams unable to allocate resources to learn and adopt DQL, Grail, and related automation patterns; the capability’s value depends on active hunting and correlation efforts. - Organizations that require strictly fixed-price models for extremely high data ingest and cannot tolerate variable costs tied to data retention and query usage.

1) Platform evolution can require customer work (documented)

Documented migrations (for example, changes to a Grail security events table) required customers to update ingest endpoints, pipelines, queries, and access policies within defined timelines. Customers with custom Threat Observability content may need to refactor artifacts during platform transitions.

2) DQL and Grail maturity concerns (community feedback)

Community comments indicate that DQL and Grail continue to evolve; this can result in shifting best practices and ongoing enablement needs.

3) Pricing and contract minimum risk (anecdotal)

Some customers report annual commitment or minimum spend dynamics that may differ from expectations based on public unit pricing; procurement teams should clarify contract terms and document commitments.

4) Usability issues and UI learning curve (review evidence)

Multiple review sources reference a non-trivial learning curve for new users and desire for improved usability for non-technical stakeholders.

02Why they buy

(Section retained as required; content presented in neutral, objective terms.)

Documented differentiators and recurring user themes

- Contextual enrichment via topology and runtime mapping across the full stack, which Threat Observability leverages to correlate security signals with application and infrastructure context. - A unified data lakehouse (Grail) with a single query language (DQL) for observability and security data, along with ingestion paths for third-party security events via OpenPipeline and normalization via a semantic dictionary. - Documented retention defaults for certain security-event categories (for example, specific retention durations for platform-generated versus ingested events) that may assist investigations and compliance, subject to configuration and plan choices.

Where competitors may have an advantage

SIEM/XDR vendors often provide more extensive prebuilt detection content and mature SOC workflows.
Teams already trained on SPL or KQL may achieve faster initial analyst productivity on SIEM platforms without an investment in a new query language.
Some organizations prefer competitor UX and modular purchasing models for pick-and-choose consumption.

03Field reports

Review platform sentiment (broader Dynatrace product reviews)

Because Threat Observability is a capability within the broader Dynatrace platform, most public review coverage addresses Dynatrace as a whole rather than that specific module. Gartner Peer Insights (Observability Platforms market): - The platform has received a high volume of ratings in the Observability Platforms market listing. Individual review content may be limited without platform access. Some reviewers noted generally positive experiences and responsive support. G2 (Dynatrace reviews): - Public review snapshots indicate generally positive scores across many entries; common praise references automated insights and comprehensive telemetry coverage, while common complaints reference cost at scale. TrustRadius: - Reviews reflect mixed feedback, with some users describing a substantial learning curve for navigation and others citing perceived retention limits or API stability concerns depending on their configuration and version history.

Community feedback (selected paraphrased excerpts)

Community discussions demonstrate variable sentiment:

Negative remarks emphasize UX complexity, perceived feature gaps, noise management, and concerns about pricing and contracting.
More positive or pragmatic remarks note that a single-agent deployment can simplify data collection and that automated baselining can provide default alerts out of the box; such comments are anecdotal and reflect individual experiences.

Why customers choose Dynatrace (themes)

Commonly cited reasons in reviews and community discussions include:

Broad coverage via OneAgent and automated discovery/topology mapping.
Support for root-cause analysis and dependency context.
Capability to deploy at enterprise scale across hybrid environments.

Why some customers leave / churn drivers (themes)

Recurring drivers for dissatisfaction include:

Cost management and budgeting complexity due to data volumes, retention choices, and required modules.
Learning curve associated with the UI and query language.
Perception of noisy or overwhelming problem detection in some environments.
Preference among some users for competitor UX or developer workflows.

Vendor-published claim: security event noise reduction

A vendor-published customer narrative describes a reduction in AWS security event volume from very high daily volumes to a much smaller set of prioritized alerts after contextualization. Critical evaluation: - This narrative illustrates the intended value of context-driven prioritization but is vendor-published and lacks independent validation. - Missing methodology details include how priority was defined, baseline false positive rates, source tools for the original events, whether reductions were achieved through suppression or enrichment-based prioritization, and if any true positives were missed as a result.

Public sector/partner documents (limited evidentiary strength)

Procurement and partner documents reference observability and security benefits, but they rarely isolate Threat Observability outcomes with third-party measurement. Use such materials as directional rather than proof of ROI.

04Best fit

Company size

Typical fit: mid-market to large enterprise organizations with substantial headcount or organizations with complex multi-team platform operations.
Smaller organizations may adopt if they are cloud-native and prioritize consolidation, but cost and complexity may outweigh benefits for smaller teams.

Industries

Industries where the product is commonly considered include:

Financial services and insurance
SaaS and large-scale technology companies
Retail and e-commerce with high uptime requirements
Public sector organizations subject to deployment model and certification alignment

Roles/personas

Decision makers: CISO, VP Security, VP Platform/Infrastructure, Head of SRE, CTO.
Primary users: threat hunters, incident responders, SOC analysts, SREs, platform engineers.
Secondary users: developers reviewing security findings in service and release context.

Pain points the product addresses

High volume of alerts from CSPM/CNAPP/XDR tools with limited runtime context.
Slow triage and investigation due to siloed telemetry.
Need to correlate security signals with actual production service topology.
Desire to automate triage and routing using contextual attributes such as exposure, criticality, and affected entities.

Qualification criteria (good fit)

Existing use of Dynatrace or commitment to standardizing on the Dynatrace platform.
Mature telemetry programs that can support integrating security events in a shared lakehouse.
Willingness to invest in standardized investigations and operational playbooks (DQL queries, notebooks, workflows).

05The pitch

What the product does (objective value proposition)

Dynatrace Threat Observability is a security-focused capability within the Dynatrace platform that consolidates security-relevant signals (both Dynatrace-native and third-party) with runtime and topology context to support detection, investigation, and response workflows while reducing irrelevant alerts. It describes correlation across metrics, logs, traces, events, entities, and security findings stored in Dynatrace’s Grail data lakehouse and queried via Dynatrace Query Language (DQL). Key documented outcomes include reduced alert noise through contextual prioritization, attack-path analysis, and support for threat hunting via contextual enrichment. Vendor messaging and independent validation vary. Key vendor-described capabilities include: - Security Advisor–style automated insights to prioritize threat hunts and scope investigations with runtime context. - Ingestion and investigation of cloud security events from tools like CNAPP/CSPM/XDR/CDR (via integrations and ingestion pipelines). - Threat hunting across previously unseen telemetry using Grail and DQL queries spanning logs, metrics, and traces. - Security automation using notebooks and workflows, plus typed field extraction via Dynatrace Pattern Language.

Target market and positioning

- Primary buyers/users: Security operations (SecOps), DevSecOps, SRE/platform engineering, and cloud security teams in organizations that already run Dynatrace for observability or intend to consolidate telemetry and security events. - Positioning: The product is presented as a combined observability and security capability rather than a direct replacement for SIEM/XDR; emphasis is on contextualizing and prioritizing security signals using runtime dependency mapping and production telemetry. - Fit signals: Environments with complex hybrid/multi-cloud estates, heavy Kubernetes usage, and teams seeking to attach operational context (exposure, affected services, dependencies, business impact) to security events.

Get a comprehensive analysis of Dynatrace Threat Observability including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →

Published May 16, 2026

01Common complaints

Organizations that primarily require full-featured SIEM/XDR outcomes (log-centric detection engineering, UEBA, mature SOC case management, and extensive detection content) may prefer established SIEM/XDR platforms and integrate Dynatrace for runtime context.
If the security team cannot adopt DQL, Grail, and the associated automation and query workflows, the benefits of Threat Observability will be limited.
If strict cost predictability is required for very high ingest volumes and retention needs, and variable cost models are unacceptable, alternative vendors or contractual guarantees should be considered.
If the primary need is specialized network performance monitoring rather than integrated observability and security context, a dedicated network monitoring solution may be more appropriate.

Deal disqualifiers (poor fit)

Organizations seeking a turnkey SIEM with extensive out-of-the-box detections and mature SOC case management without investment in a new query language or workflows; such organizations may favor Microsoft Sentinel/Defender, Splunk Enterprise Security, or Elastic Security for primary detection engineering needs and then integrate runtime context from Dynatrace.
Teams unable to allocate resources to learn and adopt DQL, Grail, and related automation patterns; the capability’s value depends on active hunting and correlation efforts.
Organizations that require strictly fixed-price models for extremely high data ingest and cannot tolerate variable costs tied to data retention and query usage.

1) Platform evolution can require customer work (documented)

Documented migrations (for example, changes to a Grail security events table) required customers to update ingest endpoints, pipelines, queries, and access policies within defined timelines. Customers with custom Threat Observability content may need to refactor artifacts during platform transitions.

2) DQL and Grail maturity concerns (community feedback)

Community comments indicate that DQL and Grail continue to evolve; this can result in shifting best practices and ongoing enablement needs.

3) Pricing and contract minimum risk (anecdotal)

Some customers report annual commitment or minimum spend dynamics that may differ from expectations based on public unit pricing; procurement teams should clarify contract terms and document commitments.

4) Usability issues and UI learning curve (review evidence)

Multiple review sources reference a non-trivial learning curve for new users and desire for improved usability for non-technical stakeholders.

02Why they buy

(Section retained as required; content presented in neutral, objective terms.)

Documented differentiators and recurring user themes

Contextual enrichment via topology and runtime mapping across the full stack, which Threat Observability leverages to correlate security signals with application and infrastructure context.
A unified data lakehouse (Grail) with a single query language (DQL) for observability and security data, along with ingestion paths for third-party security events via OpenPipeline and normalization via a semantic dictionary.
Documented retention defaults for certain security-event categories (for example, specific retention durations for platform-generated versus ingested events) that may assist investigations and compliance, subject to configuration and plan choices.

Where competitors may have an advantage

SIEM/XDR vendors often provide more extensive prebuilt detection content and mature SOC workflows.
Teams already trained on SPL or KQL may achieve faster initial analyst productivity on SIEM platforms without an investment in a new query language.
Some organizations prefer competitor UX and modular purchasing models for pick-and-choose consumption.

03Field reports

Review platform sentiment (broader Dynatrace product reviews)

Because Threat Observability is a capability within the broader Dynatrace platform, most public review coverage addresses Dynatrace as a whole rather than that specific module.

Gartner Peer Insights (Observability Platforms market):

The platform has received a high volume of ratings in the Observability Platforms market listing. Individual review content may be limited without platform access. Some reviewers noted generally positive experiences and responsive support.

G2 (Dynatrace reviews):

Public review snapshots indicate generally positive scores across many entries; common praise references automated insights and comprehensive telemetry coverage, while common complaints reference cost at scale.

TrustRadius:

Reviews reflect mixed feedback, with some users describing a substantial learning curve for navigation and others citing perceived retention limits or API stability concerns depending on their configuration and version history.

Community feedback (selected paraphrased excerpts)

Community discussions demonstrate variable sentiment:

Negative remarks emphasize UX complexity, perceived feature gaps, noise management, and concerns about pricing and contracting.
More positive or pragmatic remarks note that a single-agent deployment can simplify data collection and that automated baselining can provide default alerts out of the box; such comments are anecdotal and reflect individual experiences.

Why customers choose Dynatrace (themes)

Commonly cited reasons in reviews and community discussions include:

Broad coverage via OneAgent and automated discovery/topology mapping.
Support for root-cause analysis and dependency context.
Capability to deploy at enterprise scale across hybrid environments.

Why some customers leave / churn drivers (themes)

Recurring drivers for dissatisfaction include:

Cost management and budgeting complexity due to data volumes, retention choices, and required modules.
Learning curve associated with the UI and query language.
Perception of noisy or overwhelming problem detection in some environments.
Preference among some users for competitor UX or developer workflows.

Vendor-published claim: security event noise reduction

A vendor-published customer narrative describes a reduction in AWS security event volume from very high daily volumes to a much smaller set of prioritized alerts after contextualization.

Critical evaluation:

This narrative illustrates the intended value of context-driven prioritization but is vendor-published and lacks independent validation.
Missing methodology details include how priority was defined, baseline false positive rates, source tools for the original events, whether reductions were achieved through suppression or enrichment-based prioritization, and if any true positives were missed as a result.

Public sector/partner documents (limited evidentiary strength)

04Best fit

Company size

Typical fit: mid-market to large enterprise organizations with substantial headcount or organizations with complex multi-team platform operations.
Smaller organizations may adopt if they are cloud-native and prioritize consolidation, but cost and complexity may outweigh benefits for smaller teams.

Industries

Industries where the product is commonly considered include:

Financial services and insurance
SaaS and large-scale technology companies
Retail and e-commerce with high uptime requirements
Public sector organizations subject to deployment model and certification alignment

Roles/personas

Decision makers: CISO, VP Security, VP Platform/Infrastructure, Head of SRE, CTO.
Primary users: threat hunters, incident responders, SOC analysts, SREs, platform engineers.
Secondary users: developers reviewing security findings in service and release context.

Pain points the product addresses

High volume of alerts from CSPM/CNAPP/XDR tools with limited runtime context.
Slow triage and investigation due to siloed telemetry.
Need to correlate security signals with actual production service topology.
Desire to automate triage and routing using contextual attributes such as exposure, criticality, and affected entities.

Qualification criteria (good fit)

Existing use of Dynatrace or commitment to standardizing on the Dynatrace platform.
Mature telemetry programs that can support integrating security events in a shared lakehouse.
Willingness to invest in standardized investigations and operational playbooks (DQL queries, notebooks, workflows).

05The pitch

What the product does (objective value proposition)

Key documented outcomes include reduced alert noise through contextual prioritization, attack-path analysis, and support for threat hunting via contextual enrichment. Vendor messaging and independent validation vary.

Key vendor-described capabilities include:

Security Advisor–style automated insights to prioritize threat hunts and scope investigations with runtime context.
Ingestion and investigation of cloud security events from tools like CNAPP/CSPM/XDR/CDR (via integrations and ingestion pipelines).
Threat hunting across previously unseen telemetry using Grail and DQL queries spanning logs, metrics, and traces.
Security automation using notebooks and workflows, plus typed field extraction via Dynatrace Pattern Language.

Target market and positioning

Primary buyers/users: Security operations (SecOps), DevSecOps, SRE/platform engineering, and cloud security teams in organizations that already run Dynatrace for observability or intend to consolidate telemetry and security events.
Positioning: The product is presented as a combined observability and security capability rather than a direct replacement for SIEM/XDR; emphasis is on contextualizing and prioritizing security signals using runtime dependency mapping and production telemetry.
Fit signals: Environments with complex hybrid/multi-cloud estates, heavy Kubernetes usage, and teams seeking to attach operational context (exposure, affected services, dependencies, business impact) to security events.

Get a comprehensive analysis of Dynatrace Threat Observability including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →