Datadog.

Where Datadog fits on a long engagement.

The value is correlation. Being able to move from a latency spike to the trace to the log line in one place is materially faster than reconstructing the same picture from three tools during an incident, and incident duration is what the investment actually buys.

Two failures are near-universal. Cost climbs because custom metrics and log ingestion are billed by volume and nobody owns the total. And alerts multiply until they are ignored, at which point the platform is generating noise rather than signal — a monitoring system people have learned to dismiss is worse than none.

What an assigned team does with Datadog.

Alert quality decays without an owner. Every incident adds a monitor, nothing ever removes one, and within two years the on-call rota has learned to ignore a channel — which is the worst possible state, because the cost has been paid and the benefit has been lost.

Pruning alerts is a judgement call that needs product context, not just platform knowledge, which is why it works best from inside a standing assignment. It is scoped under DevOps as a service alongside the reliability work it supports.

What we use Datadog for.

• Alerts people still trust Cutting alerts back to those that are actionable, so a page at 3am means something.
• Cutting ingestion cost Log volume and custom metrics reviewed against what is actually queried, which is usually a fraction of what is sent.
• Tracing across services Distributed traces instrumented so a slow request can be attributed rather than guessed at.

How Datadog capacity is assigned.

Observability work is assigned under DevOps managed services, usually as part of a site reliability assignment rather than a tooling project. Every assigned specialist comes through the Talent Success and Academy programme first.