Enterprise computing just got a major upgrade. With the launch of IBM z17™, organizations running mission-critical workloads now have access to a platform purpose-built for AI at scale, end-to-end automation, and advanced security capabilities. For the enterprises that run the world’s most important transactions in banking, insurance, retail, and government, this is a significant step forward.

A more powerful platform also means more complexity to manage. More AI workloads in production, more transactions per second, and more pressure on the teams responsible for keeping it all running.

That’s where Dynatrace comes in. As a trusted IBM partner, Dynatrace brings AI-powered, full-stack observability to the mainframe, giving teams the visibility and intelligence they need to operate IBM z17 environments with confidence.

IBM z17™: A new era for enterprise AI and automation

IBM z17 is designed for the next era of enterprise computing, bringing AI, automation, and security closer to the mission-critical transactions that run the business.

With the IBM Telum II™ processor and IBM Spyre™ Accelerator, organizations can run AI inferencing directly within transaction flows, helping support real-time decisions without moving data off-platform.

But as AI-powered workloads become more embedded in core systems, teams need more than infrastructure performance. They need real-time visibility into how those workloads behave across the full hybrid environment.

The observability challenge on the mainframe

As organizations accelerate AI adoption and automation on IBM z17, how do teams know it’s all working?

Mission-critical mainframe workloads have always been difficult to observe. Legacy monitoring tools were built for a different era, designed for periodic sampling rather than real-time intelligence. They tell you something went wrong after the fact, not why, and not how to fix it.

Bringing AI inference into live transaction flows raises the stakes. Unexpected model behavior, workload spikes, or latency issues can affect critical services, so teams need to understand what is happening and respond in seconds, not hours.

Dynatrace mainframe monitoring is built specifically to close that gap.

Dynatrace mainframe monitoring: Full-stack visibility for the core

Dynatrace mainframe monitoring gives enterprises deep, real-time visibility into their IBM Z environments, unified with the rest of their technology stack in a single platform, helping to reduce silos, minimize manual correlation, and support more informed decision making.

Here is what that means in practice:

• Real-time performance monitoring. Dynatrace continuously monitors CPU utilization, response times, transaction throughput, and resource consumption on IBM Z, surfacing anomalies when they occur rather than after a batch job completes.
• AI-powered root cause analysis. Dynatrace Intelligence, an agentic operations system, can analyze billions of dependencies across mainframe, cloud, and hybrid environments. When something goes wrong, Dynatrace Intelligence pinpoints the root cause, reducing mean time to resolution and freeing teams from manual investigation.
• End-to-end transaction tracing. Dynatrace traces transactions across the full hybrid stack, from the web front end through microservices, APIs, and into the mainframe core. Teams get a complete picture of how workloads behave across every tier.
• Unified observability across hybrid cloud. Whether workloads run on IBM z17, in a public cloud, or in containers on OpenShift, Dynatrace brings it all into a single view. No more switching between tools or reconciling data from disconnected systems.
• Security and compliance insights. Dynatrace can surface runtime vulnerabilities, detect unusual behavior, and generate compliance-relevant telemetry to extend the security capabilities built into IBM z17.

IBM z17 and Dynatrace: From infrastructure power to operational intelligence

IBM z17 delivers the infrastructure power: AI at the core, intelligent automation, and ironclad security. Dynatrace delivers the operational intelligence: real-time visibility, automated answers, and end-to-end context. Together, they give teams what they need to harness that power with confidence.

In practice, that means organizations can:

• Accelerate AI adoption on IBM z17 with the observability to validate model performance and catch issues before they impact customers.
• Automate IT operations from the mainframe to the cloud with AI-driven insights that eliminate manual toil.
• Better maintain the reliability, security, and compliance that mission-critical environments demand, with enhanced transparency across every workload.

IBM z17 raises the ceiling for what enterprise infrastructure can do. Dynatrace enables organizations to see everything happening across it and act on operational intelligence in real time.

See what’s possible

If your organization runs workloads on IBM Z, now is the moment to ensure you have the observability to match the platform’s capabilities. IBM z17 is built for the future of enterprise computing. Dynatrace is built to help you operate it.

The post Seeing the core clearly: Dynatrace mainframe monitoring meets IBM z17 appeared first on Dynatrace news.

​Observability began in a world where software was more predictable. You could usually see what went wrong and where. AI changes that. Now a system can be technically healthy and still produce a bad answer, break a policy, or quietly burn money at scale.​

That shift is forcing observability to evolve quickly. It must account for behavior, judgment, cost, and risk, not just uptime. That’s why we’re proud to share that Dynatrace has been named a Leader in the 2026 Gartner® Magic Quadrant™ for Observability Platforms, marking the 16th time Dynatrace has been recognized as a Leader in this report. We think Dynatrace continues to deliver consistent business value for our customers at scale as technology evolves.​

We believe this recognition reflects a simple reality: Teams need a unified view across applications, infrastructure, cloud environments, and AI systems in one place, with the context to get answers—not guesses—about what is happening, why it matters, and what to do next.

The AI era demands end-to-end visibility​

Observability was already under pressure. Cloud-native architectures, distributed systems, and constantly changing environments made it harder to follow cause and effect across the stack. AI raises the stakes.​

AI systems do not fail like traditional software. They can look healthy at the system level while producing low-quality outputs, violating policy, exposing sensitive data, or quietly consuming far more resources than expected. Those problems often sit outside the view of conventional monitoring tools. And when observability is fragmented across separate products, teams lose the context they need to understand how AI behavior connects to infrastructure, applications, and business outcomes.​

Organizations need a complete, connected view from GPU to business outcome. That is what makes it possible to adopt AI safely, operate it confidently, and avoid trading speed for risk.

The Dynatrace difference: A unified platform, powered by AI and built for AI​

Dynatrace approaches observability with a unified platform, not a collection of fragmented tools. Built on Grail®, Smartscape®, and Dynatrace Intelligence — with integrations into the tools, clouds, and AI agents your teams already rely on — the platform brings together a unified data foundation, real-time contextual understanding, and AI-powered intelligence to help teams understand complex systems and act with confidence.​

That matters for two reasons:​

• Dynatrace is powered by AI. Dynatrace applies deterministic AI to deliver precise, trustworthy answers across applications, infrastructure, and cloud environments. Dynatrace agentic AI can then act on those answers, helping teams move faster, resolve issues sooner, and execute at scale with confidence. ​
• Dynatrace is built for AI. AI is now becoming part of the software stack itself, and it introduces new failure modes that traditional observability cannot fully explain. Dynatrace gives teams visibility into what their AI is actually doing — not just how the system is performing — with insight into performance, cost, quality, and compliance, all on the same platform and with no additional tooling required.​

Together, these capabilities help organizations move beyond isolated dashboards and alerts. They make it possible to observe, analyze, and automate across modern environments with the context required to keep AI systems reliable, governed, and aligned to business goals.​

We believe this recognition reflects where the market is going

The observability market is changing quickly as organizations invest in AI-powered applications, modernize technology stacks, and look for ways to reduce operational complexity. In this environment, platform depth, unified data, context, and AI matter more than ever.​

​We feel Dynatrace’s continued recognition as a Leader reflects the strength of this approach: A platform that helps customers unify and contextualize data across complex environments, transform it into actionable answers, and support intelligent automation at scale. We think sixteen times as a Leader also speaks to consistent delivery through wave after wave of technology change.​

Read the full Gartner® report​

We’re proud of this recognition, and grateful to the customers, partners, and teams that continue to push observability forward with us.​

Read the 2026 Gartner® Magic Quadrant™ for Observability Platforms to learn more about why Dynatrace was recognized as a Leader and how we think the category continues to evolve in the AI era.

FAQ​

What does it mean that Dynatrace was named a Leader in the Gartner® Magic Quadrant™ for Observability Platforms?​

The Gartner Magic Quadrant evaluates vendors based on Completeness of Vision and Ability to Execute. We believe Dynatrace’s position as a Leader reflects the strength of our unified observability platform and our ability to help customers manage modern complexity at scale in the AI-era.​

Why does observability need to change in the AI era?​

AI introduces new kinds of operational risk. A system can appear healthy while still producing poor outputs, violating guardrails, or increasing cost. Teams need observability that can connect AI behavior to the rest of the environment and provide context across performance, cost, quality, and compliance. ​

What makes the Dynatrace approach different?​

Dynatrace combines a unified data foundation, real-time topology and context, and AI-powered intelligence in one platform. That lets teams move from fragmented signals to precise answers and intelligent action, without relying on separate tools to understand AI systems. Dynatrace offers a combination of:
​
– A unified platform with Grail® lakehouse, exabyte-scale data foundation​
– Business-aware insights with Smartscape® real-time topology and contextual understanding
– Answers, not guesses and governed agentic automation with Dynatrace Intelligence

Gartner Disclaimer

Gartner, Magic Quadrant for Observability Platforms, Padraig Byrne, Martin Caren, D.B. Cummings, Neil Young, 13 July 2026

Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s Research & Advisory organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

Gartner and Magic Quadrant are trademarks of Gartner, Inc. and/or its affiliates

Dynatrace was recognized as Compuware from 2010-2014.

The post Dynatrace named a Leader in the 2026 Gartner® Magic Quadrant™ for Observability Platforms for the 16th consecutive time appeared first on Dynatrace news.

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.

IT modernization planning for Federal agencies spans multi-year cycles: platform decisions made at a point in time must sustain through implementation timelines and evolving technologies. A vendor may be certified today, but will their technology still meet an agency’s requirements when a program reaches full operating capability tomorrow?

Federal agencies are modernizing through hybrid cloud transformation and AI adoption while threat actors are using AI to accelerate attack velocity. The pace of change in this environment demands technology that is purpose-built for it—an AI-native platform that can process, analyze, and act on the scale of data that modern environments generate.

At this moment of increased pressure on government agencies, Dynatrace is building its platform to operate across the higher security baselines that evolving federal missions require.

Where does Dynatrace stand today on FedRAMP?

The Dynatrace platform is not a new entrant to the federal market and FedRAMP certification. Dynatrace has held FedRAMP Moderate authorization since 2020 and completed reauthorization in 2024 under NIST SP 800-53 Revision 5, including expanded coverage for Dynatrace Application Security, which is becoming more crucial as attackers increasingly use AI to accelerate threat velocity.

Dynatrace is building the stringent compliance and regulatory requirements of FedRAMP Class D into its newest platform generation first—so that when certification is achieved, agencies get access to the platform’s full capability set. This full-platform compliance posture serves agencies with the most demanding security requirements. Federal agencies across civilian, defense, and intelligence sectors have been running mission-critical workloads on the Dynatrace platform for years—many in air-gapped environments.

