Skip to content
Datadog APM

Find the slow request
before the customer does.

Datadog APM follows a request across every service it touches. We implement it, tune the sampling so the bill holds, and run it every month so the traces still explain the incident a year from now.

Traces
Every hop of a request, across every service
Service map
Dependencies as they really are
Three meters
Hosts, ingested spans, indexed spans
Monthly
Sampling and monitors reviewed

Quick facts

CoversDistributed tracing, service map, trace search, Universal Service Monitoring, Dynamic Instrumentation
Start withDatadog HealthScan if APM is already on. LaunchPad if it is not.
Runs onManaged Observability, with Critical Support for the incident itself
AcceleratorInfrastructure Observability, four weeks, fixed scope
Best whenLatency complaints arrive before the alerts do, or the APM bill moves and nobody can say why

Related

01
What APM gives you

The request, followed all the way down

A slow checkout is rarely slow in the service that owns it. It is slow three hops away, in a query nobody has looked at since the migration. APM follows the request through every hop and shows which one took the time.

One trace per request. Each hop is a span with its own timing, errors and tags. The flame graph shows where the time went, in order, without guessing.

A service map that is true. Dependencies are drawn from real traffic, not from a diagram somebody made in 2024. Orphaned services and surprise callers show up on their own.

Traces joined to logs and metrics. With unified service tags in place, one click moves from the slow span to the log line it wrote and the host it ran on.

Monitors on real behaviour. Latency, error rate and throughput per service and per endpoint, with Watchdog flagging the changes nobody set a threshold for.

02
Where it goes wrong

Three meters, one tag convention, and a sampling rate somebody set in a hurry

How it bills. APM hosts are counted on the hourly high-water mark of the lower 99 per cent of usage. Ingested spans are billed per gigabyte. Indexed spans are billed per million, and retention filters decide which spans are indexed. Each host carries an allotment of both. Serverless and Fargate use per-invocation and per-task meters instead. Datadog publishes the rates. We publish nothing here, because the price is not the problem. The configuration is.

The configuration traps. The tracer ships with a default sampling rate and a default retention filter that keeps a representative sample. Both are fine for a trial. Neither was chosen for a production estate. Ingestion controls set at 100 per cent on a busy service ingest every span and pay for every byte. A custom retention filter with no rate limit indexes every span that matches it, forever. A tracer rolled out to hosts that never needed it adds APM hosts to the high-water mark. None of these shows up as an error. All of them show up on the invoice.

Field noteThe most common gap we see is unified service tagging. The Agent says one service name, the tracer says another, the logs say a third. The service map draws three half-services and the trace never joins the log line.

Field noteSampling is set once, during the rollout, as a fixed percentage chosen by whoever was doing the rollout. It is then never revisited. Traffic doubles, the sampling rate does not, and the ingested span bill doubles with it.

Field noteRetention filters written for one incident stay on after the incident. Each one indexes a slice of spans nobody reads. The filters are easy to add and nobody is paid to remove them.

Field noteThe tracer version drifts. One service runs a library three major versions behind the rest, and the span it emits for the same database call looks different enough that the dashboards split into two.

03
How we implement it

Tags first. Tracers second. Sampling before anyone sees a bill.

If APM is already switched on, we start with a Datadog HealthScan. It is read-only and fully automated, and it reports tracer coverage, tag consistency and span volumes before we change anything. If APM is not on yet, LaunchPad runs the rollout as a managed project. Either way, the sequence is the same.

  1. Agree the service inventory. We list every service, who owns it, which language it runs, and whether it matters at 2am. Services that do not matter at 2am get Universal Service Monitoring, not a tracer.
  2. Set unified service tagging. One value each for env, service and version, applied in the Agent, the tracer and the log pipeline. This step is boring and it decides whether anything else works.
  3. Roll the tracer out by tier. Edge services first, then the services they call, then the data layer. Each tier is checked in the service map before the next one starts.
  4. Set ingestion controls and retention filters. Sampling rates per service, based on traffic and on what an incident actually needs. Retention filters for errors and for the endpoints that earn money. A rate limit on every custom filter.
  5. Build the monitors and the dashboard pack. Latency, error rate and throughput per service, with thresholds set from a fortnight of real data rather than a round number.
  6. Hand over, in writing. What was configured, what was decided, which spans are kept and why, and what the ingested and indexed volumes were on the day we finished.

