I have covered observability extensively as a discipline and as a tech sales opportunity, but haven’t really gotten to one of the most peculiar and unusual companies in the developer tooling space, Dynatrace.
While companies like Datadog, Grafana, or Elastic focused on their developer-first adoption motion, Dynatrace always stood out for taking a completely different approach to the problem of observability from a process and people perspective. The rise of observability platforms over the last ten years is directly correlated with the widespread adoption of DevOps principles and practices across most engineering orgs.
Depending on the point of view, Dynatrace can be seen as “anti-DevOps” in terms of being a tool that was pushed top down on developers, who never really had a choice or significant input into what gets rolled out or how. This would stand firmly against the “developer choice and focus on developer productivity” part of DevOps. On the other hand, there is the “automation and platform” side of DevOps: reduce toil, centralise capability, let the platform do the work. Dynatrace bet on that side, and the current platform-engineering wave (golden paths, internal developer platforms, “you shouldn’t need to know how observability works”) is arguably a vindication of that bet, particularly as we move towards the age of agent-first workflows.
The big question, of course, is whether Dynatrace can actually monetize a landscape that has shifted decidedly in its favour.
The key takeaway
For tech sales and industry operators: Dynatrace was directionally correct in it’s vision to build a comprehensive platform that could offer superior value if all workloads were consolidated on it. That’s a big if in a market where alternatives can be dramatically cheaper and many teams prefer to run their own stack. While $2B of revenue is nothing to sniff at, relative to the quality of the product and the success of it’s peers, something is not fully clicking in this motion. With it’s current growth rate and market environment, Dynatrace the company will probably keep doing fine but your average sales rep will struggle to actually get paid for it. Funnily enough, if you join a competitor and focus on making Dynatrace's core audience (platform engineering) successful, you will displace them on economics, and the champion won't fight you, because you just made them look good in a cost-cutting environment.
For investors and founders: Dynatrace is what a PE-shaped GTM leads to when applied to a founder-shaped product. Observability products are fundamentally driven by developer adoption, which Dynatrace skipped because for most of its history it was optimizing for a five-year exit. The big challenge ahead is that the industry is moving toward customer optionality (OTel) and agent-first workflows, which Dynatrace is paying lip service to but will never fully buy into. The whole organization is built around margin optimization, which leaves very little flexibility for strategic bets. A professional CEO with margin-focused shareholders is not going to open up Smartscape to other people's agents and give away the Dynatrace Intelligence premium, because that bet shows up as a margin hit this year and a strategic benefit in three years, which is forever in AI-native terms. The future of Dynatrace is likely to look like that of many other enterprise-focused companies: a strategic partner to its installed base for the foreseeable future while the next generation of companies never becomes a customer.
“A world where software works perfectly”
Rick McConnell: The observability market has entered a new era. Software that once took months to build now ships in days. AI agents are taking autonomous action across infrastructure and enterprise customers are now deploying AI rapidly, not because every risk has been resolved, but because standing still means falling behind. In this environment, unified observability matters more than ever. Systems are more interconnected, more autonomous and more difficult to manage manually than ever before. The enterprises winning in this environment are the ones that can keep complex, fast-moving systems working reliably and quickly understand when they are not. Additionally, AI workloads do not simply add volume. They behave differently. They can operate perfectly and still produce incorrect results.
That’s a problem observability has never had to solve before and addressing it represents a significant emerging opportunity. We estimate the AI observability total addressable market will exceed $10 billion by 2030, growing at more than 50% annually. We see AI observability as the next logical evolution of the broader observability market, and that evolution is already underway. What this means in practice is that observability in the age of AI has to answer far more questions than ever before. While the majority of enterprises are still in early phases of their AI journey, the requirements are evolving quickly. Let me walk through 3 of the questions that matter most today in an AI-first world. The first, is it working?
Are applications, infrastructure and systems working as intended? This question is about business resilience and is the same question we ask of traditional workloads. Second is new. Is it accurate? More specifically, is the AI model delivering output that can be trusted and relied upon with confidence. Answering this means evaluating AI systems for accuracy and intended behavior, determining whether an AI system behaves as intended before it shifts is emerging as one of the most important aspects of observability. The third, are my agentic systems delivering the outcomes they were built for. Enterprises are deploying agents to build software at a pace that wasn’t possible before.
The advantage goes to those who can accelerate the full life cycle and trust the results. Code that’s built well, ships safely and runs reliably. The last question is where our newest offering, Bluebox comes in. Built for AI-first teams, Bluebox helps development teams and their coding agents bring software into production in a way that customers can trust. It closes the loop between building and running. It gives coding agents live context from running systems before a change is released. Once that change is live, its agentic SRE capability finds root cause and returns an evidence-backed fix with the developer in control across the entire AI delivery life cycle. This is the moment for which Dynatrace was built.
The funny thing about Dynatrace is that it was probably the main observability company with a realistic claim to offering working AI way before LLMs became widely adopted. This comes back to the product approach and how it was built as a coherent full-stack platform from the very beginning.
There are 3 core architectural decisions in a Dynatrace implementation that are quite different from the usual technical motion in observability:
There is a mandatory agent deployment per host, which is unusual, but it solves a lot of practical problems, such as what data needs to be ingested and whether we have full visibility across the application/infrastructure being monitored. Logs are the exception here. Dynatrace has historically struggled to win log workloads, which often form the bulk of the paid observability business a customer would have, but that was a product and pricing problem rather than an agent problem: log monitoring was an afterthought until Grail in 2022, DDU pricing was hostile to high-volume ingest, and logs are the one workload where many competitors have mindshare that started with “you can do it with us for free.”
The relationships between applications and infrastructure are mapped out in a graph, the same idea that Wiz later applied very successfully from a cloud security perspective (with the difference that Wiz built its graph from cloud APIs without an agent, which is exactly the argument against the Dynatrace model). Dynatrace maintains a real-time model of host → process → service → application → user. The reason this is beneficial is that there is a massive difference between “these two things spiked at the same time” and “this service calls that one, and the fault propagated along this path.”
Their AI play is actually quite effective because, if you have a complete graph, root cause becomes a graph-traversal problem rather than a statistical anomaly problem. “Dynatrace Intelligence” runs on that topology and produces one problem card with a stated root cause instead of 40 correlated alerts. This advantage has narrowed a lot in the last year, with LLM agents becoming very good at correlating multiple signals from metrics, logs, and traces without the “guarantee” of the graph approach, and with Datadog, Grafana, and Elastic all shipping assistants that close the perceived gap. It is still probabilistic correlation rather than a deterministic answer, but Dynatrace has mostly lost the ability to explain why that difference matters.
All of these advantages play very well into the “automation and platforms” approach. The main weaknesses are exposed if we come back to “developer choice” and enabling a complex mix of tools:
If a company is limiting the deployment of agents, either partially or fully, Dynatrace offers very limited differentiation. Without the agent, the graph and the AI have nothing to work with.
The move towards OTel (OpenTelemetry) removes a lot of the “we collect better data” advantages, with Dynatrace being disproportionately impacted compared with other vendors. They have done the work to support it (native OTLP ingest, OTel-based collectors, OpenPipeline), but they are structurally disincentivised from leading on it, because once the customer owns the instrumentation, the graph has to be rebuilt from the same semantic conventions everyone else uses.
Between a confusing pricing model and a top-down sales motion, there is very little organic support or developer advocacy for the product internally. This makes it very difficult for Dynatrace to really have a meaningful SMB/Mid-Market business, which is also a problem when it comes to winning AI natives, since they start small and are currently being courted by Datadog, Grafana, Sentry, Honeycomb, and ClickHouse.
If we have to simplify it, Dynatrace sells answers from a complete, self-built topology, Datadog sells breadth and developer experience, and Grafana sells optionality. Datadog is always trying to make a full-scale push into security analytics, Dynatrace is dipping its toes but is worried about it, and Grafana has chosen to opt out.