What does FedRAMP Class D certification mean, and how does it differ from Class C?

FedRAMP High covers the government’s most sensitive unclassified data—workloads where a compromise could cause severe or catastrophic harm to national security, public safety, or critical infrastructure. Moderate covers systems where the consequences of a breach are serious but not catastrophic. The certification level an agency requires is determined by the sensitivity of the data the system processes, following the FIPS 199 high water mark rule: if any data type in scope qualifies as High impact, the entire system requires FedRAMP High.

The table below summarizes the key control baselines of NIST SP 800-53B, the regulation that governs FedRAMP, and some key differences between the Class C and Class D baselines.

For agencies currently running Dynatrace under FedRAMP Moderate, this pursuit is additive—the existing Class C (Moderate) certification remains fully in place. For agencies with workloads that span both baselines, the goal is to support both within a single platform.

What does the timeline for FedRAMP Class D certification look like?

Agency-sponsored certification paths typically run 18 to 36 months from formal initiation, although the exact timeline to complete the process varies for every provider. Announcing intent ahead of formal certification signals the strategic intent and direction Dynatrace is taking and gives agencies the visibility they need to plan.

What distinguishes the Dynatrace approach is sequencing. Rather than pursuing certification on an existing platform and then engineering to meet the boundary, Dynatrace is building the required architecture on its newest platform generation first—so that when certification is achieved, agencies get access to the platform’s full capability set. Dynatrace will communicate clear milestones, including reaching “In Process” status on the FedRAMP marketplace, as they occur.

What does FedRAMP Class D certification mean in practice for agencies?

For agencies evaluating Dynatrace today, the practical implication is continuity. Agencies don’t have to choose between what their current requirements demand and what a future, more sensitive program will require. Dynatrace is building the platform to meet them where they are today and scale with them as their mission security requirements evolve.

The Dynatrace government portfolio is designed around customer- and partner-managed deployments within agency-defined operational boundaries, ensuring data sovereignty and control across all classification levels. The FedRAMP Class D pursuit is intended to extend that compliance posture to the cloud-hosted baseline, making it available in both environments.

The Dynatrace roadmap also extends beyond FedRAMP Class D to include Department of Defense and other evolving government security standards, reinforcing its commitment to the full spectrum of public sector security requirements.

Why does AI-powered observability matter for this mission?

Federal agencies are accelerating hybrid cloud transformation, AI adoption, and modernization at the same time they’re managing increasingly complex security environments. Maintaining operational visibility across all of it—cloud, data center, and air-gapped infrastructure—requires more than monitoring. It requires precise answers, automated remediation, and the ability to understand causality across a full-stack environment in real time.

That’s what Dynatrace brings to the mission: AI-powered, full-stack observability that supports performance and security for every application, every device, and every user, regardless of where they operate. Achieving FedRAMP Class D certification means that capability will be available to agencies handling the government’s most sensitive workloads.

Agencies and partners interested in discussing Dynatrace’s public sector direction can contact their Dynatrace representative or visit dynatrace.com/solutions/industry/public-sector. For the full announcement, read the press release.

FAQ

What is FedRAMP Class D (High), and why do I need it?

FedRAMP Class D is the certification baseline for cloud services that handles the government’s most sensitive, unclassified data. If a breach could cause severe or catastrophic harm—to national security, public safety, or critical infrastructure—Class D certification is a compliance requirement, not a choice.

What is FedRAMP Class C (Moderate)?

FedRAMP Class C is the certification baseline for cloud services that handle Controlled Unclassified Information (CUI) where a breach would cause serious but not catastrophic harm. It’s the most common federal certification, covering the majority of civilian agency cloud use cases. Dynatrace has held this certification since 2020.

What are the differences between FedRAMP Class C and FedRAMP Class D?

The core difference is data sensitivity and consequence. Class C covers systems where a breach causes serious but recoverable harm. Class D covers systems where a breach could be catastrophic—national security, critical infrastructure, emergency services. Class D requires roughly 90 additional controls, with stricter thresholds across authentication, monitoring, and incident response.

Does Dynatrace have FedRAMP Class D certification today?

No. Dynatrace has announced its intent to pursue FedRAMP High authorization. The company currently holds FedRAMP Moderate authorization, achieved in 2020 and reauthorized under NIST SP 800-53 Rev. 5. FedRAMP High authorization is an active engineering and compliance effort, and Dynatrace will communicate milestones as they occur.

Who will benefit from Dynatrace achieving FedRAMP High authorization?

U.S. federal agencies handling the government’s most sensitive unclassified data—including defense, intelligence community, and highly regulated civilian agencies—will be the primary beneficiaries. The authorization will also extend to state and local government agencies, commercial customers working with federal agencies, and global public sector organizations operating in environments that require elevated security and compliance standards.

What’s the typical timeline for achieving FedRAMP High authorization?

Agency-sponsored authorization paths typically run 18 to 36 months from formal initiation. Dynatrace is not committing to a specific completion date but will communicate milestones—including reaching “In Process” status on the FedRAMP marketplace—as they occur.

How does this announcement affect the existing Dynatrace FedRAMP Moderate authorization?

For customers using Dynatrace Managed, the Dynatrace FedRAMP Class C (Moderate) authorization remains in place, and agencies running on that baseline are not impacted. The FedRAMP Class D (High) pursuit is additive, and intended for the Dynatrace third-generation platform.

Does Dynatrace support air-gapped and on-premises deployments?

Yes. Dynatrace supports customer- and partner-managed deployments within agency-defined operational boundaries for the most sensitive missions. The FedRAMP High effort extends this compliance posture to the cloud-hosted baseline—it does not replace existing deployment options.

The post Dynatrace plans FedRAMP Class D (High): Why it matters for agency strategic planning 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.

I think a lot of developers are quietly afraid right now. Not because AI is going to replace them any time soon. Most experienced developers don’t actually believe that.

The fear is more subtle than that. They’re afraid of getting left behind, learning the wrong tools or building the wrong way. Afraid that younger developers are adapting faster or that others understand all of this better.

I feel that pressure too.

I use Claude® Code CLI constantly. Every day. At this point I can’t imagine building software without it. I’m dramatically faster than I was a year ago, and the amount of experimentation I can do now is honestly kind of incredible. Yet when I open Reddit, LinkedIn, BlueSky, Twitter, YouTube, even TikTok, suddenly I’m hearing about:

• New coding agents
• Orchestration systems
• Autonomous workflows
• MCP setups
• Self-healing applications
• AI IDEs
• AI browsers
• AI terminals
• AI everything

And every one of them is apparently “the future.” How do you know what to ignore and what to adopt?

Look for people who are working in public and demonstrating real value

There’s a lot of confusion around productivity in AI conversations. People equate productivity with:

• More generated code
• Faster feature completion
• One-shot demos
• Or “look what I built in six minutes”

But none of that necessarily creates value. I can generate a giant pull request full of AI code this afternoon. That doesn’t mean it survives:

• Integration tests
• Security review
• Observability requirements
• Real users doing unpredictable human things

Real productivity is delivering value to users more quickly. AI helps with that, but developers waste enormous amounts of time chasing hype right now. Good marketing does not automatically equal good value. I’ve seen tools receive massive amounts of attention that, once I dug deeper, simply didn’t improve my workflow in any meaningful way.

The tools that matter are the ones that genuinely make you more productive while still allowing you to maintain understanding and control over what you’re building. That balance matters to me. I don’t want to become disconnected from the software itself.

Yes, developers should pay attention to what other people are doing. Part of being a software engineer has always been committing yourself to continuous learning. You should read Reddit. You should follow developers on social media. You should pay attention to emerging workflows and ideas.

But you also need to learn how to distinguish hype from value. Look for the people who are actually building things in public. Look for the people sharing process instead of certainty.

Ask yourself: “Was this content created to share knowledge, or to drive engagement?”

Those are very different things.

The people I trust most right now are usually the ones showing unfinished work, explaining tradeoffs, discussing failures, and sharing lessons learned from actual implementation. Not the people pretending they’ve solved software development permanently because they chained six agents together in a demo video.

That’s exactly how I ended up changing workflows myself. A friend of mine seemed to be moving leaps and bounds faster than I was. He had piles of documentation, a giant application, and everything looked polished and organized. So, I asked him to show me what he was using.

That was the first time I saw Claude Code CLI in action. Everything clicked. It had access to the filesystem. It could read the actual code I wanted modified. It could maintain context across the project. It could document what it was doing and why.

For the first time, AI coding stopped feeling like a clever autocomplete tool and started feeling like a genuine development partner. I instantly saw productivity, and it was real, not hype.

Keeping learning by doing

The developers who are adapting well right now are not the ones consuming the most AI content. They’re the ones building with AI consistently.

You need reps. The same way you learn almost anything else. You do not become a better golfer by watching YouTube videos about golf swings. At some point you need to stand over the ball and embarrass yourself for a while.

AI coding is the same thing. You need to build things. Not startup ideas. Not the next billion-dollar SaaS. Not some massive architecture astronaut project. Solve a problem in your own house. Maybe your family needs a better way to plan meals. Maybe you want to track something like the number of times you turn off light switches. Maybe you want a better view into your finances.

Those are the best projects right now because you already understand what success looks like. You can judge whether a tool helped you succeed. And you develop real skill that will transfer to whatever the next big thing is.

The post Quit trying to keep up with every new AI tool and keep building appeared first on Dynatrace news.

Enterprise AI is rapidly evolving from standalone models to agentic AI systems, where multiple AI agents collaborate to gather information, reason across data sources, and generate complex outputs. These systems unlock powerful new capabilities, but they also introduce significant operational challenges. Organizations must be able to observe, govern, and optimize AI agents, models, and infrastructure in real time.

Dynatrace helps support this need by providing broad visibility across key layers of the AI stack—from agent orchestration and model inference to GPU infrastructure and enterprise applications. With Dynatrace, teams can monitor AI workflows, understand model behavior, optimize costs, and help improve reliability as agentic systems scale.

Why agentic AI needs full-stack observability

As organizations build GPU-accelerated platforms for AI training and inference, understanding system behavior becomes increasingly complex, with bottlenecks potentially occurring anywhere – from GPU utilization, model latency, token consumption, and downstream service dependencies.

Dynatrace connects these layers through full-stack AI observability, designed to help teams monitor model performance, trace multi-agent workflows, track GPU and infrastructure utilization, detect bottlenecks across AI pipelines, and potentially accelerate troubleshooting with AI-powered root cause analysis.

