Dynatrace Security Enrichment gives security teams one place to connect commercial, open source, and proprietary threat intelligence (TI) sources and use them to enrich IP addresses across Dynatrace Investigations, Threats & Exploits, and Workflows. Instead of building and maintaining a separate connector for each TI provider, you configure an HTTP-based connection, normalize the response, and reuse that context across the platform. This can support faster triage and more consistent decisions, and reduce integration overhead, for teams that rely on both third-party feeds and internal intelligence.

Why security teams need flexible threat intelligence enrichment

How can you distinguish between yet another false positive and a real threat when the context your team needs resides in a different tool for each investigation?

Threat intelligence sources rarely live in one place. Your team might rely on commercial feeds for reputation data, open sources for additional signal, and internal services for the context that matters most to your business. An internal IP reputation database or customer-IP registry can be just as important as any external feed.

That fragmentation slows down every investigation. Analysts move between browser tabs, scripts, and disconnected tools just to answer basic questions about an IP address. Each source returns a different response pattern, which makes it harder to apply consistent triage logic across teams and workflows. The more enrichment sources you depend on, the more operational overhead you create.

At the same time, security teams are under pressure to automate triage without losing control. That means you need flexible enrichment that can keep up with new providers, internal intelligence, and changing workflows without forcing you to build a new connector every time.

One unified experience to operationalize intelligence sources

Dynatrace Security Enrichment gives you a flexible, native way to connect to any HTTP-based threat intelligence API and use its results directly in the Dynatrace Platform. This includes commercial services, open source feeds, and proprietary internal APIs.

Start in minutes with vendor blueprints.

Pre-configured templates for popular providers like AbuseIPDB and VirusTotal handle the setup for you. Add your API key, and the enrichment configuration is set.

Connect any other source just as easily.

Whether it’s a niche commercial provider, an OSINT platform like MISP, or your team’s own internal reputation service — if it has an HTTP API that returns JSON, you can connect it. No coding, no custom integration development. Just point, configure, and go.

See consistent results across every source.

Each security intelligence source vendor returns different field names, different scoring models, and different response structures. Dynatrace Security Enrichment normalizes all of this — using the same query language your team already knows from Dynatrace — into a unified view with consistent reputation levels, geolocation data, recency indicators, and source references. Triage logic and automation that works for one source works for every source you add afterward.

From manual lookups to automated responses

This is where Security Enrichment changes the operational model — not just the tooling.

Consider a team that maintains its own internal IP reputation database, built from years of telemetry and asset context that no external vendor can provide. Today, when an analyst encounters a suspicious IP during an investigation, they open a separate tool, query that database manually, and paste the result back into their case notes. Multiply that by every investigation, every analyst, and every day.

With Security Enrichment, that internal system becomes a native enrichment source. The analyst selects an IP in their investigation and sees the internal reputation score right alongside commercial intelligence and geolocation — in one consistent view that persists as case evidence. No context switching, no manual lookups, no data siloed in a browser tab.

The same connection also powers automated workflows. Teams use the enrichment action in Dynatrace Workflows to build automated triage patterns like:

• Multi-source consensus. Enrich against several sources in parallel and only escalate when multiple providers agree an indicator is malicious — dramatically reducing false positives from any single feed.
• Automatic suppression of known-good traffic. Auto-resolve findings involving IPs your internal systems have classified as benign, with a full audit trail — so analysts focus on the alerts that actually need attention.
• Pre-enriched cases from the start. Automatically enrich every new investigation case the moment it opens, and page the on-call responder when a recently flagged malicious IP appears — so no one opens a case cold.

Because enrichment, detections, investigations, and automation all live on one platform, your team can run these patterns without sending alerts to a separate orchestrator, without maintaining duplicate configurations, and without the drift that comes from stitching together tools that weren’t designed to work together.

What’s next

We’re evolving Security Enrichment to cover a broader set of observables relevant to investigations. We’re also exploring ways to make integrations more adaptable based on user needs. Over time, we aim to further incorporate threat intelligence to inform investigations and support more proactive detection.

Get started

You can get started with Security Enrichment directly from the Dynatrace Hub and create your first connections in just a few clicks.

If you’re already using the standalone AbuseIPDB or VirusTotal apps, matching blueprints are available to help streamline the transition. With those standalone apps removed in June 2026, now is a good time to see what other threat intelligence you can incorporate.

The post Dynatrace Security Enrichment: Every threat intelligence source in one unified experience appeared first on Dynatrace news.

If you want to see them in action, head over to our Release Radar launchpad on the Dynatrace Playground.

Smartscape gets a unified topology view and ad-hoc filters

In a significant Smartscape update, a new All topology view shows every relationship for a given node in a single graph: the infrastructure stack, communication flows, and relationships such as monitoring, load balancing, routing, and API dependencies. Where the existing Vertical and Horizontal views each focus on a subset of relationships, the All view provides a more comprehensive view of relationships, from any node in any app across the platform.

Two changes make these views faster and more focused:

• The AWS and Kubernetes views now use flat layouts instead of nested ones, bringing the same relevance-based edge fetching and priority-driven node loading used elsewhere in Smartscape for more consistent visibility across your cloud landscape.
• New ad-hoc node and edge filters let you narrow any view by node type, cloud and infrastructure labels, team ownership, environment, and other properties.

Filters work alongside segments and are saved in the URL, so you can bookmark and share a focused view with segment, timeframe, and filters all preserved.

Press Ctrl+F (Cmd+F on Mac) in any Smartscape view to find nodes by name or ID. Matching nodes are highlighted in the graph, and the legend is narrowed to matching entity groups.

For broader context on Smartscape, see The new Dynatrace Smartscape improves operational efficiency across clouds, Kubernetes, infrastructure, and more.

AI Observability gains LLM evaluation, OpenInference, and Python instrumentation

AI applications can fail without obvious indicators — returning responses at normal speed with no errors, while delivering answers that are inaccurate, unsafe, or inconsistent. Traditional performance monitoring misses this entirely.

dt-evals is a new open source CLI that closes that gap. It pulls live gen_ai.* spans directly from your Dynatrace environment. Built-in evaluators use an LLM judge to score real production interactions for faithfulness, hallucination, relevance, toxicity, bias, PII leakage, prompt injection, and drift. The judge writes structured results back to Dynatrace as business events. Evaluation scores sit alongside latency and error metrics in the same dashboards. These scores can trigger alert workflows and gate CI/CD releases based on quality thresholds the same way that performance metrics do. For the thinking behind this approach, see Evaluate LLM and agent quality in Dynatrace AI Observability and LLM evaluations as a foundation for trustworthy agentic AI systems.

Dynatrace OneAgent now automatically instruments Python applications that use AWS Bedrock, OpenAI, Azure OpenAI, and LangChain. Dynatrace captures distributed traces, logs, and AI-related telemetry for supported model interactions — provider, operation, model, duration, token usage, and prompt and completion metadata where available. To capture prompt and completion content, go to OneAgent features and turn on Python OpenAI prompt capture.

The same visibility extends to teams using OpenInference with OpenTelemetry (OTel). Dynatrace ingests OpenInference traces and normalizes them to the same gen_ai.* attribute schema — covering model usage, token consumption, prompts, completions, agents, tools, embeddings, and guardrails — so OTel-instrumented applications get consistent telemetry without switching instrumentation frameworks.

As AI adoption grows, evaluation and instrumentation together turn AI services into observable, governable assets rather than black boxes.

Logs gains pattern analysis, Kubernetes insights, and in-context traces

Log analysis gets three meaningful upgrades.

Log pattern analysis (Preview) lets you aggregate query results in Logs into patterns that cluster similar logs together. You can focus quickly on recurring errors, reduce thousands of similar logs to a handful of patterns, recognize the changing parts of a pattern (and their datatypes), and reuse the generated Dynatrace Pattern Language (DPL) for other queries or in OpenPipeline.

In-context trace details mean that when you investigate a log entry with trace context, you can open the associated trace directly inside Logs. A waterfall icon signals that you stay in context rather than navigating away to Distributed Tracing.

Log insights in ready-made Kubernetes dashboards provide built-in log analytics for clusters, namespace workloads, namespace pods, and node pods. Error log counts appear alongside health metrics, with log level distribution and severity trends below. Direct links to the Logs app ensure that a deeper investigation is only one click away.

Faster service investigation with the Services Explorer Preview

The Services app now includes a visual service map that overlays performance and health indicators on service-to-service relationships and messaging flows. It’s the fastest way to understand blast radius during an incident, providing a single view of topology context, performance signals, and bottlenecks without switching views.

You can also filter services directly by primary Grail fields such as k8s.cluster.name, k8s.namespace.name, aws.region, and azure.location — the same attributes that power segments across Dynatrace. Both capabilities are available in the Explorer Preview view and open for feedback before general availability; see the Community post for details.

New security integrations and a Kubernetes security tab

Threat Observability expands its ingestion options with new integrations. Dynatrace now integrates with Checkmarx for software composition analysis and container security findings, and adds CrowdStrike and Kyverno integrations — pulling detection findings and Kubernetes policy compliance data into Dynatrace as security events. For Kyverno, see Ingest Kyverno compliance findings.

Kubernetes monitoring also gets a dedicated security tab (Kubernetes app version 1.42.0+) that replaces the Vulnerability tab in the Explorer, bringing security context into the same place teams already investigate cluster health.

Runtime Vulnerability Analytics now has a native interface, replacing the legacy management-zone-based monitoring rules with a single consolidated workflow.

One change worth flagging for security teams: ingested security.events must now carry a timestamp within −1h/+10min, tightened from the previous −24h/+10min window. Events with older timestamps are dropped, so please review any pipelines that backfill security events.

Performance, drilldowns, and navigation improvements

Improved discovery of ready-made dashboards. Ready-made dashboards deliver instant insights without requiring complex queries. Finding, installing, configuring, and customizing them is now more straightforward — so new users get value faster and experienced users can build confidently on best-practice templates.

Contents tab added to all extension apps. All extension apps in Dynatrace Hub now include a Contents tab that surfaces the extension’s ready-made dashboards, so you can quickly go from installation to insights.

Session Replay has two improvements:

• Full-screen mode is now available, removing viewport constraints during playback.
• Navigating to a session through Error Inspector now opens Session Replay directly in context, keeping the investigation continuous.

Cleaner Smartscape topology. Inactive Synthetic Locations no longer appear in Smartscape, keeping topology views focused on what’s live.

Smartscape navigation for database tables and indexes. Direct navigation intents let you jump from a database node to its table or index detail view in one click.

Filters stay with you. Automated filtering suggestions scope correctly to OR and AND conditions across all apps. Filter state, search terms, and highlights survive page reloads. HTTP Status Filter selections persist through navigation steps in Distributed Tracing.

DQL durations support decimals. Duration literals (h, m, s, ms, us, ns) now accept decimal numbers — for example, 0.5h or .2m. Note, however, that this doesn’t apply to calendar durations.

More headroom in Distributed Tracing. The log viewer no longer caps at 1,000 entries, with full deduplication across trace and span IDs. Span scan limits are configurable from settings (default 5,000, up to 10,000). Field naming is also cleaned up — Smartscape fields drop the redundant prefix, and classic ME fields are clearly labeled.

More allowlist entries for external requests. You can now add up to 100 allowlist entries, double the previous limit of 50, with existing entries preserved across all environments.

Affected entity names enriched in problem records. A new affected_entity_names array is now populated alongside the existing affected_entity_ids and affected_entity_types arrays, index-aligned across all three.

This brings the 3rd-gen platform to parity with classic problem notifications and enables notification workflows and external integrations to reference entity names without additional lookup. The Problems app v1.27 reached General Availability on June 29.

Proactive Cost Intelligence across your entire stack

Dynatrace now makes it easier to understand costs, act before they spike, and optimize with less effort. New Optimize documentation walks Dynatrace Platform Subscription (DPS) customers through the full journey from understanding to optimizing costs, aligned with the FinOps Foundation framework.

The bigger shift is that Dynatrace Assist can now do the cost analysis work for you, designed to reduce the need for specialist expertise. You can ask it to:

