What is a Dynatrace automated root-cause verdict actually worth on call, and when is it wrong?

## What the verdict can honestly claim An automated causation engine has three inputs: the dependency graph, timing and deviation data per entity, and change events attached to those entities. From those it can make a genuinely strong claim, and it is worth stating precisely because candidates either overstate or dismiss it: > Among the entities that deviated, **this one appears to have started first and lies upstream of the others on a shared dependency path**, and here is the set of entities whose behaviour is consistent with being downstream of it. That is a hypothesis with a blast radius attached, and it is worth a great deal at 02:00. Two things it is emphatically **not**: it is not a statement about which line of code is wrong, and it is not a statement that the cause is inside the estate at all. The graph contains structure and timing; it contains no notion of correctness, intent or the world outside the machines it monitors. ## Where it will be wrong 1. **Shared invisible resource.** Two services with no edge between them degrade together because they sit on the same hypervisor, storage fabric or availability zone. With no edge to walk, the engine picks whichever moved first and names a peer symptom as the cause. 2. **Correctness failures.** Everything is fast, nothing deviates, and the data is wrong. No timing signal moves, so nothing is opened at all. This is the single largest category the automation cannot reach. 3. **Slow saturation.** A connection-pool leak or a queue filling over four days has no crisp onset, so the first-mover heuristic has nothing to latch onto and the deviation may be absorbed into the baseline as normal. 4. **Blind spots in the graph.** When the real cause sits behind an unrecognised protocol, an asynchronous handoff or an unsupported runtime, the nearest observed neighbour is blamed with full confidence. 5. **Causes outside the estate.** A third-party API, a DNS resolver, an expired certificate, a change shipped in a mobile client — all visible only as symptoms at your edge. 6. **Simultaneous fan-out.** A configuration change rolled everywhere at once produces dozens of near-simultaneous onsets, and ordering by first-mover becomes noise at millisecond distances. 7. **Chronically bad baselines.** An engine reacting to deviation from learned normal is quiet about a service that has always been slow, because nothing deviated. ## A worked case A school-meal ordering service running across 47 hosts took a support escalation: schools were reporting orders accepted for pupils with allergies that should have blocked them. The platform had opened nothing at all — request rates held at about 1,340 orders per minute, latency was flat, no entity had deviated. When the team forced the question, the nearest automated finding from earlier that morning pointed at a message broker with a brief queue-depth excursion, which was true and irrelevant. The actual cause was a nightly menu-import job that had written an empty allergen list for 118 dishes. Nothing was slow; a validation rule had been silently skipped. This is category 2 above, and it is exactly the incident nobody could explain from the existing dashboards: every chart was green because every chart measured time and volume, and the failure was in meaning. It was found by a business metric the team added afterwards — accepted orders whose allergen list is empty — not by anything the platform could have inferred. ## What you keep owning yourself | The finding gives you | You still have to establish | |---|---| | Where the deviation appears to have started | Why that entity misbehaved | | Which entities are on the blast path | Whether users are actually harmed | | That a change event coincides with the onset | Whether that change is causal | | That something deviated from normal | That "normal" was ever acceptable | Concretely, the instrumentation that stays yours: - **Business outcomes.** Orders accepted per minute, payment success rate, submissions rejected for validation. These are the only signals that move during a correctness failure, and no platform can infer which counter means "children get fed". - **Explicit context across the edges the automation cannot see** — queue handoffs, batch jobs, custom protocols — so the graph has an edge where causation would otherwise stop. - **A small set of symptom alerts you actually own**, expressed on user-facing outcomes, so the automated verdict is an input to an investigation rather than the thing that decides whether anyone is woken. - **Black-box checks from outside the estate**, which are the only way to see a failure whose cause is not on any monitored machine. ## How to use it on call Treat the verdict as a ranked hypothesis and, above all, as a **scoping** tool. Its most reliable output is not "what caused this" but "what else is affected", and on a large estate that answer is often the more valuable one. Check the stated onset against your own change record rather than accepting the attached events as causal, and confirm with one signal the engine did not use before acting on the verdict — a business counter, a log line, a manual request. The failure mode to avoid in an interview and in production is the same: repeating the verdict as a conclusion when it was only ever the fastest available hypothesis.