This unified visibility helps organizations run AI workloads with the same reliability, efficiency, and operational confidence expected from modern enterprise systems.

This unified visibility helps organizations operate AI workloads with improved visibility and operational confidence. By integrating with NVIDIA AI–Q Blueprint and the NVIDIA Agent Toolkit, Dynatrace enriches agent reasoning with high-quality operational telemetry while at the same time helping teams govern and identify opportunities to optimize costs.

How Dynatrace addresses Agentic AI

Dynatrace is designed to assist your team with monitoring infrastructure usage and model behavior and detecting pipeline bottlenecks and token consumption while improving reliability by accelerating troubleshooting and root cause analysis. It also provides a unified view of AI workflows from agent to model down to the infrastructure, allowing organizations to support responsible AI operations, manage cost, improve performance and support agentic workflows at scale.

Every agentic deployment is customized with different agents, tools, models, and data pipelines; therefore, observability is an important capability for understanding how these systems behave in production. The complexity arises as agents interact with multiple enterprise data sources, including:

• internal datasets
• external web and knowledge repositories
• proprietary research systems
• models served through NVIDIA NIM and Nemotron

Dynatrace can serve as operational data source for AI agents that may help improve the quality of generated insights and enable more informed decision-making. With flexible integration across customized AI-Q implementations, this architecture also lays out the groundwork for automated analysis, research, and decision making.

How Dynatrace integrates NVIDIA AI-Q

By combining NVIDIA’s AI-Q Blueprint with Dynatrace AI observability, organizations gain the transparency and operational intelligence needed to govern, optimize, and scale complex AI systems.

Dynatrace integrates into AI-Q environments in two ways.

1. Observability and cost intelligence for Agentic AI workflows

The NVIDIA Agent Toolkit generates lightweight OpenTelemetry traces that Dynatrace ingests to visualize agent workflows and model interactions.

Dynatrace automatically maps the underlying infrastructure supporting AIQ deployments including NVIDIA NIM and Nemotron microservices and enriches telemetry with AI-specific signals such as:

• token usage
• inference latency
• model metadata
• GPU utilization

This provides comprehensive visibility across key components including:

• AI models and inference workloads
• agent orchestration pipelines
• GPU and infrastructure resources
• enterprise data interactions

With these insights, teams can quickly detect performance bottlenecks across agent pipelines, monitor GPU utilization and overall infrastructure health, and identify inefficient model usage. This visibility can help organizations identify cost optimization opportunities associated with AI workloads. Together, these capabilities position observability as important components for building reliable and scalable AI systems.

2. Dynatrace as a high-quality data source for AI agents

Dynatrace can also serve as an operational intelligence source for AI agents.

Through Model Context Protocol (MCP) integrations, Dynatrace exposes telemetry that agents can use in their reasoning workflows, including:

• infrastructure performance metrics
• operational incidents and problems
• deployment and reliability trends
• system behavior and resource consumption

This allows AI agents to incorporate real-time operational insights into their decision-making. Instead of relying solely on external data, agents gain contextual awareness of enterprise systems, which may support more informed outputs Dynatrace ingests NVIDIA Agent Toolkit OpenTelemetry traces, model telemetry, and infra metrics exposing operational context via MCP.

Together, these technologies create a powerful foundation for deploying deep research in the enterprise as reflected in the picture below.

AI-Q use cases

The following are illustrative examples of what becomes possible when AI-Q-based research agents incorporate Dynatrace operational data and insights into their reasoning workflows. While NVIDIA AI-Q is a reference framework rather than a formal certified Dynatrace integration, these scenarios show how agentic research systems could use Dynatrace AI observability to generate richer analysis, identify patterns, and support more informed decisions.

Infrastructure migration analysis

AI agents combine Dynatrace operational telemetry such as performance trends, incidents, and deployment velocity with infrastructure and cloud cost data to evaluate platform migration scenarios (for example, OpenShift to AKS). The system produces data-driven recommendations with quantified tradeoffs to support strategic decisions.

Large-scale incident analysis

By analyzing thousands of historical problems, AI agents can identify recurring patterns, understand infrastructure behavior, and correlate technical issues with business KPIs. This enables deep operational insights and long-form analysis that would be difficult and time-consuming for humans to produce.

AI cost governance and optimization

Enterprises can use observability data from Dynatrace to analyze token consumption, model usage, and inefficient data interactions across AI workloads. Agents can identify patterns and suggest potential optimizations such as more efficient models or improved workflows.

Software delivery and reliability insights

DevOps and SRE teams can use agentic analysis to correlate deployments with incidents, assess build quality trends, forecast reliability risks, and identify engineering priorities—using Dynatrace as the trusted operational data source.

Get started today

• Try the Dynatrace Playground — Explore AI observability with sample data
• Explore NVIDIA integrations in the Dynatrace Hub
• Stream NAT telemetry to Dynatrace — NVIDIA Agent Toolkit OpenTeletemetry guide
• Use Dynatrace as an operational data source — Remote MCP Docs

The post Smarter, safer Agentic AI: Dynatrace observability meets NVIDIA AI-Q 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.

AI is stretching the boundaries of traditional log management. More data without context slows insight, increases risk, and stalls AI progress. Teams need to rethink how they capture, process, and use telemetry from ingest to analysis. This action plan outlines how to unify telemetry, optimize pipelines, and turn data into real‑time, trusted intelligence teams can use to scale AI operations with confidence.

AI workloads aren’t just increasing telemetry—they’re exposing the limits of how teams capture, store, and use it. Traditional log management was built for predictable systems and finite telemetry. AI systems break those assumptions. The result: more telemetry, less context, and increasing cost pressures to stay operational. The shift is how to manage logs better—and changing how teams capture, process, and make logs telemetry available across the entire lifecycle.

Here’s how that shift looks in practice:

The State of Log Management 2026 research report—based on a global survey of 450 senior IT leaders—examines how AI is reshaping log economics, instrumentation, and observability strategies, and what shifts technical leaders must make to telemetry capture, storage, and management to support and scale agentic AI projects.

5 actions to kickstart your new log management plan

• Create a single source of truth for AI systems by centralizing all telemetry in a unified, continuously queryable context layer and platform.
• Establish causation across AI systems by automatically unifying logs with metrics, traces, and lifecycle context—not relying on logs alone.
• Control costs without losing visibility by optimizing telemetry before ingest and eliminating indexing, archiving, and rehydration dependencies.
• Standardize and govern telemetry at ingest to ensure data quality, compliance, and real-time usability at AI scale.
• Enable preventive AI operations by turning contextual telemetry into real-time insight and automated remediation.

Why should teams unify telemetry on a single observability platform for AI workloads?

Unifying telemetry reduces manual correlation, preserves context, and keeps logs, metrics, and traces continuously queryable as telemetry scale increases.

AI workloads are exacerbating an existing problem by fragmenting even more telemetry across tools just as systems require more context. Teams now use an average of seven log tools, forcing manual correlation that doesn’t scale.

• Unify all telemetry—logs, metrics, traces, security signals, user behavior, business events—into a single, continuously queryable context layer where telemetry is correlated automatically.
• Enrich telemetry at ingest starting at the edge with shared technical and business context to explain system behavior as dependencies multiply.
• Democratize access using intuitive querying so more teams can validate AI behavior and act faster with confidence.

How do logs and traces work together for reliable and explainable autonomous operations?

Logs don’t explain AI behavior independently. Understanding comes from unifying logs with traces and other telemetry signals optimized throughout the telemetry lifecycle.

Autonomous systems demand deterministic signals that explain what happened, why it happened, and how to respond—something logs alone can’t fully provide.

• Instrument logs to capture AI‑specific details at every inference layer to preserve the exact sequence of events.
• Correlate logs with traces automatically to establish causation and pinpoint root causes.
• Automate remediation using continuously enriched telemetry to enable reliable, explainable autonomous operations at scale.

How can teams optimize log management costs without sacrificing insight?

Teams can manage costs by retaining high‑value telemetry without rigid schemas, indexing overhead, or rehydration delays that limit analysis.

Managing log costs involves data strategy, not just storage. Logs consume nearly half of observability budgets, yet even after reducing volume by filtering, masking, and aggregating, 50% of organizations don’t collect or discard an average of 86% of logs specifically to manage costs, and 74% say indexing and rehydration costs are barriers to value.

• Ingest and retain telemetry without rigid schemas or indexes, eliminating the need to predict questions in advance.
• Store exabytes of data in one queryable layer, avoiding cold archives and rehydration costs and delays.
• Analyze telemetry in full context to reduce waste and maximize business value from AI‑generated data.

What changes to instrumentation and ingest should teams make to support AI workloads?

Teams must optimize telemetry before ingest—standardizing instrumentation and automating parsing and configurations—so data remains high-quality, contextual, and continuously queryable at AI scale.

Fragmented instrumentation and brittle ingest pipelines slow insight and delay AI projects from reaching production. 85% of organizations struggle to ingest logs at AI scale, and 80% say turning telemetry into insight delays AI initiatives.

• Standardize instrumentation across logs, traces, metrics, and other telemetry signals to maintain context and reduce downstream correlation.
• Streamline ingestion in real time by automating parsing, configurations, and enrichment to retain only high‑value, compliant data.
• Sustain telemetry at scale with an always‑queryable data layer that supports real‑time analytics and automation.

Why are preventive operations critical to AI-native environments?

As AI workloads increase telemetry volume and autonomous operations, teams need detailed intelligence about what’s happening in AI output to predictively detect early signals of unexpected results.

Because reactive troubleshooting can’t keep up with autonomous systems, teams need real‑time, contextual telemetry to detect drift and prevent failures early. 84% say customer trust in AI depends on their ability to use log analytics to predict and prevent problems.

• Correlate logs with end‑to‑end traces automatically to create a reliable understanding of AI behavior before failures escalate.
• Analyze AI telemetry in real time and full context to detect early signs of drift or degradation.
• Automate response to reduce risk and scale AI‑driven operations safely.

Upleveling log management to advance trustworthy agentic AI

Expanding AI workloads demand more from log management—an approach built on unified observability, open, optimized ingest at massive scale, and real‑time analytics without rigid schemas, indexing overhead, or rehydration delays. Logs remain the accountability anchor, but trust emerges only when all telemetry signals come together in context.

FAQ: Log management action plan for AI workloads

Why do AI workloads require a different log management approach?

AI workloads are variable and generate significantly more telemetry, which demands explainability, reliability, and cost control capabilities that traditional log architectures weren’t designed to support.

What is the first step teams should take to modernize log management for AI?

Unify logs, metrics, and traces on a single observability platform so telemetry is always available in context and doesn’t require manual correlation.