• Understand spikes — “I received a notification that costs have increased. Can you find anything notable?” returns the root cause along with a full drilldown into your billing_usage
• Predict costs — “Based on my log ingest usage over the last 90 days, can you predict my usage for the next 30 days?” returns a capability-level forecast based on actual consumption, useful when onboarding new teams.
• Optimize usage — “Are there any log queries duplicated by multiple users?” surfaces overlapping queries with concrete suggestions to improve them.

For more on building cost discipline into your observability practice, see Driving your FinOps strategy with observability best practices.

Why these changes matter

Taken together, the June releases make everyday investigation work feel less fragmented. You get more context in the places where teams already troubleshoot: a fuller Smartscape view, AI quality signals alongside performance data, log patterns that identify root causes faster, service maps for incident response, and security and cost insights that are easier to act on without switching tools or relying on specialists.

These are the kinds of changes that add up across a week of real work.

Check out all these updates in action on our Release Radar launchpad.

The post Dynatrace Release Radar 06.26 appeared first on Dynatrace news.

Kubernetes Security Posture Management (KSPM) is a specialized subset of Security Posture Management (SPM) that focuses on container orchestration platforms. Its main purpose is to identify misconfigurations and compliance gaps across clusters. Here are the latest enhancements:

• KSPM is turned on by default during Kubernetes cluster onboarding
• Security findings are surfaced directly in the Kubernetes app
• Node Configuration Collector (NCC) occurs automatically via the Dynatrace Operator. These improvements reduce operational overhead for platform and SRE teams while embedding security insights directly into runtime context, so teams can quickly understand, prioritize, and act without switching tools.

Dynatrace now unifies:

• Vulnerability findings (runtime-relevant CVEs)
• Detection findings (active threats)
• Misconfiguration findings (insecure configurations or compliance gaps)

The result is a single, contextual view of risk across your Kubernetes workloads.

The problem: Security findings without context slow teams down

Today, security and development teams operate with fragmented visibility:

• Developers receive CVEs or misconfiguration alerts without runtime context
• Security teams know what’s wrong but lack clarity on where the issues are and who owns them
• Findings and workloads exist in separate tools, owned by different teams

The impact

This fragmented visibility ultimately introduces friction and delay with each hand-off. The result is lower remediation, unclear ownership, and increased exposure risk for business-critical applications.

Security in context, without the context switch

Dynatrace closes this gap by embedding security findings directly into the Kubernetes app. A new Security tab is now available at the workload, namespace, and cluster levels, giving teams a unified view without leaving the platform they already work in.

Three types of findings unified into a single view

The Security tab surfaces three categories of findings.

1. Vulnerability findings focus on CVE libraries loaded at runtime, so findings reflect what is actually running, not everything that’s installed.
2. Detection findings flag signals of active malicious behavior, tied directly to specific Kubernetes resources.
3. Misconfiguration findings highlight deviations from benchmarks starting with CIS, visible in near real time.

Why this matters

Developers can now identify security issues while investigating performance or availability, see findings in the exact context of the affected workload, and act immediately, without waiting for an external ticket to make its way through the queue.

Consider a practical example: a developer investigating a workload discovers that Kubernetes secrets are exposed as environment variables instead of mounted as files. Without this integration, that issue might surface days later, stripped of actionable context and requiring cross-team coordination to resolve. With Dynatrace, it appears in real time, in the same workflow, with clear remediation guidance attached.

From insight to fix, without leaving the platform

Starting from the Security tab, developers can jump straight into the Security Posture Management app, pre-filtered to the exact finding they’re investigating, no manual searching required. From there, Smartscape® topology provides full runtime context at a glance: the affected workload, namespace, cluster, and its dependencies, all mapped out instantly. (This same type of user journey is also supported for the Vulnerabilities app and Threats & Exploits.)

Guidance that tells you what to do, not just what’s wrong

Rather than leaving teams to interpret raw findings, Dynatrace Intelligence delivers plain-language recommendations tailored to the specific benchmark and workload. In the secrets exposure example, the guidance is concrete: update your YAML configs to mount sensitive data as files rather than environment variables. No guesswork, no interpretation overhead.

The result is that teams can move from detection to remediation within a single session, without switching tools or waiting on another team to connect the dots.

Onboard Kubernetes clusters to Dynatrace for monitoring with automatic rollout and enablement of KSPM scans

Dynatrace removes friction from Kubernetes security adoption by making it automatic from the start. KSPM is now turned in during Kubernetes onboarding, with the Dynatrace Operator automatically deploying NCC without any manual configuration.

How it works

1. Start cluster onboarding in the Kubernetes app.
2. Select your monitoring mode (KSPM is turned on by default).
3. Install the Dynatrace Operator (Helm or GitOps).
4. NCC is deployed automatically for compliance data collection.
5. KSPM scans begin.
6. Misconfigurations appear in context within Kubernetes resources.

What’s next

Dynatrace will soon expand coverage across diverse Kubernetes environments with the introduction of Kubernetes Security Essentials, a new KSPM profile that provides baseline best-practice security checks across Kubernetes distributions and versions, without requiring node-level configuration data.

Broader coverage, wherever you run Kubernetes

This matters because not every environment supports full benchmark profiles. Kubernetes Security Essentials extends consistent security posture evaluation to platforms like GKE, OpenShift, K3s, and MicroK8, meaning even the most lightweight or managed distributions can now benefit from the same foundational security checks as any other environment.

Get started

Onboard your Kubernetes clusters with Dynatrace to:

• Gain visibility into your security posture
• Identify and prioritize critical misconfigurations
• Move from finding to fixing faster

The post Your business applications are at risk: Introducing in-context security findings for Kubernetes appeared first on Dynatrace news.

Dynatrace extends HIPAA compliance to Google Cloud Platform

Dynatrace has long supported HIPAA‑compliant deployments on Amazon Web Services (AWS) and Microsoft Azure. With the extension of HIPAA compliance to Google Cloud Platform (GCP), healthcare organizations in the United States can now standardize observability and security controls across all three major hyperscalers.

This expansion gives healthcare teams the flexibility to select the cloud platform that best supports their operational and innovation goals, while maintaining alignment with regulatory requirements. Dynatrace offers the option to enter into a BAA to support customers’ HIPAA obligations when Dynatrace services are used in regulated environments.

By delivering consistent, enterprise‑ready observability across AWS, Azure, and GCP, Dynatrace helps healthcare organizations modernize applications, improve system reliability, and strengthen security oversight.

HIPAA compliance: A business and trust imperative

HIPAA protects PHI and establishes safeguards for its storage, access, and monitoring. Compliance is not just a legal obligation; it is fundamental to:

• Maintaining patient trust
• Protecting sensitive data
• Avoiding costly regulatory penalties

Dynatrace solves healthcare observability challenges while keeping PHI where it belongs

Healthcare providers must balance rising patient expectations, modernization initiatives, and cost pressures, without sacrificing compliance or security. While cloud platforms often offer agility and scalability, regulatory requirements such as HIPAA can constrain technology choices.

Dynatrace HIPAA compliance is built on a shared responsibility model. Our platform is architected so that PHI does not need to flow through observability data. Customers retain responsibility for ensuring PHI and Personally Identifiable Information (PII) are masked at the source, and Dynatrace provides the tools to make that straightforward. Dynatrace offers built-in data masking and sensitive data protection features that allow teams to:

• Mask or obfuscate PHI and PII before data is ingested into the platform. The original data doesn’t leave the monitored environment. Once masked, sensitive data can’t be re-engineered.
• Define custom masking rules across logs, traces, and user session data.
• Reduce the risk of inadvertent PHI exposure
• Permanently delete unintended PHI ingestion with the Sensitive Data Center’s cleanup workflow

Dynatrace automatically discovers and maps every application, service, process, and infrastructure component across clouds.

For healthcare organizations, this means that Dynatrace delivers:

• Real-time observability across applications, infrastructure, and security.
• Standardized compliance controls across providers.
• Audit trails, access logging, and RBAC are aligned with HIPAA security rule requirements.
• A single source of truth for AI-first developers, IT operations, security, and compliance teams, eliminating tool sprawl and data silos.

Dynatrace multicloud HIPAA compliance supports healthcare organizations’ strategy to:

• Confidently evaluate GCP alongside AWS and Azure.
• Strengthen security and compliance visibility from a single platform.
• Invest in innovation, without compliance as a constraint.

Frequently asked questions

Is Dynatrace HIPAA‑compliant on AWS, Azure, and GCP?

Yes. Dynatrace supports HIPAA‑compliant deployments across Amazon Web Services, Microsoft Azure, and Google Cloud Platform for U.S. healthcare organizations.

Does Dynatrace ingest or process PHI?

Dynatrace operates on a privacy-by-design architecture, meaning it provides engineers with built-in tools to block PHI before it ever reaches the cloud. By default, Dynatrace does not need or use Protected Health Information (PHI) to monitor your application, but it can accidentally capture PHI if your systems leak sensitive data into logs, URLs, or payload traces. By signing a BAA with Dynatrace, your organization is assured that, if PHI is ever accidentally transmitted to Dynatrace, the data is protected under the necessary federal safeguards.

Are Business Associate Agreements available?

Yes. Dynatrace offers the option to enter into a BAA to support customers’ HIPAA obligations.

Getting started

This announcement is part of a larger Dynatrace commitment to ensuring observability is not constrained  by cloud provider choices.

Healthcare organizations can now deploy Dynatrace on GCP with HIPAA assurance, leveraging the same enterprise-grade observability available across AWS and Azure.

• Reach out to us to discuss how multicloud HIPAA compliance fits with your strategy.
• Visit the Dynatrace Trust Center to learn more about Dynatrace data security and privacy

The post Multicloud HIPAA compliance for healthcare: Dynatrace now supports AWS, Azure, and GCP appeared first on Dynatrace news.

This is the second post in our series on LLM evaluations. In the companion post, Evaluate LLM and agent quality in Dynatrace AI Observability with dt-evals, we showed you how to run online evaluations against real GenAI prompt traces and bring quality scores into Dynatrace AI Observability alongside latency, cost, and errors. This post steps back to the fundamentals: what evaluations are, how they work, and the methods teams use to measure AI quality.

Just as traditional software relies on testing frameworks to ensure reliability, AI systems require robust evaluation frameworks to measure the quality, accuracy, and safety of model outputs. Evals are the primary mechanism by which teams build trust in, iterate on, and responsibly deploy AI systems. Without them, organizations may risk deploying systems that produce unreliable answers, hallucinate facts, or quietly degrade in performance over time.

Key takeaways

• Evaluations are how teams move from “the LLM feels right” to “we can prove the LLM works.”
• There is no single best evaluation method. The right approach depends on what you’re measuring and why.
• LLM-as-a-Judge is one powerful tool within the broader evaluation ecosystem, not synonymous with evals as a whole.
• Online and offline evaluations serve complementary roles: offline for development, online for production monitoring.
• A mature evaluation strategy combines code-based, model-based, and human-based methods.
• Evals should be treated as living artifacts — maintained, versioned, and improved over time like any other engineering asset.

Why LLM evaluation is fundamentally different from traditional testing

Traditional software produces deterministic outputs — the same input consistently returns the same result, making pass/fail testing straightforward. LLMs are probabilistic systems: the same prompt can produce different responses depending on context, temperature, and model behavior. This variability makes conventional testing methods insufficient.

Instead of verifying a single correct output, teams must evaluate across multiple dimensions simultaneously:

• Correctness— does the response answer the question accurately?
• Relevance — is the output aligned with the user’s intent?
• Faithfulness — is the response grounded in source data, not invented?
• Safety and bias — does the output comply with organizational policies?

This transforms evaluation from simple pass/fail checks into continuous measurement of AI quality.

The hallucination problem

The most well-known consequence of probabilistic generation is hallucination — when a model produces plausible-sounding but factually incorrect information. This happens because LLMs predict likely word sequences rather than verify facts, which enables powerful reasoning but introduces serious risk in enterprise environments where accuracy is critical.

Addressing this requires evaluation frameworks that track signals like factual accuracy, semantic similarity, groundedness in source data, and consistency across responses. These metrics transform subjective quality judgments into measurable, improvable signals.

