Diagnosing a Slow Checkout with Dynatrace PurePath: When Automatic Tracing Beats Writing Spans

Your checkout is slow and everyone has a theory

Picture this: during a promotion, the checkout service's p95 response time jumps from 400 ms to several seconds. Checkout calls a cart service, a pricing service, a payment gateway, and two databases. Every team is confident the problem lives somewhere else. The traditional response is to open five dashboards and start guessing.

The takeaway worth internalizing: with Dynatrace's PurePath tracing, you rarely need dashboard-first guessing, and you rarely need to write tracing code either. OneAgent captures the full path of a single request across services, queues, and databases automatically. The fastest route to root cause is usually to open one slow trace and read it.

What PurePath captures without you writing code

PurePath is Dynatrace's name for its distributed traces: a record of every step one request takes through your stack. OneAgent, the monitoring agent Dynatrace installs on hosts and processes, injects trace context at process boundaries so each hop forwards the identifier that ties the pieces together. You get one connected trace instead of one disconnected log line per service.

Crucially, this is automatic instrumentation. For common frameworks in Java, .NET, Node.js, PHP, and Go, OneAgent hooks HTTP entry points, database calls such as JDBC, and messaging traffic out of the box — no span-creation code, no SDK dependency in your build, no redeploy just to add tracing. Depth varies by language and framework version, so confirm your exact stack is on the support matrix before promising code-level visibility.

Automatic instrumentation vs. hand-written spans

The alternative is manual spans via an SDK such as OpenTelemetry. Both are legitimate; they solve different problems.

Aspect	OneAgent automatic	Manual OpenTelemetry spans
Setup	Install agent, restart process	Add SDK, write code, deploy
Coverage	Common frameworks and protocols out of the box	Anything you instrument, including custom protocols
Maintenance	Updated with agent releases	Yours to maintain
Control	Limited to supported paths	Full control over attributes and sampling
Interop	Merges ingested OTLP traces with agent data	Standard OTLP export

The practical decision rule: default to automatic instrumentation for breadth, and drop down to OpenTelemetry only where OneAgent cannot see — an unsupported framework, a custom wire protocol, or business attributes you want attached to spans. Dynatrace accepts OTLP traces and merges them with OneAgent-captured data, so it is not either/or.

Worked example: reading a slow checkout trace

Here is the workflow for the slow-checkout scenario. Exact menu names shift between Dynatrace versions, so treat this as a sequence rather than a click-path.

1. Start from the symptom: the checkout service's response-time chart shows the spike. Open the distributed traces for affected requests in that time window.
2. Pick one slow trace and read the waterfall of spans. Each span is a timed unit of work — an HTTP call, a service method, a SQL statement — nested under the request that caused it.
3. Find the longest span. In checkout-style flows it is often a database call rather than application code.
4. Open that span's detail. OneAgent captures the SQL statement text and, depending on configuration, bind values; method-level hotspots show where time went inside the service.

That gives you a diagnostic decision instead of a hunch: if the dominant span is a SELECT against the inventory table, the fix belongs in the query or the schema, not in the checkout code. One observation redirects a day of speculative profiling into a targeted change.

Dynatrace's Davis AI adds a correlation layer on top: it links traces, logs, and metrics into a root-cause problem view, so during an incident the problem card may point at the offending service or statement before you go looking. Treat it as a strong lead to verify against the trace, not a verdict.

Limits to plan around

• Sampling and capture limits: in high-volume environments Dynatrace may not retain every trace at full fidelity. Do not build processes that assume 100 percent capture; check your environment's configuration.
• Retention varies: trace retention depends on your deployment and settings, so do not promise a fixed lookback window without checking.
• Sensitive data: SQL bind values and HTTP headers can be captured — great for diagnosis, awkward for compliance. Masking is configurable; set it before you need it.
• Unsupported paths: for anything OneAgent does not auto-instrument, plan the OpenTelemetry fallback early rather than mid-incident.

Verify it in your environment before you rely on it

Feature names, licensing, and UI paths change often enough that screenshots age fast; a hands-on check does not. On a demo app — for example, a Spring Boot service calling a database — in a trial environment:

1. Install OneAgent on the demo host and restart the app process so instrumentation loads. Uninstalling the agent removes instrumentation, so a demo host is low-risk.
2. Generate traffic and confirm a trace appears with spans for the HTTP entry point and the SQL calls.
3. Inject a deliberately slow query — for example, a non-sargable predicate that forces a table scan:

   SELECT count(*) FROM order_lines WHERE note LIKE '%gift%'

4. Check whether the distributed trace and the problem view surface that query as the root cause.
5. Review the current Dynatrace documentation for your version to confirm supported frameworks, trace settings, and masking options.

If those checks pass, you have the workflow described here — and the next slow checkout takes minutes to diagnose instead of a war room.