How can organizations reduce log management costs without losing insight?

By starting observability at the edge and retaining high‑value telemetry without rigid schemas, indexes, or rehydration delays, teams avoid discarding data while controlling cost.

Why aren’t logs alone enough to support autonomous operations?

Logs show what happened and why, but traces show how and what’s affected; together they explain AI behavior and enable reliable, automated remediation.

What enables preventive operations in AI‑native environments?

Real‑time analysis of contextual telemetry that detects early signs of drift or degradation and triggers automated guardrails before failures escalate.

The post Log management for AI workloads: How to bring your logs and telemetry plan into the AI-first century appeared first on Dynatrace news.

At Dynatrace, we believe the future of observability and cloud-native operations is open. Not “open” as a slide-deck buzzword, but open as in showing up every day to write code, review PRs, chair working groups, and build tools the community can use, extend, and make their own.

We’re proud to be an active contributor to the cloud-native ecosystem. We build in the open because we’ve seen firsthand that open collaboration produces better software for our customers, the community, and the industry.

This post looks at some of our most significant open source contributions — why we built them, why we open sourced them, and how they’ve grown into thriving community projects. It’s not exhaustive; for the full set, explore our projects on GitHub.

The OpenTelemetry community, setting the standard for observability

What is the OpenTelemetry ecosystem?

The OpenTelemetry® (OTel) ecosystem provides an open source, vendor-neutral way to generate, collect, process, and export telemetry data, specifically traces, metrics, and logs. Born from the merger of the OpenTracing and OpenCensus projects in 2019, the OTel community is now the second most active Cloud Native Computing Foundation® (CNCF) community after Kubernetes and the de facto standard for instrumenting cloud-native applications.

Before OpenTelemetry standards, every observability vendor had its own proprietary agent, data format, and instrumentation libraries. Switching vendors meant ripping out instrumentation and starting over. The standards change that by providing a single set of APIs, SDKs, and a Collector that work with any backend. You instrument once, and you can send your telemetry data wherever you need it.

How Dynatrace contributes to the OpenTelemetry ecosystem

Dynatrace has been involved in the OpenTelemetry ecosystem since the project’s earliest days, and our engagement goes well beyond code commits. Our engineers hold leadership positions across the project:

• Governance Committee: Daniel Dyla, a Senior Open Source Architect at Dynatrace, serves on the OpenTelemetry Governance Committee, helping shape the project’s strategic direction.
• Technical Committee: Armin Ruech, a Team Lead and Product Owner at Dynatrace, sits on the Technical Committee, guiding the cross-language specification that ensures consistency across all OTel implementations.
• SIG Maintainers and Approvers: Dynatrace engineers serve as maintainers or approvers across multiple Special Interest Groups. Contributors like Mario Jonke, Marc Pichler, Evan Bradley, Giovanni Liva, Joao Grassi, and many more are active across these SIGs.
• Community Management: Adriana Villela, a Principal Developer Advocate at Dynatrace, recently took on the role of OpenTelemetry Community Manager, working to grow the contributor and end-user community and raise the OTel community’s profile within the CNCF and the broader open source world.

Dynatrace also ships its own distribution of the OpenTelemetry Collector, with enterprise-grade support and curated components so teams can confidently run OTel in production. Our acquisition of Bindplane, a telemetry pipeline built on OpenTelemetry standards, extends that commitment.

How the community benefits

The OpenTelemetry community has fundamentally changed how the industry approaches observability. Developers no longer commit to a single vendor’s instrumentation at the code level, SREs can standardize on one set of libraries across polyglot environments. Organizations can evolve their observability strategy, switching or combining backends without re-instrumenting their applications.

Get involved

Check out OpenTelemetry.io and find an interest group that matches your interests. Also check out the first episode of the Observation Deck to learn more about the community and how to get involved.

W3C® Trace Context: Making distributed tracing actually work

What is W3C Trace Context?

W3C Trace Context is a specification that defines a standardized set of HTTP headers for propagating distributed tracing context between services. Before it existed, every tracing tool—both commercial and open source—used its own proprietary headers, which resulted in a high volume of broken traces. We saw the problem firsthand every day across thousands of customer environments: Traces would vanish whenever a request crossed a boundary between two monitoring tools or passed through a cloud provider’s managed service. The root cause was always the same: no agreed-upon header format.

Trace Context solves this by defining a universal traceparent header that all compliant tools and middleware recognize and forward. It’s a deceptively simple idea with a massive practical impact on end-to-end tracing in production.

How Dynatrace contributes

Dynatrace helped lead W3C Trace Context. Alois Reitbauer, now Dynatrace’s Chief Technology Strategist, chaired the W3C Distributed Tracing Working Group; colleagues including Christoph Neumüller and Daniel Khan worked alongside engineers from Google, Microsoft, and New Relic to iterate on the standard, and Daniel Dyla contributed as a co-author alongside his OpenTelemetry work. Dynatrace was a founding sponsor of the working group when it moved into the W3C in 2018, and the first vendor to ship production support for the standard.

How the community benefits

W3C Trace Context has been adopted by the OpenTelemetry project (which uses it as its default propagation format), Microsoft Azure services, Google Cloud Platform™ services, Elastic® services, and many others. Middleware, service meshes, and cloud-managed services now forward traceparent headers automatically, making end-to-end visibility achievable in environments where it was previously impossible. It’s one of those standards that, once adopted, makes you wonder how anything worked without it.

OpenFeature: An open standard for feature flags

What is the OpenFeature standard?

The OpenFeature project, a CNCF Incubating project, defines a vendor-neutral open standard for feature flag management. It provides a unified API and SDK developers can code against regardless of the backend — an in-house solution, a commercial platform, or an open source tool.

Feature flags are a core practice in modern software delivery: They let teams decouple deployments from releases, roll out features to targeted user groups, run A/B experiments, and instantly kill-switch problematic features — all without redeploying code. But the ecosystem has historically been fragmented: Every vendor and homegrown solution has its own API, so migrating between solutions requires rewriting application code.

The OpenFeature project remedies this with a standardized abstraction layer. You write your evaluations once against the OpenFeature API; to switch backends — say, from an in-house solution to a commercial vendor — you swap out the “provider” (a thin adapter), and your application code doesn’t change.

How Dynatrace contributes

Dynatrace initiated and led the creation of the OpenFeature project. In 2022, we assembled an industry consortium of top feature flag management solutions and submitted the standard to the CNCF as a sandbox project. We remain one of the project’s key drivers, contributing to the specification, SDKs, and provider ecosystem.

Dynatrace engineers play central roles in the project’s governance and day-to-day development:

Governance Committee: Michael Beemer, a Product Manager at Dynatrace, serves on the OpenFeature Governance Committee and has been instrumental in driving the project from its earliest days. Alois Reitbauer, Dynatrace’s Chief Technology Strategist and a driving force behind many of our open source initiatives, has recently passed leadership to Jonathan Norris following our acquisition of DevCycle.

Project Maintainer: Todd Baert, a Software Engineer at Dynatrace, works almost entirely as an OpenFeature project maintainer, focusing on SDK development, integration points, extensibility, and the OpenTelemetry hook that bridges feature flags with observability data.

Observability is built in by design: The OpenTelemetry API supports OpenFeature flags, so feature flag evaluations are automatically captured as part of distributed traces. Observability platforms like Dynatrace can show you not just what happened in a request, but which flags were evaluated, what values were returned, and how those flags affected performance and user experience.

In early 2026, Dynatrace acquired the DevCycle® platform, a feature management solution built natively on the OpenFeature standard, deepening our investment in open, standards-based progressive delivery.

How the community benefits

The OpenFeature standard lets developers adopt feature flags without vendor lock-in. Outgrow an in-house solution? Move to a commercial provider without rewriting code. Vendor sunsets their product? Your application code is unaffected; just swap providers. And because feature flag evaluations are captured as part of distributed traces, teams can correlate flag states with performance data, error rates, and user experience metrics — making progressive delivery measurably safer.

Get involved

Visit openfeature.dev to learn about the standard, try a provider, or contribute to an SDK. The community is active on the CNCF Slack.

Keptn toolkit: Cloud-native application lifecycle orchestration

What is Keptn toolkit?

Keptn toolkit is a CNCF Incubating project that provides event-driven orchestration for cloud-native application delivery and operations. It connects observability to operations through a declarative approach to automation for deployment pipelines, quality gates, and auto-remediation workflows.

In practical terms, Keptn toolkit lets you define Service Level Objectives (SLOs) and automatically evaluate them at every stage of your delivery pipeline. Did that new deployment meet its performance targets? Keptn toolkit checks your SLIs (Service Level Indicators) against your SLOs and decides automatically whether to promote the release or roll it back. It’s often described as “SRE in a Box.”

Field teams at Dynatrace kept seeing the same pattern across customer engagements: every organization was writing the same Jenkins scripts, the same ServiceNow® integrations, the same dashboard-checking routines, just with slight variations.

Keptn toolkit is tool-agnostic by design: it integrates with whatever CI/CD, testing, monitoring, and notification tools you already use. You define the “what” — your delivery and operations strategy — and Keptn toolkit orchestrates the “how” using your existing toolchain.

Keptn toolkit’s unique value in the CNCF landscape is its focus on observability-driven operations. SLOs drive its orchestration decisions, bridging the gap between “we deployed it” and “it’s actually working well for users.” For SRE and platform engineering teams, it’s a structured, declarative way to codify operational best practices without being tied to any specific tool.

How Dynatrace contributes

Dynatrace created Keptn toolkit internally in 2019 and donated it to the CNCF as a sandbox project in 2020. It was promoted to CNCF Incubating status in 2022 after significant community growth.

Key Dynatrace contributors include Alois Reitbauer (Keptn toolkit creator and Dynatrace CTS), Andreas Grabner (co-founder and DevOps Activist at Dynatrace), and Johannes Bräuer (co-founder). The project was born directly out of our work helping customers implement autonomous cloud operations.

Get involved

Head to keptn.sh to learn about the project, try the quickstart, or build an integration for your favorite tool.

How the community benefits

Since joining the CNCF, Keptn has grown tenfold in adoption, with more than 100 production instances and more than 40 companies using it in production including Citrix, T-Systems, and others. The project has attracted dozens of community-built integrations and inspired the CDEvents standard in the Continuous Delivery Foundation.

OffOn.dev: Building the Open Source Community of tomorrow