What is an LLM evaluation?

An LLM evaluation is a systematic process of testing a model or AI-powered system to determine whether it meets a defined standard of quality. That standard could be factual accuracy, helpfulness, safety, tone, latency, cost-efficiency, or any other measurable dimension that matters to the application.

Evaluations translate vague product goals (“the assistant should be helpful and safe”) into concrete, repeatable measurements. They allow teams to:

• Catch regressions when a model is updated, or a prompt is changed.
• Compare candidates — different models, prompt versions, or retrieval strategies — objectively.
• Build accountability by producing evidence that a system behaves as intended.
• Accelerate iteration by giving developers fast, structured feedback loops.

Evals exist on a spectrum of formality, from a small hand-curated test set run locally, to a large, automated pipeline running thousands of test cases in CI/CD on every deployment.

How do LLM evaluations operate?

At their core, evaluations follow a consistent pattern regardless of their complexity:

1. Define the task and success criteria. What should the LLM model do, and how will you know when it does it correctly? This is the hardest and most important step.
2. Assemble a dataset. A set of inputs (prompts, user messages, documents) paired with expected outputs or grading rubrics. Datasets can be human-curated, synthetically generated, or sampled from production traffic.
3. Run inference. Pass the inputs through the system under test and collect outputs.
4. Score the outputs. Apply a scoring method — a function, a model, or a human — to assess how well each output meets the success criteria.
5. Aggregate and analyze. Roll up scores into metrics (accuracy, pass rate, average score), visualize distributions, and compare against baselines or previous runs.
6. Act on results. Use the findings to accept or reject a change, file a bug, update a prompt, or trigger retraining.

This loop can run manually during development, automatically in CI/CD pipelines, or continuously against live production traffic.

What’s the difference between LLM evaluations and LLM-as-a-Judge?

This is one of the most common points of confusion in the space.

LLM evaluations are the broader discipline — the full process described above. They encompass everything from how you define success to how you collect test data to how you score outputs to how you act on results.

LLM-as-a-Judge is one specific scoring method that can be used within an evaluation pipeline. It involves using a language model (often a strong general-purpose model like GPT-5 or Claude Sonnet 4.6) to automatically assess the quality of another model’s outputs.

Think of it this way: evaluations are the framework, and LLM-as-a-Judge is one type of grader you can plug into that framework — alongside code-based graders, human graders, or embedding-based similarity checks.

• LLM-as-a-judge handles open-ended, subjective dimensions (tone, creativity, helpfulness) that are hard to capture in code.
• It scales to large datasets without human effort.
• It can be surprisingly well-calibrated when prompts and rubrics are carefully designed.

Limitations

• Inherent biases of the LLM model used to judge (verbosity bias, position bias, self-preference).
• Requires prompt engineering and validation to ensure the judge is grading what you intend.
• Adds cost and latency to the evaluation pipeline.
• Not appropriate for tasks with clear ground-truth answers where code-based checks suffice.

Code-based evaluations

Code-based evaluations use deterministic functions — written in Python or any language — to score model outputs. No secondary LLM model is involved.

How it works

You write a function that takes the model output as input and returns a score. The function might check for exact string matches, run regex patterns, execute generated code and test it, parse JSON and validate its structure, call an external API to verify a fact, or compare numerical results.

Common patterns

• Exact match — does the output equal the expected answer?
• Contains / regex match — does the output include a required phrase or follow a required format?
• Execution-based — for code generation tasks, run the output and check whether tests pass.
• Structured output validation — parse JSON/XML outputs and verify schema and values.
• Tool call verification — for agentic tasks, did the model call the right tool with the right parameters?

Strengths

• Fully deterministic and reproducible.
• Fast and cheap to run at scale.
• Easy to understand, debug, and audit.
• No dependence on a secondary model’s judgment.

Limitations

• Cannot handle open-ended or subjective quality dimensions.
• Requires knowing the exact expected output or a verifiable property of the output.
• Brittle for tasks where there are many valid correct outputs (for example, summarization, creative writing).

Code-based LLM evals are the first tool to reach for whenever a task has a clear, verifiable answer. They form the backbone of any reliable eval suite.

Online vs. offline evaluations

These two modes are not competing approaches — they’re complementary phases of a complete evaluation strategy.

Offline evaluations

Offline evals run against a static, pre-collected dataset before a system reaches production. They’re the evaluation equivalent of unit and integration tests in software development.

• When: During development, before deploying a new model, prompt, or retrieval change.
• Dataset: Curated, labeled, or synthetically generated. Often maintained in version control.
• Latency: Can run in batch; speed is less critical.
• Use cases: Regression testing, model comparison, prompt optimization, safety red-teaming, fine-tune evaluation.

Key advantage: Full control over the test distribution and ground-truth labels.

Key limitation: The dataset may not reflect real user behavior or the long tail of production inputs.

Online Evaluations

Online evals run against live production traffic in real time or near real time. They observe what is actually happening when real users interact with the system.

• When: Continuously, in production.
• Dataset: Real user inputs — unlabeled, unpredictable, and representative.
• Latency: Must be fast or asynchronous to avoid slowing down user-facing requests.
• Use cases: Production monitoring, anomaly detection, drift detection, A/B testing, continuous quality assurance.

Key advantage: Captures real-world usage patterns, prompts, and failure modes from production traffic, giving teams the most representative signal for monitoring AI quality over time.

Key limitation: No pre-defined labels; scoring must rely on heuristics, implicit signals (thumbs up/down, re-prompts), or async LLM-as-a-Judge pipelines.

Get started with LLM evaluations today

The field of LLM evals is evolving rapidly. As enterprises deploy increasingly autonomous AI systems, evaluation can play an important role in improving AI accuracy, reliability, and safety.

Here are the trends worth watching and investing in:

1. Evaluation-driven development. Treat evals as a first-class engineering artifact. Write eval cases before building features, maintain them in version control, and integrate them into CI/CD pipelines — mirroring test-driven development practices from software engineering.
2. Agentic and multi-step evaluation. As AI systems move from single-turn Q&A to multi-step agents that use tools and maintain state, evaluations must evolve to assess full trajectories rather than just individual outputs. This includes evaluating tool use, planning quality, error recovery, and task completion over long horizons.
3. Adversarial and safety evals. Red-teaming — probing a system for failures, biases, and unsafe behaviors — is becoming a standard part of the eval lifecycle, especially as regulatory requirements around AI safety mature.
4. Human-in-the-loop calibration. Even automated eval pipelines benefit from periodic human review to catch drift in what the judge model or scoring function is measuring. Building lightweight human-annotation workflows alongside automated evaluations yields a more reliable signal over time.
5. Standardization and benchmarking. The industry is moving toward shared benchmarks and eval frameworks (for example, HELM, MMLU, LMSYS Chatbot Arena, OpenAI Evals) that allow apples-to-apples comparisons across models. Building internal evals that complement these public benchmarks will be an increasingly important capability for any team deploying LLMs.
6. Cost-aware evaluation. As evals scale, cost becomes a real constraint. Emerging approaches include training lightweight specialized judge models, using embedding-based similarity as a cheap first filter, and intelligently sampling which examples need expensive LLM-as-a-Judge scoring.

Organizations that invest early in robust evaluation frameworks and combine them with AI observability will be positioned to scale AI safely across their operations.

Ready to put this into practice?

See our companion blog post, Evaluate LLM and agent quality in Dynatrace AI Observability with dt-evals, to learn how dt-evals lets you run LLM-as-a-judge evaluations on real GenAI traces and turn AI quality into a queryable, trendable, and alertable signal inside Dynatrace AI Observability.

Because in the end, AI systems are only as trustworthy as the processes used to evaluate them.

The post Beyond LLM-as-a-judge: Establishing LLM evaluations as a foundation for trustworthy agentic AI systems appeared first on Dynatrace news.

This edition of Release Radar covers the Dynatrace releases from May, 2026. Here are the changes that should matter right away to practitioners:

• AI tooling
• AI coding agent monitoring
• Jira integration
• Dashboard productivity
• Pipeline grouping

To see them in action, head over to our release radar launchpad on the Dynatrace Playground.

Dynatrace Assist: At your side with more context

Dynatrace Assist gets four upgrades in sprint 1.338 that deepen its usefulness during active investigations.

Side-by-side mode puts the chat interface in a collapsible panel alongside your current view — dashboard, notebook, or any other app page stays visible while you work with Assist. Chat and investigate at the same time without losing your place.

Reference files and skills give Assist access to a curated knowledge base built on Dynatrace documentation and product expertise, following the Anthropic Claude Agent Skills format. Responses are designed to draw on structured Dynatrace knowledge, so answers are grounded in how the platform actually works.

Anthropic Claude Sonnet 4.6 as the foundation model can help bring stronger multi-step reasoning and improved performance on complex, multi-tool investigations — the same model used in the latest Anthropic API and Claude Code.

A purpose-built NL2DQL model makes natural-language-to-DQL generation more accurate. The capability now uses a fine-tuned foundation model based on Llama 3.1 8B, trained specifically on Dynatrace query patterns. Write a question in plain language and get a working DQL query with fewer iterations.

AI coding agents get unified monitoring

Dynatrace now provides observability for five major AI coding agents: Claude Code, Google Gemini CLI, OpenAI Codex CLI, OpenCode, and GitHub Copilot SDK.

As  your team adopts multiple AI agents in parallel, you need shared visibility into what they cost, how they behave, and what they produce. This release gives platform teams, engineering leaders, and security teams a  unified observability across all five agents, all built on OpenTelemetry.

What teams get across the supported agents:

• Adoption and token tracking — session counts, token consumption, and cost trends across agents and teams.
• Tool behavior visibility — which tools each agent calls, how often, and where runs slow down or fail.
• Production context in the IDE — engineers can query live Dynatrace data through the Dynatrace MCP Server without leaving their coding environment.
• Engineering outcome correlation — connect agent activity to downstream delivery signals like commits and pull requests (available for Claude Code).

Pre-configured dashboards are available for each agent. For the full breakdown by agent and setup details, see Dynatrace expands AI coding agent monitoring.

Investigate production problems without leaving Jira

The Dynatrace MCP Server now integrates with Atlassian Rovo, bringing observability context directly into Jira and JSM tickets.

When an incident or issue is open in Jira or JSM, Rovo can now call Dynatrace tools in natural language — querying metrics, traces, logs, and topology — and post the results as ticket comments. Root cause analysis and dependency mapping happen inside the ticket, so engineers stay in context instead of switching between platforms.

Key points for practitioners:

• No context switching — investigate and document findings without leaving Jira or JSM.
• Per-user OAuth 2.1 — every Dynatrace call runs as the requesting user, with a full audit trail across both platforms.
• Admin-controlled tool exposure — administrators choose which Dynatrace tools Rovo can access.
• Included with Dynatrace SaaS — no additional cost, and adding users doesn’t change the pricing.

It’s designed for fast setup: authenticate via the Rovo admin UI, select the tools to expose, and the integration is live across Jira, JSM, and Confluence.

For the full walkthrough, see Dynatrace MCP Server for Atlassian Rovo.

Dashboards: build faster, navigate better

Releases 1.338 and 1.339 bring a focused set of dashboard improvements that add up across a day of analysis work.

Ready-made tiles and sections expand the dashboard and notebook library with pre-configured visualizations and built-in drill-downs to other Dynatrace apps. Browse or search the tile library to find components that are ready to use, and customize from there rather than starting from a blank canvas.

Direct JSON editing lets power users open and edit the full dashboard definition as JSON from the dashboard Actions menu. The format matches the Dashboard API, so configuration changes, bulk tile edits, and version-controlled workflows are all faster in the editor than in the visual UI.

URL-driven variables make it possible to configure hidden dashboard variables through URL parameters, enabling pre-configured views to be linked directly with filters already applied — useful for sharing context-specific dashboards with specific teams or stakeholders.

Launcher link reordering lets users drag links between sections in the launcher, making personal navigation layouts easy to maintain.

Active tile tab persistence keeps the last-active editing tab visible when switching between tiles, so the configuration state is preserved while navigating across a dashboard.

Pipeline groups get a configuration UI

