Short answer: On August 13, 2026, Dynatrace signed a definitive agreement to acquire AI observability company Arize for $915 million, roughly $815 million of it in cash. The deal buys Dynatrace a position with AI engineers at build time, before an application ever reaches production. It does not close the gap that opens after an alert fires, which is getting the right responder paged with enough context to act. AI observability and incident response are still two separate layers, and a nine figure acquisition makes that separation more visible, not less.

Key takeaways

AI observability answers whether the model or agent behaved correctly. Tools include Arize, Phoenix, Langfuse and Braintrust. It tells you nothing about infrastructure, database or dependency failures.
Infrastructure and APM observability answers whether the system is healthy and where the anomalies are. Tools include Dynatrace, Datadog, New Relic and Grafana. It rarely tells you which anomaly is the cause and which are symptoms.
Alerting and on-call answers who gets woken up and when it escalates. This is where Pagerly, PagerDuty and Opsgenie operate. The open question is whether the responder arrives with context or with a blank page.
Investigation and resolution answers what actually broke and what to do about it. Historically this is the least automated step in the entire chain, and it is where incident duration is really decided.
The Dynatrace and Arize deal strengthens the first layer. It leaves the third and fourth exactly where they were.

What Dynatrace actually bought for $915 million

Dynatrace, listed on the NYSE as DT, announced a definitive agreement to acquire Arize in a cash and stock transaction valued at $915 million. The terms break down as roughly $815 million in cash plus replacement equity awards for Arize employees joining Dynatrace, funded from cash on hand or the company's existing credit facility. Arize co-founders Jason Lopatecki and Aparna Dhinakaran both join at closing, with Lopatecki continuing to lead the Arize team. The transaction is expected to close later in the quarter or early in Dynatrace's third fiscal quarter, subject to regulatory review.

Arize was founded in 2020 in the San Francisco Bay Area. Its platform lets engineering teams test, evaluate and monitor the behavior of machine learning models, large language models and AI agents in production, including hallucination and drift detection. Its open source project, Phoenix, is widely adopted by AI engineers as a local evaluation harness.

For context on scale, this is the largest acquisition Dynatrace has ever made. Earlier purchases including Bindplane, Metis, Runecast and Rookout were far smaller, and in most cases the price was never disclosed. Dynatrace crossed $2 billion in annual recurring revenue in fiscal 2026 and employs around 5,600 people worldwide.

Primary sources: the official Dynatrace announcement on Business Wire and Forbes analysis of the strategic rationale.

Why Dynatrace paid a record price for an evaluation platform

The obvious reading is that Dynatrace lacked AI observability and bought it. That reading is wrong on the facts. Dynatrace was already shipping evaluation before this deal. Its AI Observability app already traced gen_ai spans, scored live production responses with LLM as a judge evaluators, and detected drift in those scores over time.

What Dynatrace did not have was a relationship with the people who choose the evaluation harness. Those decisions get made while an application is still being written, often months before an operations team sees anything. Datadog, Splunk and Dynatrace all sell into operations and platform engineering, and their evaluation features grew out of those existing relationships. Arize grew from the opposite direction, with a free local project that AI engineers adopt long before a procurement conversation exists.

By the time an application reaches production, the instrumentation library, the trace schema and the evaluator definitions have already been chosen. Dynatrace paid $915 million to be in the room when that happens. This is a distribution acquisition, not a capability acquisition.

That distinction matters for anyone reading the deal as a signal about their own roadmap. The market did not just declare that AI root cause analysis is a solved product category. It declared that developer adoption at build time is worth nine figures to an incumbent whose center of gravity sits after deployment.

What AI observability covers, and exactly where it stops

AI observability tools answer a specific question: did the model or the agent behave the way it was supposed to? They do this well. They trace every span in an agent run, score outputs against evaluators, catch hallucinations, flag drift in quality metrics over time, and let teams compare prompt versions against a fixed test set.

Here is what they do not do. When an AI agent returns a wrong answer, the cause is frequently not in the AI layer at all. Common examples from real production incidents:

A retrieval step timed out because the vector database was under load, so the model answered from an effectively empty context window.
A connection pool was exhausted, so a tool call the agent depends on silently returned a partial result.
A node under memory pressure caused a service three hops upstream to return stale data.
A schema migration changed a field name, so the agent's tool call succeeded but returned nulls.
A rate limit on a third party API triggered a retry storm that pushed latency past the agent's internal timeout.