Every project in this post depends on something that doesn’t show up in a GitHub® commit graph: the people who sustain them — maintainers, contributors, mentors, and the next generation of developers who haven’t written their first PR yet. They’re often overlooked. Most platforms, foundations, and content formats are built with enterprises, legal teams, or marketing goals in mind, not for individual maintainers or attracting new contributors. Yet these are the people who keep open source alive.

OffOn.dev was created to address that gap. Too many community spaces are built to react to problems — they grow, but stay focused on troubleshooting rather than adoption, innovation, and exploration. The Open Ecosystem takes a different approach: a practical, vendor-agnostic space for builders working with open standards and cloud-native tools, focused on reproducible, hands-on knowledge — tutorials with real code and configs, Q&A with accepted solutions, technical challenges, and a Community Voices space for members’ projects and demos.

This is not a sales channel. Companies like Dynatrace may sponsor with resources or funding, but sponsors don’t influence the content or the mission. The purpose is to sustain open source momentum and help create the maintainers of tomorrow’s digital landscape — a need made more urgent by digital sovereignty and emerging regulations like the CRA and EU AI Acts.

Whether you’re an SRE wiring up an OpenTelemetry pipeline, a developer experimenting with OpenFeature flags, a student writing your first contribution, or a maintainer mentoring the next generation — the Open Ecosystem is built for you. Introduce yourself, jump into a challenge, share what you know. Head to OffOn.dev and come build with us.

The post Building in the open: How Dynatrace invests in open source to move the industry forward appeared first on Dynatrace news.

Here’s the uncomfortable truth: organizations are spending billions on cloud migrations, yet many fail to deliver the promised ROI. Why? Because moving workloads to the cloud without addressing operational visibility, runaway costs, and fragmented tooling multiplies the problem.

In this article, we’ll cover:

• Why most cloud modernization efforts stall (and how to avoid those pitfalls)
• What true cloud modernization looks like when built on the right foundation
• A phased approach to modernization that delivers measurable business outcomes
• How to choose the right path forward for your unique applications

Understanding cloud modernization

Cloud modernization refers to the process of updating existing legacy applications and infrastructure to leverage cloud-native technologies, architectures, and methodologies. This transformation goes beyond simple lift and shift migrations to embrace modern approaches like containerization, microservices, and DevOps practices.

The impetus for modernization often comes from challenges with legacy systems:

• Monolithic architectures that are difficult to update and scale
• High operational costs and maintenance burdens
• Inflexibility in meeting changing business requirements
• Limited ability to integrate with modern services and tools
• Slow deployment cycles that hamper innovation

But here’s what organizations often don’t anticipate: without unified observability and intelligent automation, cloud modernization often moves these problems to a more complex, distributed environment where they become even harder to diagnose and fix.

When done right, modernization solves these issues and unlocks entirely new capabilities. Teams move from reactive to predictive, applications become self-healing, and innovation accelerates.

Why cloud modernization matters

According to IDC, 83% of enterprises are working to rationalize and optimize their technology infrastructure, yet only 35% consider their approach to modernization effective. This gap highlights the need for thoughtful, strategic approaches to cloud modernization.

The benefits of a well-executed cloud modernization strategy include:

• Enhanced application insights: Observability solutions provide deeper visibility into application performance, dependencies, and user activity, enabling proactive optimization.
• Improved performance: Cloud-native architectures and services can dramatically improve application responsiveness and reliability.
• Cost optimization: Modernized applications typically reduce operational costs through more efficient resource utilization and automated management.
• Increased operational efficiency: DevOps practices and automation reduce manual intervention, allowing IT teams to focus on innovation rather than maintenance.
• Business agility: Perhaps most importantly, modernized applications can adapt quickly to changing market conditions and business requirements.

Essential elements of a cloud modernization strategy

Assessment and planning

Before embarking on a modernization journey, organizations should conduct a thorough assessment of their existing application portfolio. This includes cataloging all applications and their interdependencies, evaluating each application’s business value and technical debt, understanding current performance metrics and cost structures, and identifying modernization priorities based on business impact.

For example, a financial services company might prioritize modernizing its customer-facing applications to improve user experience while planning a phased approach for back-office systems.

Choosing the right modernization approach

Not all applications require the same modernization approach. The key is matching your strategy to business impact and technical reality.

Ask three key questions to guide your decision:

1. What’s the business value? Customer-facing applications typically warrant more investment than back-office systems.
2. What’s the technical debt? Minor issues suggest lighter modernization while fundamental problems require deeper transformation.
3. What’s the integration complexity? Standalone applications are easier to modernize than heavily interdependent systems.

Based on your answers, you’ll typically follow one of three paths:

The specific tactics within each path – whether you’re rehosting, replatforming, refactoring, rearchitecting, rebuilding, or replacing – depend on your application’s complexity, value, and business requirements.

Accelerating software delivery

Cloud modernization should enhance an organization’s ability to deliver software quickly and reliably. This involves implementing CI/CD pipelines for automated testing and deployment, using infrastructure as code for consistent environment provisioning, leveraging automated quality and security gates, and adopting platform engineering approaches to provide self-service capabilities for developers.

Increasing team productivity

The shift-left/shift-right approach to cloud modernization focuses on sharing responsibility between development and operations teams while maintaining centralized governance. This hybrid model provides developers with self-service capabilities, centralizes expert knowledge within platform engineering teams, maintains consistent tooling and knowledge management, and balances autonomy with governance.

Getting started with cloud modernization

To begin your cloud modernization journey, successful organizations often break the process into three clear phases:

Phase 1: Establish your foundation (months 1 to 3)

1. Define measurable outcomes such as reduced time-to-market, improved user satisfaction, or decreased operational costs.
2. Benchmark existing applications, processes, and services to create a baseline for measuring improvement.
3. Choose a pilot application that provides real business value but isn’t mission-critical, allowing your team to learn and refine approaches before tackling more complex systems.
4. Implement comprehensive monitoring and observability solutions early in your modernization process to gain insights that inform future decisions.
5. Success milestone: Complete visibility into your environment, pilot selected, and baseline established

Phase 2: Modernize and automate (months 4 to 9)

• Identify repetitive tasks and implement automation, focusing on areas that will yield the highest return on investment. Build CI/CD pipelines and automated quality gates.
• Enable self-service for development teams while maintaining centralized governance through platform engineering.
• Success milestone: Pilot in production with measurable improvements; automation reducing manual effort by 50% or more

Phase 3: Scale and optimize (months 10 and beyond)

• Expand to additional applications using lessons learned from your pilot.
• Leverage AI-powered insights for continuous optimization of costs, performance, and reliability.
• Achieve operational maturity where routine operations are automated and teams focus on innovation.
• Success milestone: Measurable ROI across applications; 40% increase in team productivity; 30% reduction in operational costs

Accelerate cloud modernization with Dynatrace

Modernizing your cloud environment helps to unlock agility, resilience, and long-term business value.

With Dynatrace, you get unified observability, precise automation, and advanced AI capabilities that help you modernize with confidence. From predictive issue detection to automatic root-cause analysis and intelligent remediation, Dynatrace enables you to scale operations, accelerate innovation, and reduce complexity—all while maintaining control and compliance.

What makes Dynatrace different:

• Unified data model: One source of truth across your entire stack eliminates tool sprawl and conflicting data. Every team works from the same real-time information, speeding decisions and collaboration.
• Causal automation: Root cause analysis happens in real-time. Dynatrace Intelligence doesn’t just detect anomalies—it automatically determines why they happened and triggers intelligent remediation capabilities through agentic AI. Teams shift from firefighting to innovating.
• Continuous topology awareness: As your environment changes constantly, Dynatrace automatically discovers, maps, and understands every component and dependency in real time. No manual configuration. No blind spots. You always know what’s running and how it’s connected.

Cloud modernization: Frequently asked questions

What is cloud modernization?

Cloud modernization is the process of evolving legacy applications and infrastructure to take advantage of cloud-native architectures, services, and operating models. It goes beyond migration to improve agility, scalability, and efficiency.

How is cloud modernization different from cloud migration?

Cloud migration focuses on moving workloads to the cloud. Cloud modernization focuses on improving how applications are built, run, and operated once they’re there—often through automation, observability, and architectural change.

What are the main approaches to cloud modernization?

Organizations typically modernize by optimizing in place (rehosting or replatforming), transforming the architecture (refactoring or rearchitecting), or replacing applications entirely with rebuilt or SaaS solutions.

How does AI accelerate cloud modernization?

AI turns observability data into actionable answers, helping teams understand dependencies, prioritize actions, and automate operations with confidence. Dynatrace AI capabilities, powered by Dynatrace Intelligence, automatically detect anomalies, identify root causes, and prioritize remediation, so teams can modernize faster without relying on manual investigation.

How do I choose the right modernization approach for my applications?

The right approach depends on business value, technical debt, and integration complexity. High-value, customer-facing applications often justify deeper modernization, while lower-risk systems may benefit from lighter optimization.

Why is observability important in cloud modernization?

Observability provides real-time insight into application performance, dependencies, and costs. It helps teams make informed modernization decisions, detect issues early, and continuously optimize as environments change.

What’s the best way to get started with cloud modernization?

Start by assessing your application landscape, defining measurable business goals, and selecting a pilot application. Establish visibility early, then modernize in phases to prove value before scaling.

The post Getting started with cloud modernization appeared first on Dynatrace news.

New Dynatrace research reveals how logs are becoming the accountability anchor for AI systems and why cost-driven trade-offs (sampling, cold storage, and discarding data) increase operational risk. In fact, with legacy log management tools now consuming 45% of observability budgets, 67% say the costs of these tools outweigh their value, indicating a need to modernize quickly (source: Dynatrace State of Log Management 2026 research).

3 takeaways for engineering and business leaders

• Scale is accelerating. Log and telemetry volume increased 93% on average with 1 in 5 organizations seeing growth above 150%.
• Costs are breaking traditional models. Existing log management tools consume 45% of observability budgets with respondents estimating an average annual spend near $2.5M.
• Context with traces is the path to AI trust. 73% say logs reveal only part of what’s happening with AI workloads, and 70% rank traces as a top source for evaluating AI performance and behavior. But 65% rely heavily on logs because they don’t have easy visibility into other telemetry signals.

Logs capture the precise details of events from cloud, AI, and infrastructure. As AI workloads and agentic systems (AI systems that act autonomously) make up an increasing proportion of technology stacks, logs serve as a crucial shared language for humans and agents to reason and troubleshoot system state and autonomously build and optimize infrastructure and applications.

Accountability depends on placing high-fidelity log telemetry in context: connecting it with traces, metrics, security events, user behavior, and business signals to understand AI behavior and guide remediation at scale.

How is AI breaking the economics of traditional log management?