Pipeline groups, which let central teams enforce shared policies across multiple OpenPipeline pipelines, now have a dedicated configuration interface in Early Access (sprint 1.339).

Platform teams can now configure group-level policies in the UI, including cost allocation and sensitive data scanning. Pipeline teams still control their own parsing and extraction logic, so central governance doesn’t come at the cost of local flexibility. No direct API access required.

This UI makes the feature accessible to a wider set of platform operators and can help reduce setup costs for organizations running large, multi-team pipeline environments.

For background on pipeline groups and the governance model they enable, see Pipeline Groups in Dynatrace OpenPipeline.

Latest UX improvements

Investigation workflows in logs get sharper. Join the Log pattern analysis preview and see how selected log patterns now open a dedicated deep-dive panel showing behavior over time and associated records — inspect pattern-level context without losing the overview, and drill into individual log records from the same panel without navigating away. Log attributes open in full-screen mode for reading long or nested JSON in place. When Logs is opened from a contextual link in a dashboard or alert, the query runs automatically — no extra click required.

Navigation, filtering, and performance also improve across several surfaces. In the Session List, a tooltip on the Session Replay icon shows replay availability — full, partial, or none — so you can triage which sessions have usable replay before opening them. The Services explorer gains dynamic tag filters for Kubernetes namespace annotations and labels, expanding filter coverage for k8s-heavy environments. Infrastructure inventory in large network environments now loads in 3–5 seconds in typical environments, with status and reachability columns loading progressively so the view is immediately usable at scale. Press Shift + ? anywhere in the platform to open the keyboard shortcut reference.

Why these changes matter

The May releases extend capabilities across the workflows that practitioners use most. AI tooling stays present during investigations. Coding agents become observable assets, not black boxes. Dashboards get faster to build and easier to manage. Cost data supports annual planning. And pipeline governance reaches more teams through a UI.

These are the kinds of changes that add up across a week of real work.

Check out the updates in action on our Release Radar Launchpad.

The post Dynatrace Release Radar 05.26 appeared first on Dynatrace news.

We have released Dynatrace version 1.341. To learn what’s new, have a look at the release notes.

The post What’s new in Dynatrace SaaS version 1.341 appeared first on Dynatrace news.

Organizations are evolving from human-driven operations to supervised autonomous operations, where AI investigates, recommends, and remediates, and humans stay in control of what matters most. A big part of delivering on that vision is working with the agents that customers already run in their cloud environments.

Harness the power of hyperscale agents

Each hyperscaler has AI agents that automatically investigate and help resolve production incidents using native cloud telemetry and tools. They act like embedded site reliability engineers, analyzing issues and recommending or executing remediation steps without waiting for a human to start the process.

AWS DevOps Agent provides investigation and remediation in AWS using native tooling. An Azure SRE Agent specializes in investigating and remediating Azure issues. And Google Gemini Cloud Assist is for incident analysis across Google Cloud Platform (GCP).

Over the past year, we’ve published how Dynatrace supercharges each of these cloud agents individually. When an issue occurs, Dynatrace Intelligence combines causal, predictive, and agentic AI using the Smartscape dependency graph to automatically link related symptoms and root causes across the environment into one unified problem card.

When Dynatrace integrates with the AWS DevOps Agent, dependency-aware root cause analysis combines with AWS frontier-agent capabilities, and joint customers report up to 70% reductions in mean time to resolution. When Azure SRE Agent connects with Dynatrace, deterministic, causation-based AI flows directly into Azure-native remediation workflows, cutting the back-and-forth between teams. And with Google Gemini Cloud Assist, Dynatrace delivers the same production context layer to GCP-hosted incidents: precise root cause, full topology, real business impact.

From integrations to intelligent orchestration

Many enterprises run workloads across AWS, Azure, and Google Cloud simultaneously, and managing three separate integrations with separate routing logic and separate cost controls is its own operational tax. Cloud SRE Agents provides a single orchestration layer that routes problems to specific hyperscaler agents based on configurable profiles to see everything happening across all three cloud agents.

The Cloud SRE Agents app writes findings back to Dynatrace, and provides your team with measurable visibility into autonomous actions.

How Cloud SRE Agents works

When Dynatrace Intelligence detects a problem and identifies the root cause, Cloud SRE Agents calls dedicated cloud-native agents from AWS, Azure, and Google Cloud to retrieve deeper insights from the sources that only they can reach: CloudTrail history, Azure subscription policy, GCP project IAM, recent deployments, and native runbooks. These agents run in parallel, gathering evidence as soon as the problem is detected. Their findings, and, where applicable, the recommended remediation path, are displayed in the same Dynatrace problem view that the on-call SRE is already using in their day-to-day workflow.

One view. No tab-switching. The work starts without you.

Three workflows do the orchestration in the background:

• Investigate evaluates your Interaction Profiles and dispatches matching problems to the right agents in parallel.
• Periodic Tasks polls each cloud provider for completion, detects stalled or timed-out investigations, and writes findings back as problem annotations.
• Event Handlers normalize the cloud-provider event stream so every action correlates back to its originating problem, end to end.

Cloud SRE Agents has the insights and intelligence to decide which agent gets which problem, tracks each run to completion, and brings the answers back together in a single view. The Overview tab provides a real-time, interactive network graph of problems, agents, and activities. The replay view allows the user to step back in time and get an overview of what has happened when, as well as the status of each investigation.

Intelligent routing with Interaction Profiles

In agentic operations, routing rules make the difference between turning autonomous systems loose on every alert and pointing them precisely where they earn their keep. Interaction Profiles are how you express routing judgment in Cloud SRE Agents. Each profile pairs a set of conditions with the agent or agents that should handle the problems flagged by the profile, and evaluates the conditions whenever Dynatrace Intelligence detects a problem.

The conditions you can write are deliberately broad. You can route by the cloud account, subscription, or project an incident touches; by problem category (availability, error, slowdown, resource contention); by affected entity type (a Kubernetes cluster, a database, a Lambda function); by tag, label, or any custom attribute carried in the problem record. Conditions combine with AND/OR logic and nest as deeply as you need, keeping real production routing policy inside the app rather than spilling into custom workflows or scripts.

Three ways teams put it to work

Route problems to the right cloud, automatically

A spike in Lambda error rates belongs to AWS DevOps Agent. An Azure App Service degradation calls for Azure SRE Agent. A Pub/Sub latency issue lands with Gemini Cloud Assist. In a multicloud estate, none of those decisions should fall to a human at 2:00 AM. A profile filtered by AWS Account ID, Azure Subscription ID, or GCP Project ID, then narrowed by resource type or tag, settles the routing question once. Every matching problem is automatically routed to the right specialist with the right cloud-native context.

Optimize spend with budget-aware routing

Cloud AI agents do work, and that work has a cost. Cloud SRE Agents lets you set a Monthly Duration Budget per agent and gate dispatch on it via a Has Available Budget filter: once the budget is exhausted, new investigations either stop (in strict enforcement mode) or proceed with a logged warning. The duration figure itself is a proxy, derived from Dynatrace event timestamps rather than the cloud provider’s clock, which makes it useful as a circuit breaker and directional signal, not a substitute for AWS, Azure, or GCP usage reports. The governance value is what matters: you decide how much autonomous investigation you’re willing to underwrite each month, and the system holds the line.

Tier autonomous investigation by problem type and entity

Not every Dynatrace problem warrants an autonomous investigation. Problem Category filters let you dispatch agents only to the problem categories that warrant it, for example, availability or error problems that require immediate action, rather than slowdowns or custom alerts where human triage might still be the right call. Layer on Entity Type filters, and you can further focus on specific infrastructure tiers (hosts, services, process groups, Kubernetes clusters). The result is a tiered model: high-severity issues receive immediate autonomous investigation, lower-severity signals queue for human review, and your team controls the threshold.

Governance that makes autonomous work measurable

Agentic operations earn trust when teams can see what the agents did, why, and whether it worked. Cloud SRE Agents treats that as a first-class concern, with two views built for the two audiences who care about it.

The Activity tab is the audit trail. Every investigation and mitigation appears as a card on a unified timeline; expand any card to see the agent’s full findings, the evidence it pulled, and the action it took or recommended. Each response can be rated Good, OK, or Bad, building a quality signal grounded in what your team actually saw rather than what the system predicted. When a single problem triggers work across multiple agents, those activities roll up to a single status (in progress, done, or stalled), so you always know where things stand without having to reconstruct the run from individual records.

The Statistics tab is where autonomous operations become a number you can show to a leadership team: problems handled, mitigations executed, average investigation time, MTTR and MTTI trends, success rates, and satisfaction scores broken down by agent. The same view doubles as a directional cost lens, since agent working time is the dominant driver on the cloud side of the bill. Treat the number as a trend signal and a circuit-breaker input, not a billing record (reconcile against AWS, Azure, and GCP usage reports for exact spend), and it makes the case for expanding agentic coverage with evidence rather than anecdote.

Why production context multiplies the value

What changes Cloud SRE Agents from a smart dispatcher into something more is what Dynatrace Intelligence contributes before an agent ever begins its analysis. Dynatrace delivers deterministic, causation-based root cause analysis grounded in Dynatrace’s Smartscape real-time dependency mapping, alongside business impact assessment and correlated telemetry. That context shapes the entire direction of the investigation. A cloud agent arriving with that foundation starts from “this specific service on this specific host is the root cause, and here’s the customer impact” rather than “something is wrong somewhere in this account.”

The numbers reflect it. According to AWS, organizations using the AWS DevOps Agent with Dynatrace see up to a 75% reduction in mean time to resolution.

Western Governors University, which runs a fully online learning environment for 200,000 students, uses AWS DevOps Agent with Dynatrace to automate cross-system correlation that previously required manual effort across multiple tools. At a larger scale, United Airlines transports more than 500,000 passengers daily across a hybrid environment that includes more than 500 AWS accounts, 20,000 Lambda functions, and 38,000 OneAgent deployments.

The team’s description of the before and after status is direct: previously, multiple tools with overlapping functions created gaps and black boxes during troubleshooting. With AWS DevOps Agent and Dynatrace, Dynatrace identifies the responsible layer, the agent investigates and provides resolution steps, and everything surfaces in a single Dynatrace view. No 3:00 AM tool-switching required.

Get started

For a closer look at the individual integrations, read the posts on AWS DevOps Agent and Dynatrace and Azure SRE Agent and Dynatrace, or see how Dynatrace Intelligence powers autonomous operations. To put your cloud agents to work today, install Cloud SRE Agents from the Dynatrace Hub. Cloud SRE Agents is currently available as a community-supported app.

The post Orchestrate multicloud AI agents for autonomous incident resolution appeared first on Dynatrace news.

What is the Kiro power for Dynatrace?

The Kiro power for Dynatrace delivers live observability data, root cause analysis, and remediation suggestions directly into the Kiro IDE, with no JSON editing or manual MCP setup.

Kiro is an AI-powered IDE that helps developers move from idea to working code through spec-driven development and an agentic assistant. To make the assistant genuinely useful in unfamiliar domains, Kiro recently introduced powers: curated, partner-validated bundles of MCP servers, steering files, and best practices that install with a single click and load on demand when a relevant task comes up. Install a power, and Kiro’s agent gains specialized expertise the moment you need it.

For Dynatrace customers already working in Kiro, it’s the shortest path yet from code to production insight. For developers new to Dynatrace, it’s a one-click way to ground Kiro’s reasoning in real facts from your environment, not guesses.

Why this matters for developers

Developers have historically been one step removed from production. When something breaks after deployment, the path to figuring out what went wrong usually runs through a Site Reliability Engineering (SRE) or operations team, and AI coding assistants can’t automatically and reliably remediate issues in software they’re unfamiliar with. Agents that can write code are guessing about how their code behaves in production unless they have access to real telemetry data.

The Dynatrace Kiro power for Dynatrace closes this gap through Dynatrace Intelligence, the agentic operations system at the core of the Dynatrace platform. Kiro’s answers are grounded in deterministic, causal AI and real-time production data, not probabilistic guesses.

With the tools provided by the Kiro power, developers can:

