Dynatrace grounds AI-assisted operations in telemetry and system dependencies

Dynatrace helps engineering teams understand what is happening across applications and infrastructure, using telemetry and the relationships between services. Its AI offering combines analysis of that operational context with natural-language investigation. The practical question is whether an engineer can move from a symptom to a defensible explanation and an appropriate action, while keeping both the evidence and the consumption cost visible.

01 / ProductTelemetry and topology give the assistant something to reason about

The Dynatrace Intelligence documentation describes causation-based analysis across applications, infrastructure, logs and traces. It uses Grail and the Smartscape dependency graph to identify anomalies and relate them to changes. This is a broader operational system than a chat interface placed over a set of log files.

Grail is the platform's data lakehouse for observability, security and business data. Its role is to make different signals available for contextual analysis. Smartscape contributes the relationships between components. Together, these can help distinguish a failing downstream dependency from several independent application errors that happen to appear at the same time.

The Dynatrace Assist explanation describes Assist as the evolution of Davis CoPilot. This article uses the current Dynatrace Intelligence and Assist names while retaining Dynatrace as the company identity. A reader comparing older Davis material should check whether it describes the same capability and release, rather than assuming the naming change guarantees identical behavior.

There is also an availability boundary. The Intelligence overview labels agentic workflows and built-in agents for approved actions as Preview. Investigation and query assistance should therefore be assessed separately from a proposed automated remediation path. A roadmap toward autonomous operations is not proof that every repair action is generally available in the reader's environment.

02 / AudienceDistributed operations create the useful context

Dynatrace is relevant to platform engineers, application owners and site-reliability teams investigating problems across many connected services. A checkout failure may originate in a database, a deployment or a dependent API. The platform's value is strongest when it can connect the symptom to enough operational context that the team can test a specific explanation.

A small application with little instrumentation may need to establish basic observability before it benefits from advanced assistance. Missing traces, inconsistent service names and absent deployment metadata limit what an AI system can infer. The model cannot reconstruct evidence that was never collected merely because the engineer asks a well-written question.

The Datadog blueprint offers another observability approach for applications and infrastructure. The Elastic blueprint is relevant when search and analysis across operational data are central requirements. Compare instrumentation, investigation workflows and cost units using a representative service, rather than relying on broad AI capability labels.

03 / WorkflowA proposed investigation of a checkout latency spike

Imagine an engineering team investigating slow checkout requests after a release. This is a proposed evaluation, not a Dynatrace benchmark or an incident we observed. Define the result as an evidence-backed incident explanation and a verified recovery outcome. A confident summary alone should not close the incident.

Start with the customer-visible symptom and a bounded time window. Identify the affected transaction, error rate and latency distribution, then compare it with a normal period. Confirm that the relevant traces, logs and deployment events are present. If only a subset of requests is sampled, preserve that coverage limitation when interpreting the results.

Use the service relationships to examine the path from checkout to its dependencies. A delayed database call can explain several slow services, but a shared symptom does not automatically prove a single cause. Inspect the proposed dependency and the timing of changes. Keep competing explanations visible until the operational evidence distinguishes them.

Ask Assist to help formulate a query or explain the relevant findings. The AI FAQ describes natural-language generation of Dynatrace Query Language, including a generate-only option. For the first evaluation, inspect generated queries before running them. Confirm the time range, selected entities and aggregation, since a syntactically valid query can still answer a different question from the one the engineer intended.

Tie each proposed explanation to specific evidence: a release event, a changed error pattern or an affected dependency. An engineer should be able to follow that chain without relying on the conversation transcript as the only record. Preserve the query and its result in the incident artifact so another responder can reproduce the investigation.

If a rollback appears appropriate, use the team's established change process. Do not make preview agentic remediation a hidden dependency of the pilot. Record the action actually taken and verify both technical health and the user-facing transaction afterward. A successful deployment rollback does not necessarily resolve a separate database or third-party problem.

Investigate the cost of the investigation as well. A broad query across a long period may scan substantially more data than a narrow incident query. The Cost Intelligence guide describes asking Assist about consumption, but says its answers use list prices and are environment-scoped; Account Management remains the billing source of truth. Do not confuse a conversational estimate with the invoice.

Include misleading scenarios in the evaluation: a deployment near the incident that was unrelated, a delayed upstream service, incomplete traces and a short-lived spike that disappears before investigation. Measure time to a verified explanation, incorrect hypotheses and the work required to reproduce the evidence. Those results show whether assistance improves operations under realistic conditions.

04 / PricingConsumption has several units even under one commitment

The pricing page describes Dynatrace Platform Subscription as an annual platform commitment consumed through a rate card. Public examples include Full-Stack Monitoring billed per memory-GiB-hour and log analytics billed for ingestion, retention and querying. The table uses selected USD list rates, not a negotiated quote or an estimate of the full platform bill.

The AI licensing FAQ says there is currently no separate licensing charge for the generative and agentic AI functionality it describes. Queries executed through that functionality still consume the customer's existing license. This is a current condition, not a promise that the feature will remain free or that AI-driven investigation has no cost.

Budget the monitored environment and expected investigation behavior together. More retained logs, wider queries and higher data volume can change consumption even if the engineering team has the same number of people. For the checkout example, estimate the actual host memory, logging volume and query pattern, then compare those assumptions with measured usage during the pilot.

05 / DistinctionsThe dependency model can improve the quality of a question

Dynatrace's distinctive contribution is operational context around the data. An engineer may begin by asking why checkout is slow and discover that the useful question concerns one dependency under a particular deployment. The platform can help narrow that question when the topology and telemetry are sufficiently complete.

The distinction between deterministic analysis and generated explanation matters. A graph relationship, query result and natural-language summary are different artifacts with different failure modes. Keeping them visible lets a responder challenge the explanation without discarding useful underlying measurements. The most persuasive output is one that remains understandable when the chat response is removed.

The consumption tools also connect technical decisions to operating cost. A team can inspect which capability and workload changed rather than treating observability as a fixed per-seat subscription. That makes query design, retention and instrumentation policy part of the platform's ongoing management, with engineering and finance looking at the same underlying usage.

06 / QuestionsCheck SaaS support, data boundaries and preview status

The current FAQ requires the latest Dynatrace SaaS environment, enabled AI functionality and relevant user permissions. It explicitly says this generative and agentic AI is unavailable for Dynatrace Managed customers. A reader using Managed should resolve that limitation before treating the proposed Assist workflow as immediately available.

Which operational data reaches the model provider? The FAQ says customer data and prompts are not used for model training, but also explains that agentic Assist shares additional information, including tool results, with enterprise vendors hosting its models. Review that distinction against the organization's permitted data flows rather than reading “no training” as “no external processing.”

Which actions are production-supported and which remain Preview? Verify the exact feature status and authorization controls for the intended release. Also test how permissions affect answers across teams. A useful assistant for one service owner must not become a route to unrelated operational data simply because the platform can query it.

07 / DecisionEvaluate the evidence path before expanding automation

Dynatrace deserves consideration when a team needs to connect operational signals across a complex environment and can maintain the instrumentation required to do so. Start with one service and one incident class. Use AI to assist the investigation while preserving queries, dependency context and the established authority for changes.

Expand when responders reach correct explanations faster, can reproduce the evidence and understand the cost of their usage. Keep preview remediation separate until its availability and behavior are verified. The durable result is an operational practice that remains trustworthy under pressure, not merely a more conversational dashboard.