AI workloads break the financials of traditional logging approaches by driving massive telemetry growth that forces many teams to not collect or discard data to avoid runaway costs.

Over the past year, AI workloads triggered a 93% average increase in log and telemetry volume, with one in five experiencing expansions above 150%. At the same time, teams rely on an average of seven different log and telemetry tools, forcing manual correlation that doesn’t scale.

The financial impact is just as stark. According to the report, existing log management tools now consume 45% of observability budgets, with average annual spend among survey respondents nearing an estimated $2.5M per organization. To contain costs, many teams limit ingestion, sample telemetry, or push logs into cold storage, losing crucial context and increasing security, compliance, and operational risk. In fact, 67% say the cost of existing log management tools now outweighs their value. And even after filtering, masking, and aggregating to reduce volume, the limitations of traditional logging tools force teams into imprecise compromises, resulting in half of organizations not collecting or discarding 86% of logs specifically to manage costs.

Traditional vs. AI-native log management

What must change in instrumentation and ingestion for autonomous systems?

To build trust in AI workloads and advance the business value of autonomous decision-making, optimizing and streamlining telemetry must start before ingest and be open and automated at a massive scale.

Traditional logging architectures weren’t built for AI‑driven scale or autonomy.

• As AI workloads proliferate, 79% of technical leaders worry their current ingest and storage approaches won’t meet future needs.
• 80% say they must update instrumentation to support new AI‑specific metrics.

The operational toll is significant. Teams spend 58% of their analysis time stitching together logs, metrics, and traces before extracting insight, which slows decisions and delays AI projects from moving into production.

To break this bottleneck, 81% of organizations say log ingestion and processing must be open and automated at massive scale, enabling real‑time analysis without rigid schemas, indexing overhead, or rehydration delays.

Why do logs need an observability ecosystem to build AI trust?

While logs are a crucial component of AI observability, they need context to tell the whole story.

• 73% of organizations say logs reveal only part of what’s happening in AI workloads
• Teams spend 58% of analysis time stitching telemetry together
• 72% say standalone log management tools are obsolete—AI workloads demand a platform approach that combines all types of telemetry in one place to accelerate time to answers

As a result, most organizations rely on logs alongside other telemetry signals—especially traces, which 70% rank as the top source for evaluating AI performance and behavior.

Trust in AI develops when analysis is based on high-fidelity telemetry in context:

• Logs provide the fact basis
• Traces expose flow and causality
• Metrics quantify performance
• Security events surface risk
• Business signals connect system behavior to outcomes

Unified observability turns this telemetry into a coherent narrative—enabling teams to validate AI behavior, assess impact radius, guide remediation, and move from reactive troubleshooting to preventive operations.

What does AI-native log management look like with unified observability?

Unified observability transforms log management for the AI era by optimizing telemetry instrumentation and ingest, unifying telemetry with context, and eliminating crippling cost-cutting measures.

With exponential increase in telemetry volumes due to AI workloads, the path forward can’t just be shrinking log ingest to manage costs. AI innovation depends on leaning into telemetry volume with the right strategy and capabilities. The report points to key actions leaders can take to adopt AI-native log management practices.

• Centralize all telemetry (logs, traces, metrics, events) in a unified, continuously queryable context layer to eliminate silos and scale AI visibility.
• Automatically correlate logs with traces and lifecycle context to establish causation, understand AI behavior end to end, and enable reliable autonomous operations.
• Control log costs before ingest while retaining full-fidelity telemetry in exabyte-capacity storage with no rigid schemas, indexes, cold archives, or rehydration.
• Standardize instrumentation and optimize ingestion to capture high-value, governed telemetry that tracks agent actions, reasoning traces, and lifecycle events.
• Enable preventive operations by detecting early signals and automating remediation to reduce risk, strengthen reliability, and safely scale AI projects.

The goal is reliable operations and AI accountability at scale. Together, logs, traces, metrics, and events in context can enable preventive operations, reliable autonomy, and confident decision‑making as AI systems move from pilots into production. Organizations that build this unified foundation will be best positioned to scale AI without sacrificing trust.

FAQ: State of Log management 2026

Why is log management getting harder in the AI era?

Because AI workloads are driving rapid telemetry growth—organizations saw a 93% average increase in log and telemetry volume in the past year.

Why do log management costs feel out of control?

Existing log management tools consume 45% of observability budgets, and average annual spend is nearing $2.5M per organization.

Do teams still see value in log management at today’s price?

Not consistently. 67% of respondents say costs of existing log management tools now outweigh their value.

Why do teams discard so many logs?

Cost pressure. Using existing tools, 50% of organizations don’t collect or discard 86% of their logs on average, often using sampling or limiting ingestion specifically to reduce spend.

What’s the biggest operational bottleneck with today’s tooling?

Manual correlation. Teams spend 58% of analysis time stitching together logs, metrics, and traces before they can extract insight.

Why aren’t standalone log tools enough for AI workloads?

Because logs alone rarely tell the whole story. 72% say standalone log management tools are obsolete, and 73% say logs reveal only part of what’s happening in AI workloads.

What telemetry signal do teams rely on most to evaluate AI behavior?

Traces—70% rank them as the top source for evaluating AI performance and behavior beyond logs alone.

The post How AI workloads are changing what logs must deliver, forcing a new strategy 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.

If you’re running modern applications on AWS, you already have access to more data than ever: metrics, logs, traces, and events. The real advantage comes from turning that data into actionable insights that drive continuous improvement.

Today’s challenge occurs when something breaks; teams still spend too much time connecting the dots. Pulling data from different tools, correlating signals, and trying to figure out what changed. That gap between insight and action is where time is lost, and customer impact grows.

Dynatrace and AWS are working together to close that gap.

With the introduction of AWS DevOps Agent and deeper integrations across Dynatrace and AWS services like Kiro, the experience moves beyond monitoring into AI-powered observability. It becomes a connected system that detects issues, investigates them, and feeds directly into how teams fix and improve software.

How we got here

At AWS re:Invent, AWS introduced DevOps Agent, a new type of AI agent built to investigate and resolve issues across cloud environments. Instead of relying on manual troubleshooting, the agent works continuously across services to understand what changed and why. Dynatrace has been part of that effort since the start. After all, if these agents are going to be effective, they need real production context. That’s the Dynatrace specialty.

That collaboration evolved quickly. Sharing observability data is now a two-way integration. Dynatrace detects and understands issues. AWS DevOps Agent investigates them. The results flow directly back into Dynatrace for a complete view of what happened and what to do next.

The next iteration of the Clouds SRE app

As customers started using the initial implementation, one thing became clear. The foundation was there, but there was an opportunity to make the experience more streamlined, more transparent, and more aligned with how teams actually operate at scale.

With the introduction of the Clouds SRE app, that experience has evolved in a meaningful way.

Instead of requiring users to manually configure multiple workflows, onboarding is now guided. Teams can get started faster without needing to define everything upfront. What used to take several workflows is now simplified into a more focused, purpose-built experience across AWS.

Visibility is another big step forward. Previously, there was limited insight into what agents were doing during an investigation. Now, teams have transparent tracking into agent activity, including approvals, notifications, and the ability to automatically re-run stalled investigations. That shift alone gives teams more confidence in how work is executed.

Routing and management have also become much more intuitive. Rather than managing workflows behind the scenes, teams can now use interaction profiles directly in the UI to control how agents are routed, filtered, and managed. It brings that control closer to where teams already operate.

And importantly, the scope of what agents can do has expanded. What was once limited to investigations now includes mitigation actions as well, allowing teams to move from insight to action without changing context.

Finally, there’s a stronger focus on outcomes. With built-in executive summaries and efficiency metrics, teams can now understand the impact of these workflows in real terms, not just activity.

Taken together, this is a shift from a workflow-centric model to an experience that is guided, observable, and outcome-driven.

From investigation to resolution

Because the integration is two-way, everything stays connected. Findings from AWS DevOps Agent flow directly back into Dynatrace. Root cause, impacted services, and recommended fixes are all visible in a single place.

Teams no longer need to switch between tools or reconstruct the story themselves. The full path from detection to resolution is already laid out.

For teams running distributed systems on AWS, this changes daily operations. Instead of spending time figuring out where to look, teams can focus on fixing the issue and preventing it from happening again.

Bringing that context to developers with Kiro

This is where the story extends beyond operations. Kiro, AWS’s agentic development environment, brings that same production context directly into the developer workflow.

Instead of waiting for a handoff from operations, developers can access real production insights while they are building and fixing code. They can see exactly what failed, understand the root cause, and apply fixes with the same context that was used during investigation.

This removes one of the biggest sources of friction in software delivery. Developers are no longer dependent on separate teams to translate production issues. They are working from the same data in real time.

Now we have a closed loop: Dynatrace detects the issue. AWS DevOps Agent investigates it. Kiro brings that insight directly into the codebase where it can be resolved and improved.

That closes the gap between production and development in a way that was not possible before.

What this means for you

If you are running applications on AWS today, these developments can result in:

• Less time spent correlating data across tools
• Faster and more consistent incident resolution
• Fewer handoffs between operations and development
• Direct access to production context during development

Most importantly, it shortens the feedback loop. Issues are not just detected faster; they can be understood and resolved faster, and improvements can be applied to the code without delay.

Getting started

If you are already using Dynatrace on AWS, the next step is to connect these workflows.

Start by enabling the AWS DevOps Agent integration with Dynatrace to bring automated investigation into your environment. From there, extend that same production context into developer workflows with Kiro so your teams can act on insights directly.

This is the fastest way to move from insight to action and start seeing the value in day-to-day operations.

The post Moving from insight to action: How Dynatrace and AWS are reshaping cloud operations 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.

Every developer knows the feeling: You’re in your IDE when something breaks. Error rates spike, alerts fire, and suddenly you’re out of the flow. Michael Kobush, Performance Engineer III at the National Association of Insurance Commissioners (NAIC®), wanted to eliminate the gap between development and runtime. Instead of switching tools or waiting on SRE support, NAIC set out to bring production insight directly into the developer workflow.

Let’s take a look at how NAIC embedded real-time observability directly into their development workflow and reduced investigation time to a few minutes.

The problem: Context switching kills developer productivity

Developers lose time the moment they leave their IDE, jumping between views of logs, metrics, and traces simply to understand what has changed.

For NAIC, this friction was slowing down their teams. Developers didn’t have access to production context, creating a dependency on SRE teams whenever investigations were needed. An analysis that should have taken minutes routinely took 45 minutes to an hour. Root-cause identification required manual correlation across multiple systems, a process that was neither scalable nor sustainable.