• Investigate live incidents and get root cause analysis directly in Kiro chat
• Query metrics, logs, and traces from production using natural language
• Surface security vulnerabilities affecting the code they’re working on
• Get remediation suggestions grounded in what’s actually happening in their environment

“Using Kiro powers for Dynatrace has been a total game-changer in the observability space. Deep-dive root cause analysis of complex system issues that once required lengthy manual intervention now happens in seconds, giving us unprecedented speed and confidence.”

Mike Kobush, Sr. Software Performance Engineer, NAIC

How to install the Kiro power for Dynatrace

Getting started takes only a few steps. Once installed, the Kiro power activates automatically when Kiro detects a relevant task. Mention an incident, a slow service, or anything that needs production context, and the Dynatrace tools and guidance will load in Kiro chat.

Prerequisites

• A Dynatrace account. If you don’t already have one, you can start a free 15-day trial.
• Kiro installed on your system.

Prepare the Dynatrace connection

First, create a Dynatrace Platform Token, which Kiro will use to authenticate. Then add the required permissions for the Dynatrace MCP server.

Install the Kiro power

The power can be installed from either the Kiro IDE or the Kiro powers website. For this walkthrough, we’ll use the IDE.

1. Launch the Kiro IDE.
2. Select the Ghosty icon with the lightning bolt to open the powers panel.
3. Select Dynatrace Observability from the Recommended
4. Select Install. The power is registered with placeholder values for the Dynatrace URL and token. Therefore, Kiro will show an error message that the MCP server can’t be reached.
5. To complete the configuration, select Open Settings and replace the placeholders with your environment details.

Configure your tenant and token

In the settings file, replace the two placeholders:

Start asking questions

Open a new chat in Kiro and start interacting with your Dynatrace environment using natural language. Query active problems or security vulnerabilities, request a root cause analysis to identify critical issues in production, or pull related logs and traces, all without leaving the IDE.

See it in action

The short demo below walks through installing the Kiro power for Dynatrace, verifying the connection, and running a first query against your environment to list the top 10 vulnerabilities detected by Dynatrace.

Get started with the Kiro power for Dynatrace

Kiro powers transform what used to be a stitching exercise (MCP servers here, steering files there, custom instructions somewhere else) into one single, ready-to-use bundle. The Kiro power for Dynatrace applies the same idea to observability: live production insight, causal root cause analysis, and remediation grounded in real telemetry, all available the moment a developer needs them.

The result is a tighter loop between writing code and understanding how it behaves in production. Less waiting for diagnostic data from someone else. Less guesswork from an AI assistant operating without context. And, more time spent on the work that actually matters.

Ready to try it? The Kiro Power for Dynatrace is publicly available: install it from kiro.dev or the Kiro IDE and start asking your environment questions.

The post Dynatrace observability is now a Kiro power appeared first on Dynatrace news.

For AI systems, reliability is defined by response quality, factual grounding, data security, and usability — and those signals need to live alongside the same observability data teams already trust to monitor performance and availability.

When evaluation scores are isolated in notebooks, spreadsheets, standalone tools, or CI logs, they’re hard to operationalize. By bringing AI quality metrics into Dynatrace AI Observability—next to latency, cost, errors, traces, and user behavior—teams can connect poor responses and hallucinations directly to the prompts, models, retrieval contexts, tool calls, services, and traces that produced them.

What is dt-evals?

dt-evals is an open source CLI for evaluating LLM and agent quality from real GenAI traces, agentic interactions. Teams can run online evaluations against live or recent interactions, score outputs with an LLM judge, and send structured results back to Dynatrace AI Observability so quality becomes visible, queryable, trendable, and actionable.

A minor prompt edit, model change, or retrieval update to an AI application can improve one behavior while quietly breaking another. The challenge to tracking down where and why these systems break is that evaluation results are often maintained outside the operational workflow, making it difficult to connect a low score to the exact trace, prompt, model version, retrieval context, tool call, or service that produced the unwanted behavior.

Dynatrace AI Observability closes this loop. With dt-evals and the AI Observability Evaluation Preview teams can pull recent gen_ai.*  spans, score real interactions with an LLM judge, and write structured evaluation results back as business events. These scores can be viewed with the originating trace, queried for custom analysis, trended in dashboards, and used to trigger alerts or workflow-driven remediation.

A failing faithfulness score is no longer just a number in a report. It’s now an operational signal.

What are LLM evaluations?

An LLM evaluation system scores an AI response against a range of quality and safety dimensions. Common examples include whether the answer is relevant to the question, faithful to the provided context, free of hallucinations, safe for users, complete enough to be useful, and resistant to prompt-injection attempts.

LLM evaluations are typically applied in two modes:

Offline evaluations run before release against a fixed test set or curated trace dataset. These are used to compare a proposed prompt, model, retriever, or agent-tool change against a known baseline before shipping. For example, replay 500 representative support questions in CI and block the release if faithfulness drops below the configured threshold.

Online evaluations run after deployment against sampled production or user traffic. Use online evaluations to detect regressions caused by live inputs, changing retrieval results, tool behavior, traffic mix, or model drift. For example, evaluate 10% of support-agent traces from the last hour and alert the team if hallucination failures exceed the configured window.

With dt-evals, you can run evaluations from the command line, use them in CI/CD, or schedule them to detect quality regressions autonomously after deployment as a post-processing quality gate for your AI agents and LLM output.

Run evaluations from the command line

dt-evals is an open source evaluation toolkit for teams that want to bring their own data, judge provider, and evaluation logic while keeping traces, scores, dashboards, and alerts connected.

Install the CLI:

npm install -g @dynatrace-oss/dt-evals

Or run it directly with npx:

npx @dynatrace-oss/dt-evals <command>

A typical first run has three steps:

1. Configure your environment and judge provider (Bring Your Own AI API key):

dt-evals configure

2. Verify your local setup and connection:

dt-evals doctor

3. Run evaluations on recent GenAI traces:

dt-evals run --since 1h --sample 10

This command evaluates traces from the last hour and samples 10% of them. In other words, dt-evals evaluates roughly one out of every ten matching traces, including the prompt and completion messages associated with each selected trace.

During configuration, you provide the connection to your Dynatrace environment and the credentials for the LLM judge provider you want to use. dt-evals does not require teams to send evaluations through a fixed provider. You bring your own judge credentials and control where evaluation execution happens.

For CI/CD use cases, run in CI mode:

dt-evals run --since 6h –ci

In CI mode, dt-evals emits machine-readable output and can fail the pipeline when a configured threshold is breached. This makes quality checks part of the same delivery process used for prompt changes, model upgrades, retrieval updates, and agent releases.

Bring your own LLM judge provider

The “LLM-as-judge” evaluation approach involves using an AI model to score another model or agent response. The LLM judge needs to come from an AI provider your team trusts and has approved for the type of data being evaluated.

dt-evals supports common LLM judge AI models and inference providers, including OpenAI, Anthropic, Google/Vertex/Gemini, AWS Bedrock, and Azure OpenAI. Depending on the package and configuration path you use. Teams provide their own credentials, choose the judge model, and can tune execution settings such as thresholds and concurrency.

This matters for both governance and cost control. Teams can decide which LLM provider is assigned to evaluate which traffic, how many judge calls run in parallel, and where evaluation results are stored.

Which quality and safety dimensions are evaluated by dt-evals?

dt-evals supports built-in LLM-as-Judge evaluators for a range of quality and safety dimensions, including:

• Relevance: Does the response answer the user’s question?
• Faithfulness: Is the response supported by the provided context?
• Hallucination: Does the response invent facts that are not present in the available context?
• Answer completeness: Does the response fully address the user’s request?
• Context relevance: Is the retrieved or supplied context useful for answering the question?
• Factual accuracy: Does the response match an expected or known-correct answer?
• Summarization quality: Does the summary preserve the important information?
• Conciseness: Is the response direct with no unnecessary detail?
• Fluency: Is the response clear and readable?
• Toxicity: Does the response contain harmful or abusive content?
• Bias: Does the response show unfair or inappropriate bias?
• PII leakage: Does the response expose sensitive personal information?
• Prompt injection: Did the input or response show signs of instruction manipulation?
• User frustration: Does the interaction suggest the user is blocked or dissatisfied?
• Drift: Are scores changing meaningfully compared with prior behavior?

A Retrieval Augmented Generation (RAG) application might focus on faithfulness, hallucination, context relevance, and answer completeness. A customer-facing support agent might focus on relevance, fluency, bias, toxicity, and prompt-injection risk. An internal assistant might add custom checks for tone, policy compliance, or whether the answer includes required next steps.

Add custom evaluations

Built-in metrics are useful, but most production AI systems also need checks that are specific to the business, domain, or workflow.

Custom evaluations let teams define their own judge prompts, scoring rules, labels, and thresholds. For example, a support team can create a custom evaluator that checks whether an answer includes a required troubleshooting step before recommending escalation. A financial services team can check whether responses include the required disclaimers. A platform team can check whether an agent uses the correct tool before answering.

The critical point is that custom evaluators run through the same pipeline as built-in evaluators. They can produce the same structured results, appear alongside other scores, and be used in dashboards, alerts, and release checks.

A typical configuration defines the target service, judge provider, sampling strategy, enabled metrics, and thresholds:

schemaVersion: 1
name: support-agent-prod

dynatrace:
  environmentUrl: https://your-env.apps.dynatrace.com
  platformToken: dt0s16.xxxxx

judge:
  provider: openai
  model: gpt-5.5

scope:
  service: support-agent
  since: 1h
  sampling:
    strategy: random
    percent: 10

metrics:
  enabled:
    - faithfulness
    - hallucination
    - relevance
    - drift

alerts:
  thresholds:
    faithfulness: 0.7
    relevance: 0.7

Evaluation results in the AI Observability app

Evaluation results appear directly in the AI Observability app, so teams don’t have to jump between a trace view, an eval report, and a separate dashboard to understand what happened.

In the Prompts view, teams can filter for prompts with evaluation scores and inspect row-level verdicts. Score badges such as relevance, fluency, bias, faithfulness, or toxicity make response quality easy to scan without opening every trace.

This is useful when triaging a regression. Instead of starting with a generic failure count, teams can quickly see which prompts failed, which evaluator failed them, and whether the issue is isolated or widespread.

From an individual prompt or trace, the Evaluations tab shows run-level details, including the evaluation name, score, provider, judge model, method, and supporting metadata.

That detail matters because a failed score is only useful if teams can explain it. Engineers and evaluation owners can move from a low score to the exact prompt, response, trace, model, evaluator, and rationale that produced it.

Query, trend, and alert on evaluation scores

Because dt-evals writes results back as structured events, evaluation scores can be analyzed with the rest of your telemetry.

Teams can ask questions such as:

• Which evaluator has the lowest average score?
• Which services are producing the most failed evaluations?
• Did quality drop after a model or prompt change?
• Are hallucinations increasing over time?
• Is quality improving at the cost of latency or token usage?

For example, to get average score by evaluator you could write this query:

fetch bizevents
| filter event.type == "gen_ai.evaluation.result"
| summarize avg_score = avg(gen_ai.evaluation.score.value),
    by: { gen_ai.evaluation.name }
| sort avg_score asc 

Failed evaluations by service and metric can be determined with this query:

fetch bizevents
| filter event.type == "gen_ai.evaluation.result"
| filter gen_ai.evaluation.score.label == "fail"
| summarize failures = count(),
    by: { dt.service.name, gen_ai.evaluation.name }
| sort failures desc 

Trending is where evaluation data becomes more useful than a point-in-time report. A single failed score can show an issue. A trend can show whether quality is drifting slowly, whether a release caused a sudden drop, or whether a fix actually improved behavior over time.

On the AI Evaluation & LLM App Performance dashboard, teams can track trends in quality score, pass rate, failed evaluations, drift detections, evaluator health, run cadence, and pass/fail volume over time.

How to turn quality regressions into alerts

Evaluation results can also drive alerts. For example, a support agent team may want to notify the AI team when hallucinations appear in production, or when faithfulness drops for more than a few minutes.

name: support-agent-prod