Access is admin on the Datadog organisation plus read access to the deployment tooling. We do not need production shell access to implement APM, and we do not ask for it.

04
Getting the most out of it

APM is not finished at handover. It is finished when the estate stops changing, which is never.

New services ship without a tracer. Traffic patterns move. A retention filter added during an incident stays on for a year. Managed Observability is the monthly service that keeps APM matching the application it watches.

Every month, we review the meters. APM host count against the high-water mark, ingested span volume per service, indexed span volume per retention filter. Anything that moved gets a reason or a fix.

Coverage follows the deployments. A new service without a tracer or without the right tags is found in the service map review and instrumented before it is the service everyone is looking for.

Monitors earn their place. A monitor that has not fired for a real reason in a quarter is retired or rebuilt. Alert noise is a configuration problem, and configuration is what we run.

The incident is ours to take. Under Critical Support our engineers answer the alert the trace raised, 24x7, and fix the cause rather than report it. Datadog has published that our work reduces mean time to resolve incidents by 40 to 60 per cent.

05
Why with Critical Cloud

We operate the stack. You own the product.

An implementation partner configures APM and hands it over. A managed partner is still there when the sampling rate is wrong in March. We are the second kind. The tracer config, the dashboards and the decisions stay in your Datadog organisation, documented, and you can take them in-house whenever you choose.

Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.

Powered by Datadog accredited Datadog Advanced Partner ISO 27001 Cyber Essentials Plus 10+ years on Datadog
06
Questions we get asked

Datadog APM, answered plainly

How is Datadog APM billed?

Datadog APM has three meters. APM hosts are billed on the hourly high-water mark of the lower 99 per cent of usage, so a short spike does not set the bill but a sustained one does. Ingested spans are billed per gigabyte. Indexed spans are billed per million, and retention filters decide which spans are indexed. Each host carries an allotment of ingested and indexed spans. Serverless and Fargate workloads use per-invocation and per-task meters instead. We do not publish prices. The meters are what we tune.

Do we need to change our code to use Datadog APM?

For most languages, no. The Datadog tracer attaches to the runtime and instruments common frameworks, web servers, database clients and queues on its own. Code changes are needed for custom spans, for business tags such as customer or tenant, and for the few frameworks the tracer does not cover. Universal Service Monitoring gives request, error and latency metrics from the Agent alone, with no tracer at all, which is a useful first step for services nobody wants to touch.

Why does our Datadog APM service map have gaps?

The two common causes are services without a tracer and services without unified service tags. A service that is not traced appears only as an external call from its neighbours. A service whose env, service and version tags differ between its Agent, its tracer and its logs appears as several half-services that never join up. The fix is tag discipline first and tracer coverage second, in that order.

Does Datadog APM include profiling and error tracking?

They are separate products that run from the same tracer. Continuous Profiler shows where CPU, memory and wall time go inside a service and is billed per profiled host on its own meter, or comes bundled in the APM Enterprise tier. Error Tracking groups exceptions from traces, logs and RUM into issues. Both are switched on in the tracer configuration once APM is in place, and both are covered on their own pages.

What does Critical Cloud do with APM every month?

Managed Observability runs it every month. We review sampling and retention filters against the ingested and indexed span volumes, retire monitors that no longer fire for a real reason, add coverage when new services ship, and report what changed. Under Critical Support our engineers also take the incident the traces point to, 24x7.

Read next

Traces that explain the incident. A bill that holds.

Tell us which services matter at 2am. We will tell you what APM is doing today, what it should be doing, and what it costs to get there.