At Dynatrace Perform 2026, Kobush demonstrated how his team uses Kiro and Dynatrace at NAIC: Real-time observability in your IDE: How NAIC uses Kiro powers to drive developer productivity

The solution: Kiro powers and intelligent observability

Kiro is AWS’s agentic AI-powered IDE that takes a spec-driven approach to software development by turning natural language prompts into structured requirements, architecture designs, and implementation tasks to carry code from prototype to production.

NAIC installed the Dynatrace power for Kiro, one of Kiro’s installable powers that
dynamically connect domain-specific tools and context to the agent. Once connected, Kiro gives developers and AI agents access to Dynatrace data and insights, helping them pinpoint root causes and receive remediation recommendations directly in their workflow.

No switching between tools. No waiting on another team.

The aha moment: Root-cause analysis in minutes, not hours

The first prompt NAIC ran after connecting Kiro to Dynatrace set the tone for everything that followed. Kobush typed a single line into Kiro: “Tell me about problem P-18576.”

Within 30 seconds, Kiro returned a full problem summary with details and recommendations, pulling everything from Dynatrace automatically. Then, he pushed further: “Give me a really deep dive root-cause analysis of what happened.”

In under two minutes, Kiro returned a full root-cause analysis correlating telemetry, infrastructure signals, historical incidents, and the current problem from Dynatrace into a structured response that included:

• An executive summary
• Detailed problem context
• Infrastructure analysis
• Technical root-cause analysis
• Remediation strategies
• Conclusions and next steps

A preliminary assessment that would have previously taken 45 minutes to an hour was now done in minutes. More importantly, it wasn’t just faster; it gave the team a clear, connected view of how services, infrastructure, and dependencies contributed to the issue.

Beyond root cause: Automation across the entire workflow

What makes this more than just a faster diagnostic tool is how NAIC extended Kiro’s capabilities to automate the full incident response workflow.

Using Kiro’s steering files feature, NAIC configured Kiro to automatically generate a structured Markdown file whenever a root-cause analysis was completed. That file includes:

• Relevant DQL queries used during the investigation
• Direct links to the Dynatrace dashboards and data sources that surfaced the issue
• A clear summary of findings

With a Targetprocess MCP also connected, Kiro can take that analysis and populate a ticket directly, automatically loading all relevant context and sending it to the development team. For NAIC, this means the handoff from investigation to remediation is essentially hands-off. This level of automation doesn’t just save time; it creates consistent, repeatable workflows with built-in guardrails. Every incident gets the same structured, data-rich documentation, regardless of who’s investigating it or when.

This isn’t just about faster incident response. It changes how teams build and release software—giving developers immediate feedback on how their changes behave in real environments.

Proactive alerting: Catching problems before they crash

Root-cause analysis after the fact is valuable. With observability embedded directly into the workflow, teams can detect issues earlier in development and respond faster in production, closing the gap between building and operating software.

After noticing that a specific process had crashed, Kobush asked Kiro to set up an alerting profile that would trigger both before the crash, based on stress signals visible in the logs, and at the point of the crash. Kiro analyzed historical log data, identified pre-crash indicators, and built the alert profile automatically.

The result: NAIC’s team now receives early warning signals before a process fails, giving engineers time to intervene rather than react.

This shift from reactive to proactive operations is central to what the Dynatrace and AWS partnership enables. When observability data is embedded in the developer workflow rather than siloed in a separate platform, the entire engineering organization is better equipped to prevent incidents, not just resolve them.

Debugging a sneaky production bug

Perhaps the most telling story from NAIC’s experience with Kiro occurred during a routine error-rate investigation.

An application error rate had increased unexpectedly. Kobush asked Kiro to investigate. Two minutes later, Kiro identified the culprit: A developer had left debug code in the development environment, and it had made its way into production. Every time a user triggered that code path, it threw errors.

When Kobush sent the Markdown report to the developer, the response was immediate: “How did you find that? I’ve been looking for that.”

Kiro leveraged correlated logs, traces, systems context, and historical behavior from Dynatrace to pinpoint exactly where the issue originated.

Start embedding observability into your development workflow

NAIC’s experience highlights a broader shift: When developers, AI assistants, and systems all operate from the same runtime context, debugging becomes faster, releases become safer, and teams spend less time chasing issues and more time building.

The broader message from Kobush is simple: “I’m not a developer. I have a degree in biology and a minor in chemistry… But this, to me, is a game changer in the observability space. I can do things in seconds that would take me hours.”

The productivity gap between observability data and developer action is a solvable problem.

For DevOps engineers, SREs, and platform teams looking to accelerate incident resolution, reduce context switching, and move from reactive troubleshooting to proactive operations, the Dynatrace and Kiro integration offers a practical, immediately actionable path forward.

For developers, this means fewer interruptions, faster answers, and the ability to stay in flow, even when issues arise.

The post From reactive to proactive: How NAIC embedded AI‑powered observability directly into the IDE 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.

As more agentic AI projects come online, the observability market is abuzz with familiar promises: tool consolidation, AI-powered insights, and faster remediation through smarter tools. On the surface, this sounds like progress. But beneath the excitement, many discussions are framed around the wrong question.

The real issue isn’t about how to adopt autonomous operations; it’s about ensuring AI agents are operating reliably and resolving problems without introducing new ones. When evaluating new observability solutions, the question should be:

Can this observability solution accurately analyze complex, dynamic telemetry in context so AI agents can act autonomously with trust, precision, and reliability?

As systems become increasingly agent driven, observability is crossing a structural boundary. Approaches designed for environments where only humans decide and act must adapt to a world where agents increasingly operate autonomously with human oversight, while keeping organizations informed.

Rethinking observability for the agentic age

Observability platforms were initially intended to support engineers in delivering reliable applications, services, and infrastructure to users, and alert them in the event of a problem. Dashboards, alerts, and correlation helped teams investigate incidents, piece together what happened, diagnose issues, decide on next steps, and resolve the problem. This model worked when changes were pushed manually.

The assumption was that more data, better correlation, and cleaner interfaces will lead to increased visibility and improved operational decision making.

Agentic AI systems break that assumption.

With faster release cycles and AI-generated code, manual investigations can no longer keep pace. Moreover, observability platforms must now provide actionable insights to both humans and AI agents.

As agents begin operating as autonomous participants in software environments by triggering mitigations, scaling infrastructure, and optimizing behavior in real time, observability can no longer function solely as a human interface. It must also provide AI systems with a reliable, contextual fact basis that agents can act on programmatically. Machines can’t rely on dashboards and alerts. They require a deterministic foundation of unified, real-time data that delivers accurate, context-rich answers at exabyte scale.

Agentic systems break the mold of “good enough”

Many observability platforms layer probabilistic AI on top of siloed data. They use LLMs to correlate signals and rank likely causes—but they can’t always determine correctness.

“Probabilistic” means that the same input will generate a different output based on a probability distribution of predefined outputs, delivering a different answer when the same problem occurs. This approach is also prone to hallucinations, requiring additional human validation, which can increase operational overhead and token costs, delay resolution of business-critical issues, and divert resources from strategic initiatives.

Enterprise-grade observability must now answer: Is this insight reliable enough for autonomous action?

AI built on siloed data is inherently unreliable. Autonomous systems depend on deterministic, contextual, and trustworthy data to act reliably.

“Deterministic” means that the same input always results in the same output by using factual data to trace the exact causal changes that created the issue. When agentic AI systems act on business-critical applications, the cost of being “mostly right” becomes operationally unacceptable.

This is where a subtle but critical divide appears in the market. Aggregating signals and correlating anomalies can surface patterns. Patterns alone are not a solid basis for decisions, and without deterministic understanding, AI systems inherit that uncertainty and can propagate it downstream.

To drive reliable enterprise autonomous operations, AI agents require a unified, AI-powered observability platform that can analyze exabytes of data in real time and across models to pinpoint root cause, delivering actionable answers in context of what’s affected and its business impact.

From correlated guesses to deterministic answers

This shift in the demands of observability hinges on a clear distinction:

• Probabilistic AI correlates signals that happened around the same time and therefore appear related, pulling information from fragmented data stores to propose a likely root cause.
• Deterministic AI uses causal analysis to pinpoint what happened and why, recommend remediation actions, and identify business impact.

Probabilistic AI is intended to narrow the search space and direct engineers toward potential resolution, but it still requires interpretation.

Deterministic AI establishes sequence, dependency, and impact, enabling systems to decide safely without waiting for humans to connect the dots.

Auto‑remediation, auto-prevention, and auto-optimization all depend on this leap. A platform that unifies telemetry only at the UI layer may deliver data and potential root cause, but it can’t compensate for fragmented understanding and missing context underneath. When context is pieced together after the fact, confidence is never guaranteed.

You can’t automate what you don’t precisely understand.

Context driven observability as the control plane for AI

In an autonomous enterprise, observability doesn’t sit beside execution; it’s embedded within it. This integration requires that teams adopt a new mindset toward observability architecture.

Because more AI workloads are happening at the source, telemetry must be optimized and streamlined before ingest, not after the fact, from the edge to the back end. Data access must be unified, context-aware, and always-hydrated on a massive scale. Answers must be explicit, not implicit, and they must be informed by automatic, real-time dependency mapping.

Likewise, intelligence must combine deterministic and agentic AI—not as add‑ons, but as a single reasoning system from ingest to execution.

In this model:

• AI agents can become the primary consumers of observability data.
• Humans can shift toward strategy, architecture, oversight, and exception handling.
• Observability evolves from a reactive lens into a control plane for autonomous operations.

Observability purpose-built for autonomous operations ensures successful agentic AI initiatives

This moment represents an architectural transition, not just an incremental upgrade cycle. Correlation-dependent observability that uses probabilistic AI can be extended, augmented, and rebranded, but it will always carry the limitations of approximation and human validation.

The next era belongs to an observability platform that’s built for machine understanding from the start: a unified, context driven architecture that delivers deterministic answers at machine speed, precision, and scale.

The post Beyond correlation to autonomous action: Why “good enough” observability fails in the age of agentic AI 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.

Every organization runs on data. But for most leaders, the challenge is clarity. Traditional dashboards and reports often arrive too late, and system-level metrics don’t explain the business consequences of technical events.

When a payment API slows by 200 milliseconds, what does that mean for daily revenue? When user sessions drop, is it a performance issue or a recent pricing change? These are the questions business observability is designed to answer.

Business observability connects technical telemetry to business outcomes, creating a shared understanding of how digital performance drives, or hinders, organizational results. It’s less about adding more data, and more about connecting the right data in real time to the decisions that matter.