alerts:
  notifications:
    - name: hallucination-detected
      metric: hallucination
      condition: count > 0
      window: 5m
      channel:
        type: slack
        connection: ai-observability-slack
        channel: "#ai-alerts"

    - name: faithfulness-regression
      metric: faithfulness
      condition: fail_rate > 10%
      window: 15m
      channel:
        type: email
        connection: ai-team-email
        to: [ai-team@example.com] 

Deploy the alerts with:

dt-evals alerts list ./support-agent-prod.yaml
dt-evals alerts apply ./support-agent-prod.yaml

Once applied, Dynatrace runs these checks continuously as Workflows. If hallucinations appear in the last five minutes, the team gets a Slack alert. If more than 10% of faithfulness checks fail over 15 minutes, the AI team receives an email. This turns LLM quality from something teams inspect manually into something Dynatrace can monitor and route automatically.

For continuous alerting, evaluation runs need to happen continuously or on a schedule. You can run dt-evals in CI for release checks (see our example here), run it manually during investigation, or deploy a scheduled runner for ongoing production evaluation. An alert is only as fresh as the evaluation results it carries.

Once configured, quality signals can be routed to the teams that need to act. If hallucinations appear in the last five minutes, the team can receive a Slack alert. If more than 10% of faithfulness checks fail over 15 minutes, the AI team can receive an email. This turns LLM quality from something teams inspect manually into something they can monitor and route automatically.

Close the loop in the AI software delivery lifecycle

Evaluation gates are most useful when they meet developers where they already work. Because dt-evals writes evaluation results back into the observability data layer, those results are not limited to dashboards or post-release reviews. They can be queried, inspected, and acted on from development workflows, CI/CD pipelines, and agentic coding environments.

For example, a team can run dt-evals after any change to a prompt, model, retriever, or agent tool, and then use dtctl (Dynatrace CLI tool for AI Agents) to query the resulting evaluation data, inspect related traces, review dashboards, or validate whether a release threshold was met. In an AI-assisted workflow, tools such as Claude Code, Cursor, GitHub Copilot, or an internal agent harness can leverage MCP or CLI access to bring that same observability context into the developer’s daily workflow.

That closes the loop of the AI software delivery lifecycle: teams can evaluate behavior, control rollout decisions, remediate regressions, and feed production learning back into the next development cycle. Quality signals are no longer in a separate report; they’ve become a part of how AI software is built, shipped, and operated.

Bring evaluations into the release process

Evaluation support is not just for inspection after something breaks. It can also help prevent regressions before they reach users.

This makes AI quality part of the release process. Teams can gate changes based on relevance, faithfulness, hallucination risk, prompt-injection risk, toxicity, or custom metrics, rather than relying solely on latency and error rate.

What makes this meaningful is that it’s the same pipeline teams already run. AI quality gates sit alongside the latency, error rate, and SLO gates teams have been using for years. There’s no second CI system, no second platform to learn, no second dashboard to monitor. Quality becomes one more dimension of the release decision, gated the same way performance is gated, by the same platform, in the same pipeline.

Coming next

The current experience makes evaluation results visible and actionable inside Dynatrace AI Observability. Next, the focus is on making evaluation workflows easier to run at scale and easier to compare across changes.

Planned improvements include targeted and bulk trace evaluations, custom evaluation libraries, evaluator versioning and lineage, baseline comparisons, experiment views, native quality gates, and deeper visibility into online evaluations.

These capabilities will help teams compare prompt and model variants, understand quality versus cost and latency tradeoffs, and detect sustained quality regressions before they affect more users.

Start today

To get started, check out the Git repository. You’ll need:

• Node.js 20 or later
• A Dynatrace environment with GenAI spans and the AI Observability app installed

• Credentials for the judge provider you want to use
• A service, trace sample, or CI workflow you want to evaluate

Then, install the CLI:

npm install -g @dynatrace-oss/dt-evals

Configure your service and judge provider:

dt-evals configure

Run your first evaluation:

dt-evals run --since 1h --sample 10

With Dynatrace AI Observability and dt-evals, teams can bring LLM and agent evaluations into the operational loop, where they can trace behavior, score outputs, trend results, alert on regressions, and gate releases before silent failures reach production.

The post Evaluate LLM and agent quality in Dynatrace AI Observability with dt-evals appeared first on Dynatrace news.

We have released Dynatrace Managed version 1.340. To learn what’s new, have a look at the release notes.

The post Dynatrace Managed release notes version 1.340 appeared first on Dynatrace news.

The Dynatrace MCP Server is now available in Port via Port MCP Connectors. A single OAuth flow connects it in minutes. Set up Port AI to communicate with Dynatrace, GitHub, Slack, and your service catalog in a single conversation, correlating production signals, code, and ownership in a single agent run rather than three browser tabs and a manual handoff. For incident triage, this turns a multi-tool investigation into a single prompt: just ask Port AI what’s wrong; you’ll get details about the failing service, the error signature, the file and function, and the suspect commit.

Ground every Port AI conversation in live production data from Dynatrace

Port is an agentic engineering platform that platform teams use to organize their software development lifecycle. It gives software and DevOps teams a central place where engineers can find system information, take action on it, and route work across their connected tools, without waiting on IT or operations.

Port AI is the assistant that queries the catalog using natural language. Through Port MCP Connectors, the same chat also reaches external systems, such as Dynatrace, GitHub, and Slack.

Dynatrace complements Port by providing context-rich observability and security insights, right where you need them:

The result: Team members ask a question in the Port AI chat, where they’re already working, and get back complete answers that no single tool could produce on its own.

Incident triage from a single Port AI prompt

The Dynatrace MCP Server provides Port AI with a set of tools it can call during any conversation. For incident triage, the most relevant needs are:

• Query production data. Logs, traces, metrics, and events from across the Dynatrace tenant returned in structured form.
• List open problems. An overview of all active problems on the tenant.
• Get problem details. Root cause, causal chain, and affected entities for a specific problem.
• Get troubleshooting guidance. Relevant troubleshooting guides matched to a problem description.

The full toolset also covers security findings, entity and topology lookup, query generation, forecasting, and more. See the Dynatrace Hub for the complete list. In combination with Port AI, these capabilities turn the Port AI chat into a single place to ask production questions.

The example below walks through the triage of an incident affecting broker_service, a fictional service. The same investigation, done manually without this integration, starts in Dynatrace (where the failing service shows up in seconds), then jumps to GitHub to scan recent commits, to Slack to confirm ownership, and back to a doc to write up the summary. With this Port AI integration, those steps run in a single agent run, with the Dynatrace signal at the center of the chain.

The scenario begins when broker_service degrades and lands as a new incident, INC-1003. In Port AI chat, an SRE asks, “Help me understand the root cause of INC-1003.”

Port AI loads the ai-incident-triage skill and runs the following steps:

1. Resolve the incident in Port’s catalog. Port AI looks up the incident entity and pulls the affected service identifier.
2. Query Dynatrace. The Dynatrace MCP Server queries logs and traces for broker_service. The response carries the first-seen failure timestamp and the top error signature.
3. Find the suspect commit in GitHub. Port AI passes the failure window to the GitHub MCP Server, locates the failing function, and lists the commits to that file. One commit aligns with the first-seen timestamp.
4. Return a structured triage summary. Port AI returns the failing service, the error signature, the file and function, and the suspect commit.
5. Post to Slack and close the loop. The Slack MCP Server posts the same summary to #incident-updates (Figure 2). The incident entity records a triaged_at timestamp through a Port self-service action.

Within a single agent run, the engineer receives a triage summary in Slack that already includes the live Dynatrace signal.

The same Dynatrace integration allows many more use cases, such as deployment correlation, on-call summaries, and postmortem drafts, each built as a Port AI skill.

Security triage works just as easily: ask Port AI about a vulnerability; the Dynatrace MCP Server returns the affected running services, severity, and exposed entities, while Port resolves ownership and routes the fix to the accountable team.

Roll it out across teams, govern centrally

The integration is designed for organization-wide rollout. Admins maintain central control over which tools are exposed and who can access them, while each query remains scoped to the user’s existing permissions.

• Per-tool selection. Admins choose which Dynatrace tools Port AI can call across the organization. Sensitive tools can be scoped to selected groups.
• Per-user authentication. Each user authenticates to Dynatrace through OAuth. Queries return only the data that their existing Dynatrace permissions already allow.
• Audit trail on both sides. Every Port AI call and every Dynatrace MCP call names the same person, with no stitching required between platforms.
• Scales without new workflows. The same per-user model that works for a pilot team works for hundreds of developers. No separate access-request workflow needed.

Get started: connect Port with Dynatrace

The Dynatrace MCP Server connects to Port through a single OAuth flow. Setup takes a few minutes and is done once by an admin.

• Add Dynatrace as a data source. In Port, go to Data Sources > + Data source > MCP Servers. Select Dynatrace, fill in the connector details, and select Connect to authenticate with your Dynatrace tenant.
• Expose the tools you want Port AI to use. Under Allowed Tools, add the Dynatrace capabilities you want available to your organization (querying production data, listing problems, getting problem details, finding troubleshooting guidance). Select Publish.
• Register the incident triage skill. Add the ai-incident-triage skill from Port’s skill library and point it at the incident entities in your catalog.

Once published, the integration is available to every authenticated Port user in your organization. Each user authenticates to Dynatrace individually through OAuth on first use.

For full setup walkthroughs, see Port documentation

Port MCP Connectors documentation: connector setup and admin configuration

Triage incidents with AI: full skill walkthrough

The post Port and Dynatrace: One-prompt incident triage with the Dynatrace MCP Server appeared first on Dynatrace news.

We have released Dynatrace version 1.340. To learn what’s new, have a look at the release notes.

The post What’s new in Dynatrace SaaS version 1.340 appeared first on Dynatrace news.

We have released Dynatrace OneAgent and ActiveGate version 1.339. To learn what’s new, have a look at:

• OneAgent release notes
• ActiveGate release notes

The post OneAgent release notes version 1.339 appeared first on Dynatrace news.

In May 2026, OpenTelemetry (OTel) officially graduated from Cloud Native Computing Foundation (CNCF). This milestone marks the cloud native ecosystem’s achievement of production readiness and maturity, thanks to the efforts of hundreds of companies and thousands of developers who believed in an open standard for observability and built it together.

OpenTelemetry was already the standard. Now it’s official.

If you’ve been shipping production code over the last few years, OpenTelemetry has almost certainly touched your tech stack, whether through its SDKs and collectors, or traces, metrics, and logs. For many teams, OTel has quietly become part of the default toolbox for building and operating modern applications. It solves a real problem: the industry needed a common language for telemetry data, and OpenTelemetry became that language.

CNCF graduation reflects the strength of the ecosystem: a diverse contributor base, widespread vendor support with proven production readiness, comprehensive security audits and a governance model built by the community, for the community and for future sustainability.

Why a shared standard changes everything

Graduation formalizes OpenTelemetry as the common protocol and shared language for observability:

1. A standard protocol allows different tools, open source and commercial, to work together.
2. Semantic conventions define how telemetry is named and structured. When all systems speak the same language, correlation becomes possible at scale.
3. OpenTelemetry decouples instrumentation from backend analytics, enabling teams to export telemetry data to any backend system and switch analytics platforms without rewriting code.
4. Standardized, high-quality telemetry data allows automation, anomaly detection, and AI-driven insights. A consistent protocol becomes critical as systems grow more complex and autonomous.

Dynatrace loves OpenTelemetry and open source

Dynatrace has been involved in shaping OpenTelemetry from its early days, contributing to the specification, semantic conventions, Collector, and many other areas, ensuring the standard works at enterprise scale. With over 46,000 contributions and 54,000 commits, Dynatrace is one of the top contributors to the project.

Our focus has always been clear: make OpenTelemetry production-ready without compromising its open, vendor-neutral model.

Beyond OpenTelemetry, Dynatrace actively contributes to over 30 open source projects, including W3C Trace Context, and integrations with Kubernetes, JMeter, and more.

Frequently asked questions

Is OpenTelemetry stable after CNCF graduation?

Yes. Graduation confirms that the core specifications, APIs, and data model are stable and suitable for long-term production use. Teams can adopt OpenTelemetry with confidence across environments and use cases.