In every one of these cases, the prompt was fine and the model was fine. An AI observability trace will faithfully show you a bad output and give you no path to the actual cause. The cause lives in infrastructure, in the database, or in a dependency, and it is visible only to tools that were watching those layers.

This is the structural point the acquisition surfaces. Evaluating AI output and diagnosing system failure are genuinely different problems with different data requirements. Bundling them under one vendor's billing relationship does not merge them into one workflow.

The detection to resolution gap

There is a second gap that gets far less attention than the AI versus infrastructure split, and it costs teams more hours per year.

Every observability platform, AI native or otherwise, terminates in a dashboard or an alert. That is the end of the product's job. It is nowhere near the end of the incident.

What happens next in most engineering organizations looks like this. An alert fires. It routes to a channel or a phone. Someone who may or may not be the right person acknowledges it. That person opens a dashboard they do not use daily, scans forty active alerts, and spends the first fifteen to thirty minutes of the incident working out which alert is the cause and which thirty nine are downstream symptoms of it. Only then does actual remediation begin.

Detection has improved by an order of magnitude over the last decade. That first thirty minutes has barely moved.

The four layers of an AI incident

A useful way to think about this is that any incident involving an AI system has four distinct layers, and most tooling covers exactly one of them.

Model layer. The prompt, the completion, the evaluator score. Owned by AI observability tools.
Application layer. The service that called the model, its dependencies, its error rates. Owned by APM.
Infrastructure and data layer. Nodes, pools, queues, queries, storage. Owned by infrastructure monitoring.
Human layer. Who is on call, who gets paged, what they know when they arrive, how it escalates, what gets communicated to customers, and what gets fixed permanently afterward.

The first three layers have had enormous investment. The fourth is where incident duration is actually determined, and it is the layer where most teams still run on process discipline and individual heroics rather than tooling.

What actually matters in an incident response layer

If you are evaluating this part of your stack, these are the criteria that separate tools that reduce incident duration from tools that merely forward notifications.

1. Time from alert to the correct responder

Routing to a channel is not routing to a person. The measure that matters is how long it takes for a human who can actually fix the problem to be looking at it. Rotation coverage, escalation policies with real timeouts, and override handling for vacations and sick days all feed into this single number.

2. Separation of cause from symptom

A P1 that generates forty alerts is not forty problems. If your response layer presents forty equal items, it has pushed the hardest analytical work onto the most sleep deprived person in the company. Grouping, correlation and noise analysis belong in the tool, not in the responder's head.

3. Where the work happens

If the responder has to leave the place their team already communicates in order to run the incident, coordination fragments immediately. Incident channels, severity assignment, timeline capture and status updates should live where the conversation already lives. For most engineering teams that is Slack.

4. Investigation that runs before the human reads the page

This is the newest and most consequential criterion. An AI SRE agent can begin pulling logs, metrics and recent deploys the moment an incident opens, so the responder's first screen is a hypothesis rather than a blank page. The value is not that the agent is always right. The value is that it eliminates the cold start.

5. Coverage integrity

Schedules drift. People swap shifts informally and forget to update the tool. Someone leaves the company and stays in a rotation for three months. A response layer that cannot show you, right now, who is genuinely reachable is a liability rather than an asset.

6. Customer communication

Internal resolution and external communication run on different clocks for different audiences. If updating the public status page requires a separate login and a separate person, it will lag the incident by twenty minutes every single time.

7. What happens after resolution

MTTR trends, recurring incident patterns, alert noise sources, and follow up action items with named owners. Without this, the same incident recurs quarterly and nobody has the data to justify fixing the underlying cause.

How to choose: a decision framework

Are your incidents mostly AI quality issues or mostly system failures? If genuinely mostly model quality, an evaluation platform is your priority and Dynatrace with Arize is now a credible single vendor path. If mostly system failures that happen to surface in an AI product, evaluation tooling will not shorten a single incident.

Do responders currently arrive at an incident with context or without it? If without, the highest leverage investment is an investigation layer that runs automatically at incident open, not more instrumentation. You are not short of data. You are short of synthesis.

Does your team run incidents in Slack already? If yes, tooling that lives outside Slack will be routed around within a quarter. Adoption follows existing habits rather than replacing them.

Can you name, right now, who is on call for each service? If that takes more than ten seconds to answer, coverage integrity is your bottleneck and no amount of observability spend will help.

Are the same incidents recurring? If yes, the gap is post incident action item tracking, not detection.

Where Pagerly fits alongside Dynatrace, Datadog and New Relic

Pagerly operates at the fourth layer, the human layer, and it is explicitly complementary to whatever observability stack you already run.

