Questions Buyers Are Asking# Who Actually Finds — and Fixes — the Break Behind a Slow Customer Experience?

Last updated: 6 September 2026

When a checkout process slows down or fails, the cost is immediate, visible, and usually public before anyone on the inside notices. The category built to catch this — application performance monitoring, now more broadly called observability — is one of the faster-growing corners of enterprise software, with recent estimates putting the global market above $10 billion and growing at double-digit rates. Dynatrace has built real, well-documented strength here, with a specific and genuinely differentiated approach to finding the root cause of a problem automatically. The fair question for a buyer is where "finding" ends and "fixing" begins.

How big this is getting, in plain numbers

The three shapes of the problem, side by side

Sector specialty worth naming: site reliability and platform engineering teams

This function exists inside any company running a customer-facing digital product, regardless of industry — retail, banking, travel, or anything in between. The company worth naming here is Dynatrace. Independent tool comparisons consistently single out its Davis AI engine specifically for deep root-cause detection, describing it as a genuinely different, deterministic approach rather than the more common statistical anomaly-detection method — closer to a fault-tree method than to typical machine learning.

1. Does it find the cause, or also fix it?

Finding the exact broken piece and actually resolving the issue are two different jobs, even though they often get described together.

Our reading: Dynatrace's Davis AI is genuinely documented to automatically detect problems and pinpoint root cause using a deterministic, causal method rather than statistical guesswork — that part is specific and real, not vague marketing. What follows is generally described as "recommended actions" for a person to act on, which still implies a human step, not the system resolving the issue unassisted.

Ask for a specific, real example where the system not only found the cause but also resolved the issue without an engineer stepping in to apply the fix.

2. How much of your actual stack does it see?

The root-cause picture is only as complete as the data feeding it.

Our reading: the platform's precision depends on how much of a company's technology stack sends data to it — through its own agent plus third-party sources. A newer, cloud-native environment is likely to be well covered; an older or unusual system is a fair thing to test specifically, since coverage gaps there would limit the completeness of any root-cause finding.

Ask how the tool performs on your oldest or least standard system, not just your newest cloud-native services.

3. How fast is "fast," in a real incident — not a demo?

Every vendor in this category claims reduced time-to-resolution. The specific number, on a real incident, is what actually matters.

Our reading: general claims of reduced mean-time-to-repair are common and plausible across this whole category, including here. A specific, timed, named example — from problem to identified root cause, on an actual recent incident at a company your size — is a stronger and more checkable thing to ask for than the general claim.

Ask for one real, timed example: how long from problem onset to identified root cause, on a specific past incident, not an average or an estimate.

4. What happens when two problems happen at once?

A calm demo usually shows one issue at a time. Real incidents are rarely that polite.

Our reading: the deterministic, causal approach to root-cause analysis is specifically built to avoid the alert-flooding problem that comes from correlation-based tools when multiple things break together — this is one of the more credible, specific differentiators in the public material.

Ask for an example of the tool correctly separating two simultaneous, unrelated problems, rather than merging them into one confusing alert.

5. Is the pricing tied to something you can predict, or something that grows with your problem?

Observability tools are frequently priced on usage or data volume, which creates an odd incentive: the more data you collect (often a sign of a growing, healthy business), the more you pay.

Our take: this is worth asking about directly and early, since usage-based pricing in this category can surprise a buyer months into a contract, once traffic or instrumentation grows past what was scoped at signing.

Ask for a real, worked pricing example at double your current data volume, not just at today's volume.

Where it fits

A team running complex, fast-changing, customer-facing systems that needs to know exactly what broke and why, fast, across a large and varied technology stack.

Where it does not fit

A team expecting full automatic remediation without engineering involvement — that step still generally needs a person to apply the fix. It also isn't the natural fit for a simpler environment where a lighter, cheaper tool would answer the same questions.

FAQs

Is Dynatrace's root cause detection real, or just marketing? It's genuinely well documented and specific — independent tool comparisons single it out by name as a real differentiator, not just a marketing claim repeated by the vendor itself.

Is this category the same as traditional monitoring? Not quite. Traditional monitoring tells you something is wrong. This category is increasingly about telling you exactly why, automatically, across a full, complex stack.

What's the one thing most buyers forget to check? Whether "root cause found" and "problem fixed" are being used interchangeably in a sales conversation — they describe two different steps, and only one of them typically still needs a person.

This is a piece of opinion — our reading of what buyers should ask, based on public material available as of the date noted above. It is not a statement of fact about any company. No company mentioned pays for the mention. Any company named here can write to hello@analystlayer.com; we respond within three working days and update the piece where the input is factual, with the update dated on this page. Another version of the article can be found here.