Does OpenTelemetry lock teams into a specific vendor or backend?

No. OpenTelemetry decouples instrumentation from backend analytics. Teams can export telemetry data to any backend and switch platforms without rewriting instrumentation code.

How does Dynatrace support OpenTelemetry?

Dynatrace supports you wherever you are. You can ingest pure OpenTelemetry data natively; no proprietary agents are required. From there, you can query billions of spans in seconds, correlate metrics, logs, and traces automatically across petabytes of data, and get the full observability context.

Want to see OpenTelemetry in action?

Learn more about OpenTelemetry at Dynatrace Hub.

The post OpenTelemetry graduates: A milestone for the observability Open Source community appeared first on Dynatrace news.

A developer triaging a bug in Jira, or an on-call engineer responding to an alert in Jira Service Management (JSM), can ask their Rovo agent to investigate production issues in Dynatrace using plain language, without leaving Jira or JSM. The Rovo agent answers any relevant questions, calls the appropriate Dynatrace tools, and posts the results back to the Jira workspace. Admins can now complete setup in minutes. Every call runs with the permissions of the requesting user, every action is logged, and data access and cost remain under central control.

Move from “ask the platform team” to “ask the agent”

If your organization uses Dynatrace, much of your production knowledge may reside with the Dynatrace experts on your organization’s platform or SRE team. Everyone else (developers triaging Jira bugs, on-call responders running down JSM alerts, or support engineers handling escalations) either learns enough Dynatrace to investigate production issues on their own or pings the platform team and waits for a response.

The Dynatrace Model Context Protocol Server for Rovo moves this valuable production expertise into the Rovo agent, where it’s accessible to all Rovo users. The Rovo agent holds the Atlassian context (the bug, the alert, the service it relates to) and calls Dynatrace for the production context (problems, topology, root cause). Meanwhile, the developer asking the question gets a usable answer directly in the tool where they’re already working.

How does an on-call engineer use Rovo to triage a JSM alert?

A JSM alert is triggered when a service degradation is detected. The on-call engineer opens the alert’s response panel and asks the Rovo Ops Agent, Atlassian’s built-in AI agent for JSM incident response, to investigate.

Rovo Ops calls the Dynatrace MCP Server, retrieves the open problem, the root cause, and the related signals, and returns a single answer: what went wrong, what’s related, and what to do next. The on-call engineer either acts on this problem context directly or escalates the alert, with the full analysis already attached.

How does a developer triage a Jira bug with Rovo and Dynatrace?

Let’s say Jira provides details of a bug in a service that a developer doesn’t own. The developer asks the Rovo agent a question in the issue’s chat panel: “What’s going on with this service right now?” Rovo returns the open Dynatrace problem, the elevated error rate, and the dependency that’s causing the issue.

Rovo’s answer posts as a comment on the bug in Rovo, so the next person who opens the ticket sees the investigation is already done. From there, the bug typically closes as a duplicate of the active incident or routes to the team that owns the failing deployment, in minutes rather than hours.

How to roll out the Dynatrace MCP Server in Atlassian Rovo

MCP Server setup is a configuration task, not a project. The Dynatrace MCP Server is pre-approved by Atlassian as an external MCP integration and is included with Dynatrace SaaS at no extra cost. In a few clicks, an admin connects Dynatrace using the Rovo admin UI, authenticates against the Dynatrace tenant, and selects which tools to expose. Once connected, the integration is available across Jira, Jira Service Management, and Confluence.

The Dynatrace MCP Server tool set is ready for immediate use, providing data retrieval through Grail, topology and entity context, root cause analysis, active security findings, time-series forecasting, and change-point analysis.

Security, governance, and cost stay under administrator control

Admins keep control over security, governance, audit, and cost on both the Atlassian and Dynatrace sides.

• Per-user enforcement, end-to-end. Every Dynatrace call runs as the requesting user via OAuth 2.1, with authorization based on the user’s Dynatrace permissions. On the Atlassian side, Rovo and Rovo Ops only see the Jira and JSM data that the user is already entitled to see.
• Per-tool selection. From a checklist in the admin panel, administrators choose which Dynatrace tools the Rovo agents in the organization can call. (New tools released later must wait for admin approval before they become available.)
• Audit trail on both sides. Every Rovo invocation and every Dynatrace MCP call names the same person, with no stitching required between platforms.
• Usage and costs are observable in Dynatrace. Tool call volume can be observed with Dynatrace, and costs can be clearly attributed to data owners.
• Adding more Dynatrace users doesn’t increase your cost. Dynatrace consumption is priced on data, not per user, so onboarding more developers and on-call engineers doesn’t instantly impact your billed costs.

Get started with the Dynatrace MCP Server for Rovo now

The integration is generally available. To connect it:

1. In Atlassian Jira or JSM, go to Atlassian Administration → Rovo → Rovo MCP server.
2. Add the Dynatrace MCP Server and authenticate against your Dynatrace tenant.
3. Select the Dynatrace tools you want to expose to your Rovo agents.

Full setup instructions are available in the Atlassian documentation and the Dynatrace MCP Server documentation.

Because the MCP Server is included with Dynatrace SaaS, you can easily set up a pilot program. Just connect the integration for one dev team, allow them access to a narrow set of tools, and then monitor the team’s usage and related costs. The patterns that emerge (which tools are called, by whom, and at what cost) can serve as a basis for a confident wider rollout.

The post Dynatrace MCP Server for Atlassian Rovo: Investigate production problems without leaving Jira or JSM appeared first on Dynatrace news.

The April 2026 Dynatrace SaaS releases bring six updates aimed at a familiar problem: too much manual work between a signal and an answer. The updates focus on native cloud visibility, deeper Kubernetes insights, consistent severity handling, faster investigations, and smoother analytics work.

Explore all updates hands-on in the Release Radar launchpad.

A native Azure experience in Clouds

What does Dynatrace add for Azure practitioners?

Dynatrace now extends the enhanced Clouds experience to Microsoft Azure, putting Azure subscriptions on the same footing as AWS. Metrics, logs, metadata, and topology now sit in one managed view, so Azure teams can move from inventory to investigation without stitching the picture together by hand.

What you get out of the box

• Opinionated insights and ready-made dashboards built from enriched Azure telemetry, so investigations start with answers instead of a blank canvas.
• Pre-configured health alerts for Azure, created and managed directly in Clouds, with drill-down, search, and filtering directly in the Clouds app.
• Broad metric coverage for any Azure Monitor native platform metric across Azure services.
• A rich Azure topology inventory that periodically scans Azure environments and enriches resources with native metadata such as tags and subscription IDs, all queryable with Dynatrace Query Language (DQL).
• Simple onboarding and lifecycle management that turns Azure subscriptions into native Dynatrace connections and manages them centrally.

Dynatrace also adds drilldowns from cloud entities into the relevant Dynatrace experiences, so teams can keep moving instead of bouncing between cloud and platform views.

Kubernetes visibility for autoscaling and custom resources

What’s new in Kubernetes observability?

Dynatrace extends Kubernetes visibility to two additional object types that SREs and platform teams rely on daily: Horizontal Pod Autoscalers (HPA) and Custom Resources (CRs).

Horizontal Pod Autoscaler as a first-class object

HPA is now a first-class object in enhanced Kubernetes visibility. You can see when scaling kicked in, what triggered it, and how desired and actual replica counts lined up next to the workloads involved.

Custom Resource insights

You can monitor up to five Custom Resources per cluster, surfaced the same way as built-in Kubernetes objects. This brings CRD-heavy ecosystems such as Argo, Istio, Cert-Manager, Kyverno, and operator-managed databases into the same investigation scope as the rest of your cluster.

For clusters connected through cloud integrations, the Kubernetes cluster details page now exposes the underlying cloud configuration (EKS, AKS, or GKE) in YAML or JSON, making cloud-side and cluster-side state accessible in one place.

A unified severity model for alerts and problems

What is event.severity in Dynatrace?

Dynatrace introduces a standardized event.severity field for alerts and problems, aligned with the ITIL Incident Management framework. Severity is stored in Grail as an integer from 1 (Critical) to 5 (Informational) and is shown as a human-readable label across the platform.

Severity levels at a glance

Severity automatically propagates from correlated alerts to the parent problem, with the highest severity always taking precedence. This gives teams one severity model to filter on, route with, and escalate from.

You can now:

• Filter the problem feed by severity
• Display a severity column with visual icons in problem lists
• Use severity as a condition in Workflows for alert routing and notifications

Faster Investigations with Smartscape navigation

What changed in Smartscape?

Smartscape now offers all six ready-made views, such as vertical topology, horizontal topology, and visual resolution path, just a click away in a persistent side panel. You no longer need to return to the landing page in the middle of an investigation.

The new Recent views section shows your latest investigations, making it easy to reopen them, compare them, and keep working as you test a root-cause hypothesis.

The result is less backtracking in the middle of an incident.

Dashboards and notebooks: productivity improvements

What’s new for dashboard authors and analysts?

The latest release adds several practical upgrades for team members who build dashboards and work in notebooks every day.

• Treemap visualization for identifying dominant categories in hierarchical data, such as requests per service by Kubernetes namespace.

  

• Dashboard variables for dynamic coloring and thresholds, so visual conditions stay in sync with environment or team selectors.

  

• Centralized tile indicator controls, allowing you to show or hide warnings, descriptions, and custom timeframes at the dashboard level.

  

• Direct image upload in Markdown using a built-in image library shared across Dashboards, Notebooks, and the Launcher.

  

• Row marker coloring for tables, making it easier to visually group related rows without sacrificing readability.

  

User experience improvements

Why does the platform feel faster?

This release smooths out the path from the first symptom to root cause analysis. Tracing and services workflows now handle high-span traces more reliably, show timing more clearly, and surface useful sample traces earlier.

Table-first workflows also benefit from richer entity-detail tables, better filtering, and clearer structure, helping teams answer more questions without switching views. Navigation patterns, overlays, and error messaging are now more consistent across the platform, reducing mental overhead when time is tight.

Why these updates matter

Taken together, these updates eliminate inefficiencies in the work that teams do every day. Cloud operations teams, Kubernetes SREs, on-call engineers, and analytics authors get richer context, faster paths to answers, and simpler ways to share what they find. This is where Dynatrace earns its keep under pressure.

Explore the updates live in the Release Radar launchpad.

The post Dynatrace Release Radar 04.26 appeared first on Dynatrace news.

We have released Dynatrace version 1.339. To learn what’s new, have a look at the release notes.

The post What’s new in Dynatrace SaaS version 1.339 appeared first on Dynatrace news.

We have released Dynatrace Managed version 1.338. To learn what’s new, have a look at the release notes.

The post Dynatrace Managed release notes version 1.338 appeared first on Dynatrace news.

To help address this challenge, Dynatrace introduced new documentation and best practices for handling sensitive data.

This blog explains why the topic matters, what risks teams are trying to avoid, and how Dynatrace is designed to support privacy-first DEM adoption.

How privacy concerns slow DEM adoption

Across industries, we see the same patterns: Teams want granular and precise visibility to identify meaningful patterns and tailor improvements, while security, privacy, and compliance teams require strong guarantees around sensitive data handling. As a result, DEM adoption can be delayed or remain limited to basic use cases.

This is especially common in regulated environments such as banking and healthcare, where even well-intentioned monitoring can raise questions like:

• Are we collecting more data than necessary?
• Who can access personal data, and under what conditions?
• Are we handling sensitive data appropriately?
• Are we compliant with all our regulatory requirements?

Without clear answers and support, organizations may delay rollout, restrict access too aggressively, or avoid certain capabilities altogether.

Privacy by default in Dynatrace DEM

Dynatrace is designed with privacy-by-design principles:

• User sessions are anonymized out of the box
• Sensitive data can be masked at capture, storage, and read
• Access to sensitive fields is controlled through fine-grained permissions

Privacy settings are configured per frontend (web or mobile) and can be set independently based on each frontend’s risk profile and regulatory context.

Configure Dynatrace DEM for end-to-end compliance