Pagerly handles on-call schedules and rotations, escalation policies, overrides and shift swaps, incident declaration with automatic Slack channel provisioning, severity assignment from P1 through P4, incident timelines, public status page components and updates, follow up action items with owners and status, and reporting that includes MTTR, severity distribution and recurring incident patterns. Alert noise analysis identifies which integrations generate volume that never converts into a real incident.

The AI SRE capability runs investigation across logs, metrics and system state when an incident opens, so the responder receives a starting hypothesis rather than a link to a dashboard.

None of that replaces Dynatrace, Datadog, New Relic or Grafana. Those tools remain the source of truth for telemetry. Pagerly is the layer that turns telemetry into a specific human doing a specific thing at a specific minute, inside Slack, with context already assembled.

If you are running Arize today and will be running it under Dynatrace next quarter, nothing about that changes what Pagerly does. The evaluation layer tells you the agent misbehaved. The observability layer tells you what the system looked like when it did. The response layer decides who wakes up and what they already know when they do.

Use case cheat sheet

Small platform team, alerts routing to a shared Slack channel everyone ignores. Start with real rotations and escalation policies. The problem is ownership, not visibility.
Team with excellent Datadog coverage and a thirty minute time to first hypothesis. The gap is investigation automation at incident open.
AI product team where most incidents originate below the model layer. Evaluation tooling will not help. Cross layer investigation will.
Team with a public status page always twenty minutes behind reality. Integrate status updates into the incident workflow instead of treating them as a separate task.
Team where the same three incidents recur every quarter. Action item tracking with named owners is the missing piece.
Team where nobody is confident who is on call this week. Coverage integrity first, everything else second.
Team drowning in alerts from one noisy integration. Run alert noise analysis before adding any new tooling at all.
Team that just consolidated onto a single observability vendor and expects incident duration to drop. It will not drop on its own. Consolidation changes billing, not workflow.

Frequently asked questions

The deal

How much did Dynatrace pay for Arize? $915 million in cash and stock, consisting of approximately $815 million in cash plus replacement equity awards for Arize employees joining Dynatrace.

When was the Dynatrace and Arize acquisition announced? Dynatrace signed the definitive agreement on August 13, 2026. The transaction is expected to close later in that quarter or early in Dynatrace's third fiscal quarter, subject to regulatory review.

Is this Dynatrace's largest acquisition? Yes. Previous acquisitions including Bindplane, Metis, Runecast and Rookout were significantly smaller, and most were never publicly priced.

AI observability basics

What does Arize actually do? Arize provides a platform for testing, evaluating and monitoring machine learning models, large language models and AI agents in production, including hallucination detection and quality drift tracking. Its open source project Phoenix is widely used by AI engineers as a local evaluation harness.

Does AI observability find the root cause of AI failures? Not usually. AI observability identifies that an output was wrong and traces how it was produced. When the underlying cause is a slow query, an exhausted connection pool or a node under memory pressure, the cause sits outside the AI layer entirely and requires infrastructure and application telemetry to diagnose.

Incident response

What is the detection to resolution gap? It is the interval between an alert firing and a responder forming a correct hypothesis about the cause. Detection tooling has improved dramatically over the last decade. This interval, typically fifteen to thirty minutes, has not.

Does an AI SRE replace human on-call engineers? No. It removes the cold start. The responder still decides and still remediates, but begins from an assembled picture rather than from a blank dashboard.

Do I need incident response tooling if I already have Dynatrace or Datadog? Those platforms tell you that something is wrong and provide the telemetry to investigate it. They do not manage rotations, escalations, incident coordination or post incident follow up. Those are separate functions with separate failure modes.

Pagerly

Does Pagerly replace my observability stack? No. Pagerly sits on top of it. Telemetry stays where it is. Pagerly manages who responds, how the incident is coordinated, what is communicated externally, and what gets fixed afterward.

Where does Pagerly run? Inside Slack, which is where most engineering teams already coordinate during an incident.

The bottom line

A $915 million acquisition is a strong signal, but not the signal most of the commentary is claiming. Dynatrace did not concede that it lacked AI observability. It bought a foothold with AI engineers at the moment tooling decisions get made, months before anything reaches an operations team.

What the deal does confirm is that the observability market keeps investing in seeing more, while the interval between an alert and a correct hypothesis sits roughly where it was ten years ago. You can buy the best telemetry stack available and still have a person at 2am deciding which of forty alerts matters.

That interval is where incident duration is actually determined, and it is the part of the stack that no observability acquisition has addressed yet.