Importantly, business observability is broader than observing individual business processes. While end‑to‑end workflows like “order to fulfillment” or “claim to payout” are one expression of business observability, the discipline also encompasses digital experience, customer behavior, revenue impact, operational efficiency, and risk. Business observability focuses on understanding how technology performance influences business outcomes across the organization and not just how a single process executes.

Moving beyond traditional monitoring

Traditional monitoring focuses on uptime, latency, and error rates. These are essential for engineers but often disconnected from business context. Business observability closes that gap by linking system health directly to business performance.

That connection – the ability to translate technical telemetry into business insight – is what distinguishes business observability from conventional monitoring.

What makes business observability different

Business observability builds on traditional monitoring by expanding its scope from system health to business outcomes. It introduces three essential capabilities that operate across customer experience, revenue‑generating transactions, and end‑to‑end processes:

• Business context integration: IT metrics are linked with business KPIs, translating system behavior into measurable impact.
• End-to-end business process visibility: Processes like “loan approval to disbursement,” “claim to payout,” or “application to onboarding” are monitored across applications, infrastructure, and external systems.
• Real-time decision support: Business observability surfaces business implications in real time, allowing teams to respond to issues before they escalate.

Together, these principles give organizations a live understanding of how every digital interaction affects outcomes, from conversions and revenue to efficiency and satisfaction.

Where business observability gets its data

Business observability relies on unifying multiple data streams into a single, contextual view of performance:

• Business events: Structured, contextualized data that represents key business outcomes, such as completed checkouts, submitted claims, bookings, or failed transactions.
• Logs: Time-stamped records of system activity that show what happened and when, often containing critical technical and business data.
• Real user monitoring (RUM): Continuous insight into how users actually experience applications and digital services across devices, channels, and geographies.
• External business tools: Data from tools such as ERP, CRM, billing, and payment platforms that provide commercial, operational, and customer context.
• Instrumentation and agents: Technologies that collect telemetry and business-relevant data from applications and services, ranging from manual instrumentation to automated approaches that observe activity as it flows through systems with minimal configuration effort.
• OpenTelemetry: A standardized instrumentation framework that enables consistent collection of metrics, logs, and traces across hybrid and cloud-native environments.

When correlated, these data sources bridge the gap between technical operations and business results, providing a comprehensive view of how technology supports, or disrupts, performance.

How organizations put business observability to work

Modern organizations apply business observability in three key ways. Organizations may pursue these use cases through a variety of approaches, ranging from manually instrumented metrics and custom reporting to more automated, integrated platforms that reduce effort and time to insight.

1. Drive real-time decisions with IT context: When issues arise, teams and business leaders can see the business impact immediately. A sudden dip in conversions, for example, can be traced to a misconfigured API or third-party service outage, enabling immediate, targeted response.
2. Track and optimize business processes: Complex workflows—like “order to fulfillment” or “quote to claim”—are mapped from end to end. Teams can pinpoint where time, cost, or customer satisfaction are being lost and address bottlenecks before they affect outcomes.
3. Accelerate sustainability and reduce costs: By correlating business events with resource usage, organizations can identify inefficiencies in automation, cloud consumption, or scheduling that inflate cost and carbon impact.

Business observability, in action

Each of these examples shows how business observability does more than surface anomalies. It provides the context to act on them. By connecting business events, telemetry, and user experience data, organizations move from simply detecting issues to understanding their impact, cause, and resolution path in real time.

In practice, achieving this level of insight often depends on how business and technical data are captured and correlated. While some organizations rely on custom instrumentation, manual analysis, or post‑incident reporting, others use more automated approaches that make it possible to detect impact, trace root cause, and act in real time.

Financial services

A large financial institution monitored loan application volume as a business event rather than relying solely on system health metrics. When completed applications began declining, traditional monitoring showed no infrastructure failures. Business observability revealed that timeouts from a third-party credit scoring service were affecting only new applicants following a recent integration change. By correlating business events with external service performance, the bank isolated the issue quickly and rolled back the configuration—preventing lost loan volume and downstream compliance exposure.

Payments

A global payment services provider processes billions of transactions annually and needs to understand not just whether systems are available, but how performance impacts transaction success and revenue. By connecting transaction latency and failure rates directly to payment outcomes, the organization can quantify the financial impact of technical issues in real time. This shared visibility allows both internal teams and customers to see how payment flows are performing and proactively optimize transaction speed and reliability.

Travel and hospitality

A large travel platform aggregates booking data across partners, regions, and channels. Business observability enables teams to track quotes, bookings, and completed reservations as business events, segmented by partner and geography. When booking volume dips, teams can immediately determine whether the cause is a partner integration issue, a regional performance problem, or a downstream service slowdown—allowing rapid response to protect revenue across the ecosystem.

Retail and consumer services

A national restaurant chain observed high abandonment rates during online reservation flows. Rather than treating this as a generic user experience issue, business observability correlated real user behavior with backend availability and booking outcomes. This insight enabled automated recovery workflows that re-engaged customers who abandoned reservations due to technical or availability issues—recovering lost bookings without manual intervention.

Aviation and transportation

An international airline struggled with fragmented visibility across booking, pricing, and fulfillment systems. By modeling bookings as end-to-end business processes, business observability provided real-time insight into how technical issues affected customer bookings and operational teams. This shared context improved collaboration between IT, call centers, and operations, reducing response times and improving passenger experience during disruptions.

Insurance and regulated industries

An insurer tracked claims submissions as business events and noticed rising exception rates on mobile channels. Business observability revealed that document uploads from newer devices exceeded a backend file-size limit introduced during a recent update. Because business events, logs, and user session data were correlated in real time, teams deployed a same-day fix and notified affected customers—preventing claim backlogs and demonstrating operational transparency to regulators.

Manufacturing and public sector

Organizations running complex, multi-step production or licensing processes use business observability to monitor each step as it moves across applications, infrastructure, and external systems. In manufacturing and government services alike, correlating process steps with technical events allows teams to identify bottlenecks that delay outcomes—such as throttled payment validation or downstream capacity limits—and resolve them without disrupting customer- or citizen-facing services.

Enabling data-driven executive insight

For executives, business observability shifts technology from a cost center to a source of executive intelligence, providing leaders with real‑time visibility into revenue, customer experience, operational performance, and risk. It enables:

• Real-time business health monitoring: Live dashboards show key performance indicators such as order volume, claim processing times, or fulfillment success rates.
• Anomaly detection: Advanced analytics identify deviations in both technical and business metrics before they escalate.
• Impact analysis: Teams can immediately quantify how issues affect revenue, engagement, or satisfaction, and prioritize based on real business value.
• Trend analysis: Historical and real-time data combine to forecast outcomes and guide strategic decisions.

Improving collaboration between business and IT

One of the most transformative aspect of business observability is the way it unifies language and priorities across teams.

• IT teams can prioritize work by business impact instead of technical urgency.
• Business stakeholders gain visibility into technical dependencies that influence performance.
• Cross-functional teams align around shared outcomes rather than isolated metrics.

This shared context strengthens trust and speeds response, particularly during digital transformation, where both technology performance and customer experience are constantly evolving.

Laying the groundwork for business observability

While business observability may be expressed through dashboards, process views, or executive metrics, its success depends less on how data is visualized and more on how consistently business outcomes are connected to technical signals across teams. Adopting business observability effectively requires thoughtful preparation:

• Data integration: Pull from diverse sources – applications, infrastructure, and business systems – to form a cohesive view.
• Shared metrics: Define how business KPIs map to technical signals.
• Organizational alignment: Ensure teams are trained and incentivized to act on shared insights.
• Platform scalability: Choose an observability solution that supports hybrid, cloud, and partner ecosystems as data volume grows.

The road ahead

Business observability represents a shift from reactive monitoring to outcome-driven intelligence. Rather than focusing solely on system health or individual process performance, it enables organizations to understand in real time how technology influences revenue, customer experience, operational efficiency, and strategic decision‑making. For executives, it means real-time visibility into how technology influences outcomes. For IT teams, it means prioritizing based on business value. For organizations, it means a unified, data-driven way to make decisions with confidence.

In practice, many organizations attempt to reach this level of insight through manually instrumented metrics, custom dashboards, and offline analysis – approaches that require ongoing effort and often delay understanding when it matters most. Dynatrace Business Observability takes a different approach, capturing business events from multiple sources and automatically correlating them in real time with full‑stack telemetry. This delivers the context leaders need to act decisively, without the manual overhead of traditional approaches.

FAQs: Business observability

What is business observability in simple terms?

Business observability is the ability to understand how technical performance affects business outcomes in real time. It connects IT telemetry, such as logs, traces, and metrics, with business data such as transactions, claims, or orders, so teams can see both the cause and the consequence of an issue in one view.

How is business observability different from traditional monitoring?

Traditional monitoring reports on system health (uptime, latency, or resource use) without showing the business impact. Business observability goes further by linking these technical metrics with key performance indicators (KPIs), providing the context to understand how technical changes influence revenue, customer experience, and operational efficiency.

What types of data does business observability rely on?

Business observability combines multiple data sources, including:

• Business data from transactions or processes
• Logs and traces from applications and infrastructure
• Real user monitoring (RUM) for end-user experience
• Data from external business tools like CRM, ERP, or payment systems
• Instrumentation frameworks such as OneAgent and OpenTelemetry for consistent telemetry across environments

Who benefits most from business observability?

Executives gain real-time visibility into how technology affects performance and outcomes. IT and engineering teams gain business context to prioritize fixes based on impact. Together, these perspectives drive faster decision-making and closer alignment between technology operations and business goals.

What are common use cases for business observability?

Typical use cases include:

• Detecting and resolving process slowdowns in finance, healthcare, or logistics workflows
• Tracking and optimizing customer journeys and digital transactions
• Measuring the business impact of new releases or integrations
• Identifying inefficiencies that increase costs or carbon footprint

How does business observability support sustainability and cost efficiency?

By correlating business events with resource consumption, business observability helps identify where automation, compute, or storage are overused. This enables teams to optimize cloud spend, reduce energy consumption, and track sustainability metrics alongside operational performance.

What challenges do organizations face when implementing business observability?

Key challenges include integrating data from multiple systems, defining the right shared KPIs between business and IT, and ensuring teams are trained to act on insights collaboratively. Success depends on cross-functional alignment as much as on technology.

Is business observability only relevant for large enterprises?

No. Any organization that relies on digital processes – from mid-sized financial firms to healthcare networks or government agencies – can benefit. The ability to link technical performance to business results is valuable at any scale

The post The rise of business observability appeared first on Dynatrace news.