Privacy and compliance should not be blockers to Digital Experience Monitoring, but they do require clear guidance and intentional configuration. Our DEM compliance guide explores two relevant use cases to help organizations identify which configuration options should be considered for their environments:

• Complaint resolution in an e-commerce web app: teams can utilize user tags to quickly identify affected sessions and resolve issues, while access to personal data remains tightly controlled.
• Troubleshooting performance issues in a mobile banking app: teams can gain insights and fix stability or performance issues while fully masking all personally identifying information.

Learn more

To meet data compliance requirements set by industry regulations, organizations must identify specific requirements and outline the steps to protect sensitive data. The new documentation helps organizations to expand or refine their use of Digital Experience Monitoring by demonstrating how to:

• Configure privacy settings for frontends
• Limit data collection
• Control access to sensitive fields
• Support troubleshooting and performance optimization without compromising compliance

The post How to build trust in Digital Experience Monitoring appeared first on Dynatrace news.

We have released Dynatrace version 1.338. To learn what’s new, have a look at the release notes.

The post What’s new in Dynatrace SaaS version 1.338 appeared first on Dynatrace news.

We have released Dynatrace OneAgent and ActiveGate version 1.337. To learn what’s new, have a look at:

• OneAgent release notes
• ActiveGate release notes

The post OneAgent release notes version 1.337 appeared first on Dynatrace news.

The March SaaS releases, 1.334 and 1.335, sharpen how teams investigate issues, apply business context, handle security findings, and manage governance. The platform gets more useful precisely when the pressure is on.

If you want to jump straight to our curated sandbox environment for the capabilities mentioned below, head over to our dedicated playground launchpad.

Actionable compliance insights

The Compliance Assistant is now generally available. It shifts compliance from a documentation effort to real-time insights, connecting rules, incidents, risks, and business-critical services while systems run. Validation happens as things move, not after the fact. DORA support comes ready-made. For example, you can:

• Map critical functions to IT assets through Business Flow.
• Track compliance health.
• Classify incidents against regulatory thresholds.

This means less chasing evidence across separate tools and better visibility into how business-critical processes really behave. Read our Compliance Assistant blog to learn how Business Flow and Smartscape® on Grail® tie compliance-critical business processes to the supporting IT components and identify related risks in an operational context.

Vulnerability findings that are easier to trust

Dynatrace now uses a native Dynatrace Vulnerability feed to detect vulnerabilities. The new feed delivers more accurate, transparent, and threat-aware vulnerability data while preserving strong coverage of critical risks.

The Dynatrace vulnerability feed is informed by multiple reputable sources, including OSV.dev, GitHub, NVD, and vendor advisories, and is then curated and enriched with Dynatrace’s own research. The result is better accuracy, clearer remediation guidance, and less noise when teams need to decide what to fix first.

These enhancements also support another March security change: Security Posture Management now uses CCSS-based severity classifications for benchmark rules. Together, these changes improve the quality of the vulnerability data that security teams work with, not just the number of findings.

Lookup tables allow adding more context easily

Lookup tables in Grail are now generally available, enabling teams to build dashboards and queries that reflect how their business works.

A lot of observability data is technically rich but hard to read in operational terms. The lookup tables blog shows exactly where teams feel that pain: dashboards full of cryptic identifiers, while customer, country, or store context lives somewhere else entirely. Joining Grail data with lookup tables at query time turns those IDs into readable business context inside DQL and dashboards.

Results become easier to act on. Spreadsheets, manual mappings, and custom processing outside the platform become unnecessary. Teams ask better questions and get answers in terms they recognize.

Extended Synthetic monitor enhancements

Synthetic monitoring is most useful when it explains why performance is slow and how to improve it. The March Synthetic monitoring blog showcases the updated browser monitor experience, which now includes:

• Richer execution details in Grail,
• DQL access to those events, and
• An enhanced Requests waterfall in the latest Dynatrace experience.

Instead of vague timing summaries, teams can use the new requests waterfall to:

• Inspect every loaded resource.
• See exact load durations.
• Identify initiators such as scripts or XHRs.
• Spot render-blocking behavior.
• Quickly find failed assets or retry attempts.

In practice, this means a slow Synthetic browser run is much easier to explain: Teams can see which resource caused the delay and quickly understand whether the issue lies in frontend code, third-party scripts, rendering, or network behavior.

Just as important, browser monitor executions are now stored as events in Grail and can be explored with Dynatrace Query Language. This gives teams a much better way to filter, aggregate, and correlate Synthetic results with other telemetry, and it opens the door to more useful dashboards, troubleshooting workflows, and automation. Dynatrace also adds support for enriching Synthetic data with primary Grail tags, making it easier to group results by dimensions such as team, application, or environment without additional post-processing.

Easy analytics with dashboards and notebooks

The March updates improve both dashboard creation and day-to-day analysis activities.

On the creation side, teams can resize multiple dashboard tiles at once, add tiles, and duplicate tiles without breaking the dashboard layout. Chart configuration is cleaner too, with a unified color palette and more powerful threshold controls across Dashboards and Notebooks, so teams can maintain visual consistency without extra UI friction.

On the analysis side, practical improvements were made to troubleshooting and data exploration. Dashboards now support annotations on time series charts, so deployments, alerts, problems, and custom events can be overlaid directly on metric trends, without context switching. Table workflows were also improved in both Dashboards and Notebooks: the new details panel lets teams inspect wide rows in a side panel, while pinned columns keep key identifiers visible as you scroll through larger result sets.

For teams watching cost and usage, the new Usage – Logs ready-made dashboard shows log-query consumption across the platform, helps spot spikes, and highlights which dashboards and notebooks are driving the most usage. This gives teams a better way to understand which views are expensive and where optimization work will pay off most.

Closing thoughts

Above all, our March updates make Dynatrace easier to use in real situations.

Compliance is tied more closely to the live operational context. Security findings are supported by stronger signals. Grail can incorporate business metadata more naturally. Synthetic browser runs are easier to investigate. And teams get better access to analytics through a variety of dashboard and notebook enhancements.

Teams will feel the difference when they investigate, prioritize, and decide.

The post Dynatrace Release Radar 03.26 appeared first on Dynatrace news.

Dynatrace helps you answer these questions by extending AI observability for a new wave of coding agents, including Claude Code, Google Gemini CLI, OpenAI Codex CLI, OpenCode, and GitHub Copilot SDK. Together, these integrations give engineering leaders, platform teams, and developers a consistent way to understand agent activity, token consumption, costs, tool behavior, and runtime impact: without forcing teams to stitch together fragmented telemetry across terminals, SDKs, dashboards, and development workflows. Dynatrace public AI agent instrumentation examples on GitHub demonstrate how to provide industry leading observability that drives performance, cost efficiency, and governance across complex, distributed AI-driven systems—all through a unified Dynatrace platform experience that developers can access directly via MCP without leaving their IDE.

From agent activity to engineering insight

As organizations adopt multiple coding agents, new adoption challenges emerge. One team might use Claude Code in the terminal, another may build internal tools with GitHub Copilot SDK, while others experiment with Gemini CLI or Codex CLI. Platform teams want visibility into usage, availability, and costs. Engineering leaders want to know whether agents improve delivery. Security and governance teams want confidence that all prompts, tool usage, and actions can be monitored appropriately.

Dynatrace provides a practical answer to these challenges: a single observability layer for agile development workflows. For agents that emit OpenTelemetry directly, such as Claude Code, Gemini CLI, and Codex CLI, Dynatrace can ingest telemetry related to sessions, tokens, costs, tool executions, errors, and performance. For GitHub Copilot workflows, Dynatrace adds production context, software delivery automation, and GitHub-based integrations that connect agent activity to real engineering workflows.

The payoff is clear. Developers gain visibility into how agents behave in real work. Platform teams can track adoption, usage trends, and cost signals. Engineering leaders can correlate agent activity with commits, pull requests, and delivery outcomes. And with an MCP-enabled production context, teams can connect coding-agent actions to what is happening in production.

“Before we instrumented Claude Code, we had no easy way to break down how our engineers actually used AI, which models, for what tasks, and at what cost. Now we can pinpoint inefficient model use and guide usage toward better cost-performance tradeoffs.”
— Markus Heimbach, Senior Director Software Development

Multiple coding agent experiences, one observability strategy

Each coding agent has a different operating model, which is why a common observability layer matters.

Claude Code

Claude Code already supports built-in OpenTelemetry, making it easy to send metrics and logs to Dynatrace with no code changes. Teams can track sessions, tokens, costs, tool activity, API health, and engineering output such as commits and pull requests. Logs, dashboards, and alerts help teams investigate failures, spot latency spikes, and catch unusual spend or error patterns early.

Gemini CLI

Gemini CLI includes OpenTelemetry-based observability and preconfigured dashboards, making it a strong fit for Dynatrace AI observability. Teams can correlate agent activity with broader platform signals and move quickly from raw telemetry to action. This includes debugging failed runs, identifying slow or error-prone tool calls, and alerting on cost or reliability regressions.

Codex CLI

Codex CLI supports opt-in OpenTelemetry monitoring, giving teams a path to audit usage and strengthen governance across CLI, IDE, and app experiences. With Dynatrace, logs and traces help investigate request flows, delays, and failures across agent workflows. Alerts can flag degraded reliability, unexpected behavior, or rising token consumption before they become larger issues.

GitHub Copilot SDK

GitHub Copilot SDK lets teams embed agentic workflows directly into applications, while Dynatrace adds live observability and security context. This matters because embedded agents become part of real engineering and production-adjacent workflows. Dynatrace helps trace execution paths, use logs for debugging and auditability, and set alerts for failures, latency, or policy-relevant events.

OpenCode

OpenCode is a terminal-based AI coding agent that helps developers work through coding tasks directly from the command line. Because OpenCode ships with native OpenTelemetry support, teams can route telemetry to Dynatrace without code changes by setting standard OTLP environment variables. With Dynatrace, teams can track LLM call volume, session activity, tool usage, request latency, and workflow behavior across real developer sessions. Traces help teams inspect LLM requests, tool executions, session lifecycle events, message processing, file snapshots, or diff operations.

Across all operating models, the value is the same: one strategy for monitoring adoption and impact, understanding costs, logging and tracing agent activity, alerting on reliability issues, and debugging real-world workflows as coding agents scale across the enterprise.

Why this matters now

Teams are no longer asking whether coding agents are useful. They’re asking how to drive adoption, scale them safely, govern them consistently, and prove their impact. That requires visibility into usage, cost, reliability, and engineering outcomes across teams and tools. Dynatrace helps organizations make that shift with the observability and production context needed to expand coding-agent adoption with confidence.

The coding-agent market is moving fast. Claude Code, GitHub Copilot SDK, Google Gemini CLI, and OpenAI Codex CLI each represent a different path toward agentic software delivery, from terminal-based workflows to embedded SDKs and governed local execution. At the same time, Dynatrace has been expanding its developer-facing AI surface with the Dynatrace MCP Server, GitHub Copilot integrations, and AI observability capabilities built to connect agent behavior with real production systems. The timing matters because teams are no longer evaluating whether coding agents are useful. They’re deciding how to drive adoption, scale up usage safely, govern usage consistently, and measure real impact.

Ready to see AI coding agents through a Dynatrace lens?

With Dynatrace, teams can understand adoption, spend, reliability, tool behavior, and engineering outcomes in one place, while giving agents access to the live production context they need to make better decisions.

Whether your developers are working in Claude Code, building on GitHub Copilot SDK, experimenting with Gemini CLI, or adopting Codex CLI, Dynatrace helps bring observability, governance, and production awareness into the heart of agentic software delivery.

Public examples already demonstrate this approach for Claude Code, and the broader Dynatrace MCP and AI observability ecosystem provides the foundation to extend the same value across the next generation of coding agents.

Ready to learn more?

In our Git repository, you’ll find step-by-step examples for supported coding-agent workflows, including how to configure OpenTelemetry export, send telemetry data to Dynatrace, and use the provided dashboards to analyze the activity of your AI coding agents.

The post Dynatrace expands AI Coding Agent monitoring for Claude Code, Google Gemini CLI, Codex CLI, OpenCode, and GitHub Copilot SDK appeared first on Dynatrace news.