AI SRE for Datadog
Sherlocks AI reads the telemetry Datadog already collects and returns a root cause with the evidence attached.
Your metrics, logs and traces already live in Datadog. What is missing is the investigation. When a monitor fires, Watson reads across your Datadog data, correlates it with recent deploys and dependency state, and posts a drafted root cause in Slack. No re-instrumentation. No migration. Your Datadog stays as it is.
sre@prod-bastion ~ $ sherlocks investigate --source datadogSIGNAL SOURCE CORRELATEDerror spike apm traces deploy + log patternp99 regression service map slow downstream callhost saturation infra metrics application rolloutlog error surge logs upstream dependency sre@prod-bastion ~ $ sherlocks connect datadog --read-only
The problem Sherlocks AI solves on top of Datadog
Datadog tells you something is wrong. It does not tell you why.
A monitor fires at 3 AM. The on-call engineer opens Datadog, pulls up the service dashboard, cross-references APM traces, scans logs, checks deploy events, walks the service map to look for a slow dependency. Forty minutes later they land on a cause. The fix takes two.
Watson runs that investigation for you the moment the monitor fires.
How teams use Sherlocks AI with Datadog
(03 Steps)- 1Step 1: Connect Watson to Datadog.
Provide a Datadog API key and application key with read-only scope. No agent to deploy, no monitor to rewrite.
- 2Step 2: Route your Datadog alerts to Watson.
Sherlocks AI monitors your Slack workspace for incident conversations, questions and alerts, so the monitors your team already routes to Slack are where an investigation starts.
- 3Step 3: Get a drafted root cause in Slack.
Within minutes, Watson posts findings with the specific service, endpoint, deploy window or dependency that caused the regression, with a confidence level and the evidence linked. Engineers ask follow-up questions in the same thread.
What Watson investigates across Datadog
(04 Scenarios)The incident shapes Datadog monitors fire on most, with the site's own RCA guide and the Datadog documentation for each. The 21 published investigations show the same method worked end to end from other alert sources.
- 01
Service error spikes
5xx rate above threshold · Error rate by endpoint · Errors after a deploy
Watson correlates APM trace errors with recent deploys, log patterns and dependency health. It names the service, the endpoint and the deploy that caused the regression, instead of the dashboard that noticed it.
Guide: How to fix a CrashLoopBackOffDatadog docs: APM
- 02
Latency regressions
p95 or p99 breach · Slow endpoint · Dependency timeout
Watson reads APM percentiles across the incident window, walks the service map to find the slow dependency, and correlates with deploys or infrastructure changes in the same window.
Guide: How to debug a slow query after a migrationDatadog docs: Service Map
- 03
Infrastructure incidents
Host CPU or memory saturation · Container restarts · Pod pressure
Watson correlates host, container and pod metrics with application signals to explain whether the symptom is infrastructure-driven or application-driven, which decides who gets paged next.
Guide: How to debug a JVM memory leak and OOM killDatadog docs: Infrastructure Monitoring
- 04
Dependency failures
Downstream call failing · Retry storm · Cascading timeouts
Watson reads the service map and APM spans to find which downstream call is failing, and whether that failure is the root cause or a symptom of something further upstream.
Guide: How to debug connection pool exhaustionDatadog docs: Trace Explorer
What Watson reads from Datadog
(04 Sources)Infrastructure and custom metrics across every Datadog integration you run.
Log search across the incident window, for the patterns that line up with the alert.
Traces, service dependencies and span-level detail.
What you already track, so Watson reasons about the signals your team watches.
Read-only. Watson uses a Datadog API key with a read-scoped application key. It does not push metrics, change monitor state or modify your Datadog configuration.
Running Prometheus and Grafana next to Datadog? The Prometheus and Grafana page covers that side, and the Kubernetes page covers what Watson reads from inside the cluster.
Deployment: your compliance posture, not ours
(02 Models)Watson runs in the Sherlocks AI cloud and reads from Datadog over its API. Zero infrastructure footprint on your side.
For regulated workloads, Watson runs inside your network and only aggregated metrics and metadata leave it, or nothing at all with the self-hosted deployment.
What changes after Sherlocks AI
Investigation starts the moment the alert lands, not when the engineer opens their laptop.
The on-call engineer wakes up to a drafted root cause, not a dashboard spiral. Escalations drop because the first question is already answered.
Every claim in the RCA cites the logs, metrics or traces it rests on, and the hypotheses that were ruled out are listed. Postmortems start from the evidence.
Architected for compliance scrutiny
All permissions are read-only. Sherlocks AI cannot push metrics, change monitor state or modify your Datadog configuration.
Sherlocks AI collects only metadata and metrics: never raw application data, PII or secrets.
In-VPC deployments route LLM calls through your own AWS Bedrock or Azure OpenAI tenant, so no data leaves your account.
Sherlocks AI cloud environment is annually audited against the SOC 2 Type 2 framework.
Frequently asked questions
(08 Questions)What permissions does the Datadog API key need?
Read-only access. Sherlocks AI uses a Datadog API key and application key with read scopes only. No write scopes are required or used, so it cannot change monitors, push metrics or alter your configuration.
How is this different from Datadog Bits AI?
Bits AI is Datadog's own agentic assistant. It lives inside Datadog and investigates with the data Datadog holds. Sherlocks AI reads from Datadog and from the rest of your stack, GitHub, Kubernetes, your databases and your cloud APIs, and posts the investigation into Slack with the evidence trail. The two can run side by side; the comparison page below goes through the differences in detail.
Does it replace Datadog?
No. Datadog stays your source of truth for metrics, logs and traces. Sherlocks AI sits on top of it and reads what it already collects. Nothing needs re-instrumenting and no telemetry has to move.
How does a Datadog alert become an investigation?
Sherlocks AI monitors your Slack workspace for incident conversations, questions and alerts, so the Datadog monitors your team already routes to Slack are where an investigation starts. It can also be triggered manually or proactively.
What if we are half-migrated to Datadog from another APM?
Watson reads from Datadog and from other APM sources, New Relic, Elastic, Sentry and SigNoz, in the same investigation. You do not need a clean cutover before it adds value.
Where does the LLM processing happen?
It depends on the deployment. SaaS routes through the Sherlocks AI cloud. In-VPC deployments route LLM calls through your own AWS Bedrock or Azure OpenAI tenant, so no data leaves your account.
Do my raw logs and traces leave my network?
Sherlocks AI collects only metadata and metrics, never raw application data, PII or secrets. Only aggregated metrics and metadata are sent to the Sherlocks AI platform, and with the self-hosted deployment nothing leaves your environment.
How do I know whether to trust a root cause?
Every root cause comes with a confidence level, and every claim cites its source: the logs, metrics, traces or commits it rests on, with links back into Datadog. The hypotheses that were checked and ruled out are listed too.
Ready to see Watson investigate across your Datadog?
Connect your Datadog and watch Watson draft your next incident. Start free with 30 investigations per month, or book a 30-minute demo on your own Datadog setup.
Questions? Get in touch.
Sherlocks AI is used by Fynd, Topmate, Wafeq, TradeIndia, and Lokal to investigate production incidents. SOC 2 Type 2 certified. Watson runs read-only.