The hypothesis is waiting
when the engineer wakes up.
Datadog Bits Investigation takes a monitor alert as its input, forms hypotheses, pulls the traces, logs, deploys and metrics that test them, and proposes a root cause with the evidence attached. We scope it to the monitors that matter, feed it your runbooks, and under Critical Support our engineer verifies the hypothesis against the data before anyone acts on it. Agents own the analysis. Humans own the outcome.
Quick facts
Related
- Bits AI, the whole family and the guardrails
- Bits Code, the fix proposed from the finding
- Incident Management, where the verified cause becomes the record
The context-gathering, done before the page lands
The alert says latency is up on checkout. The engineer opens the trace, then the deploy history, then the logs for the service two hops down, then the database dashboard. Twenty minutes in, they find the migration that ran at 02:40. Bits Investigation does those twenty minutes when the monitor fires, and attaches the migration to the alert with the evidence that points at it.
Input: the alert, and everything around it. When a scoped monitor fires, the agent reads the monitor query, the service tags, recent deployments, traces, logs, metrics and the knowledge sources you gave it, and starts forming hypotheses.
Output: a root cause, shown with its working. The investigation lists what it suspected, what it checked, what the data showed and what it concluded. The reasoning is visible, so an engineer can disagree with a step rather than with a verdict.
Where the engineer sits: on the verification. The agent proposes. It does not restart, roll back or scale anything. The engineer reads the evidence, confirms or rejects the hypothesis against the data, and decides what happens next. Under Critical Support that engineer is ours.
The hand-off is to another agent or a person. A confirmed code cause can go to Bits Code for a proposed pull request. An infrastructure cause can go to Bits Remediation, behind a guardrail. Or it goes to the incident channel, with the summary and the postmortem draft already written.
Investigating every monitor, with no runbooks loaded, and a summary that gets pasted into the postmortem unread
How it bills. Bits Investigation draws on AI Credits, the meter shared across the Bits AI family. Datadog sells credits on demand or in monthly bundles that reset on the first of each calendar month and do not roll over. Each investigation consumes credits, so the number of monitors scoped for investigation is the lever. Automatic investigations also carry rate limits, per monitor and per organisation, which an administrator can adjust, and administrators can cap credit usage for the organisation and per user. Datadog's documentation at the time of writing does not label Bits Investigation as a Preview. It is reachable through MCP, the Bits AI API and Pup. The follow-on agents, Bits Remediation and Bits Detection, carry Preview labels. We publish no rates. We scope the monitors, which scopes the meter.
The configuration traps. Investigation is enabled for every monitor, including the ones that fire hourly for no reason, and the credits are spent explaining noise. The knowledge sources are empty, so the agent reasons without the runbook that says the queue always backs up during the nightly export. The investigation runs but its output goes nowhere a human looks at 3am, because the Slack or Teams integration was never connected. The hypothesis is confident, well formatted and wrong, and it becomes the postmortem's root cause because nobody owned the step where it was checked. None of these is the agent being bad at its job. It is an agent whose job nobody defined.
Field noteThe most common gap we see is the empty knowledge source. The agent is told nothing about the estate, proposes a plausible generic cause, and the team concludes the agent is not useful. With the runbooks loaded, the same agent proposes the thing the team already half-suspected.
Field noteThe pattern we keep finding is investigation enabled on the noisiest monitors first, because those are the ones that fire during the trial. The organisation's limit on automatic investigations goes on explaining disk alerts that resolve themselves, and is used up before the monitor that matters fires.
Field noteThe investigation summary is good enough to read like a conclusion. It is pasted into the incident timeline, then into the postmortem, and the verification step disappears because the document already has a root cause in it.
Field noteThe integration to the incident channel was never finished. The investigation is on the alert in Datadog, the engineer is in Slack, and the two meet after the engineer has done the twenty minutes by hand.
Scope the monitors. Load the runbooks. Put a named engineer on the verification.
We start with a Datadog HealthScan, read-only and fully automated, which reports the monitors Bits investigates today, the knowledge sources it has, the integrations connected and the credits consumed. The scoping then runs within Managed Observability onboarding, and the verification step is staffed by Critical Support.
- Pick the monitors worth investigating. Paging monitors on services that matter at 2am, and nothing that fires more than it should. A monitor is only scoped for investigation once it has been classified as a real page.
- Load the knowledge sources. Runbooks, architecture notes, known seasonal behaviour and the general organisation context, so the agent's hypotheses are about your estate. This step changes the quality of everything after it.
- Connect the channel the engineer is in. Slack or Microsoft Teams for the investigation output, Jira or ServiceNow for the follow-up, GitHub for the code context. The hypothesis arrives where the person is, with the alert.
- Define the verification step. A written rule: no investigation output enters the incident timeline as a cause until a named engineer has confirmed it against the data. Under Critical Support that engineer is ours, and the confirmation is logged.
- Set the credit budget and its owner. A monthly allotment for investigation with a monitor on consumption and a named owner. An agent that stops mid-month is a budget problem, and it is alerted as one.
- Run it against the last five incidents. The scoped agent is run on the alerts from recent incidents and its hypotheses scored against the known causes. The scoring sets the expectation and the first month's review baseline.
Access is admin on the Datadog organisation for the investigation settings and knowledge sources, plus read access to the runbooks we load. Bits Investigation reads telemetry already in Datadog; we need no access to your code or your cloud accounts to implement it.
An agent is only as good as the last time somebody told it it was wrong
Services change, runbooks go stale, a seasonal pattern the agent was never told about arrives. Managed Observability is the monthly service that scores the agent's hypotheses against what was actually true and feeds the difference back. Critical Support is the engineer on the other side of every verification.
Every month, hypotheses are scored. Each investigation's proposed cause against the cause the postmortem confirmed. Right, partly right, wrong, and why. The score is in the monthly report and decides what changes next.
Scope follows the monitors. When monitors are reclassified in the alert review, the investigation scope moves with them. A new paging monitor on a critical service is added; a monitor downgraded to a ticket is removed.
The knowledge sources are kept current. Runbooks updated after incidents go into the knowledge sources in the same week. The agent that was wrong about the nightly export is told about the nightly export.
The incident is ours, hypothesis and all. Under Critical Support our on-call engineer receives the alert with the investigation attached, verifies it against the data, and takes the fix, 24x7. The agent wrote the first draft. The engineer signs the postmortem.
We operate the stack. You own the product.
We run Bits Investigation inside our own on-call, every night, with the same rule we set for customers: the agent proposes, the engineer verifies, and the record says which was which. An implementation partner switches it on. A managed partner is the engineer who reads the hypothesis at 3am and decides. We are the second kind. The scope, the knowledge sources and the scoring stay in your Datadog, and you can take it 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.
Datadog Bits Investigation, answered plainly
Is Bits Investigation the same as Bits AI SRE?
Yes. Datadog introduced the alert-investigation agent as Bits AI SRE and now names it Bits Investigation in its documentation and navigation. It is the agent that takes a monitor alert, forms and tests hypotheses against telemetry, and proposes a root cause with its evidence. Bits Remediation, in Preview, is the separate agent that acts on what Bits Investigation found.
How is Datadog Bits Investigation billed?
Through AI Credits, the meter shared across the Bits AI agents. Datadog sells credits on demand or in monthly bundles that reset on the first of each calendar month and do not roll over, and each investigation consumes credits. We do not publish prices. The lever is which monitors are scoped for investigation, so we scope the paging monitors on services that matter and set a monthly credit budget with a named owner.
Does Bits Investigation fix anything?
No. It reads the alert, the deploys, the traces, the logs and the knowledge sources you give it, and it proposes a root cause with the evidence and the reasoning visible. Acting on the cause is a separate step: a person, or Bits Remediation behind a guardrail, or Bits Code opening a pull request that a person reviews. Under Critical Support the person who verifies the hypothesis and takes the fix is our on-call engineer.
How accurate is it?
Accurate enough to be worth reading before the engineer opens anything, and not accurate enough to be the postmortem. Its quality depends heavily on the knowledge sources: with runbooks and architecture notes loaded, its hypotheses are about your estate; without them, they are about a generic one. We score every investigation against the confirmed cause each month and feed the misses back, because an agent that is never told it was wrong does not improve.
What does Critical Cloud do with Bits Investigation every month?
Under Managed Observability we score each investigation's hypothesis against the cause the postmortem confirmed. We move the scope when monitors are reclassified, update the knowledge sources with the runbooks that changed, and review credit consumption against the budget. Under Critical Support our on-call engineer receives every scoped alert with the investigation attached, verifies the hypothesis against the data before acting, and takes the fix, 24x7. Agents own the analysis. Humans own the outcome.
- Datadog products: every product, and how we implement and run each one
- Bits AI: the agent family and the guardrails we run it under
- Critical Support: the engineer who verifies the hypothesis and takes the incident
A hypothesis at 3am, and an engineer who checks it.
Tell us which alerts take longest to understand. We will show you what Bits Investigation proposes for them, what it needs to know about your estate first, and who should be checking its work.