Ask the estate a question.
Get an answer you were allowed to see.
Datadog Bits Chat takes a question in plain language as its input, "why is checkout slow since the deploy?", and answers from the metrics, logs, traces, monitors and dashboards the asker has permission to view. It can build a dashboard or write a DDSQL query on request. We set it up so the answer is scoped by role, informed by your runbooks, and reviewed each month for what it was asked and what changed as a result. Agents own the analysis. Humans own the outcome.
Quick facts
Related
- Bits AI, the whole family and the guardrails
- Bits Investigation, when the question is an alert
- Access Control, the roles that scope the answer
The dashboard you could not find, answered instead
A product manager wants to know whether the release slowed the mobile checkout. The dashboard that answers it exists. It is called "svc-overview-v3 (copy)" and it was built by someone who left. Bits Chat takes the question, finds the service, reads the latency metrics before and after the deploy, and answers, with the graph, in the channel where the question was asked.
Input: a question, with the asker's permissions attached. Bits Chat uses the Datadog role of the person asking. It can only read what they can read and only edit what they can edit, so the answer is scoped before the question is understood.
Output: an answer with the data behind it. A summary, the graph or log lines it drew on, a DDSQL query it wrote, or a dashboard it built. The working is shown, so the person can check the query rather than trust the sentence.
Where the person sits: on every change. Bits Chat can build a dashboard and, with edit permission, change one. The person asked for it, sees it, and keeps or discards it. Nothing in the runtime moves because of a chat.
Available where people already are. The Datadog web app, the mobile app, Slack and Microsoft Teams. The question that used to be posted to the platform channel can be asked of the data directly, by the person who has it.
A role that sees everything, no context about the estate, and a dashboard built by chat that nobody records
How it bills. Bits Chat draws on AI Credits, the meter shared across the Bits AI family. Datadog sells credits on demand or in monthly bundles. Bundle credits reset on the first of each calendar month and do not roll over, and usage above the bundle is billed at the on-demand rate. Each chat message consumes credits, so the number of people with the Bits Chat Access permission, and what they ask, is the lever. Administrators can cap credit usage for the organisation and per user. Datadog announced Bits Chat as generally available and we confirm that status at the start of each engagement. We publish no rates.
The configuration traps. The Bits Chat Access permission is on by default for the standard roles, which is fine, and the standard roles can see everything, which is the actual problem. Nobody set up the knowledge sources, so the chat does not know that the nightly export always spikes the queue, and it reports the spike as a finding every morning. Dashboards built in chat are kept, duplicated, and never named, so the dashboard list grows by the day. Log restriction queries were never written, so the answer to a question about a customer includes the customer's data. None of these is the chat being wrong. It is the chat answering within a scope nobody drew.
Field noteThe most common gap we see is the role, not the chat. Bits Chat respects permissions exactly, and the permissions were set for a small platform team who all needed everything. When the whole company gets the chat, they get the platform team's view.
Field noteThe pattern we keep finding is the dashboard sprawl that chat accelerates. A dashboard now takes one sentence to build, each one is kept in case, and the list that was hard to search is now impossible.
Field noteNobody has written a skill in the Skills Library, so the chat describes the estate accurately and without context. It reports the nightly export as an anomaly, correctly, every night, to a different person each time.
Field noteThe useful questions turn out to be the boring ones. "Which services have no owner?", "which monitors have not fired this quarter?", "what changed on this host yesterday?". The teams that get value from chat are the ones who ask it the questions nobody wanted to build a dashboard for.
Fix the roles first. Then give the chat something to know. Then open it up.
We start with a Datadog HealthScan, read-only and fully automated, which reports who holds the Bits Chat Access permission, what each role can see, which knowledge sources exist and what credits have been consumed. The setup then runs within Managed Observability onboarding.
- Review the roles the chat inherits. Bits Chat sees what the asker sees, so the roles are the scope. Data Access Control and log restriction queries are set so a question about a customer does not return the customer's data to everyone.
- Decide who gets the permission. The Bits Chat Access permission is granted to the roles that should ask questions, and removed from the ones that should not. Default-on is a starting point, not a decision.
- Load the knowledge sources. The runbooks, the architecture notes and the known seasonal behaviour go into the knowledge sources and the Skills Library. The answer about the nightly export then says it is the nightly export.
- Connect Slack or Teams. The chat is available where the questions already get asked, so the platform channel stops being the search engine.
- Set a dashboard rule. Dashboards built in chat are either named and owned within a week or deleted. The rule is written down and the monthly review enforces it.
- Set the credit budget and hand over. A monthly allotment for chat, a monitor on consumption and a named owner. The role map, the permission list and the knowledge sources are documented.
Access is admin on the Datadog organisation for roles, permissions and knowledge sources. We do not need access to your code or your cloud accounts; Bits Chat reads only what is already in Datadog, and only what the person asking is allowed to read.
The questions people ask are a list of the dashboards nobody has built yet
New people join and get a role that was designed for someone else. A runbook changes and the chat still gives the old answer. Managed Observability is the monthly service that reviews what was asked, what was answered and what the permissions let through.
Every month, the questions are read. The recurring ones become dashboards or monitors with an owner. The ones that returned wrong answers become knowledge-source fixes. The ones nobody should have been able to ask become role changes.
Permissions follow the org chart. When teams change, the roles the chat inherits are checked against who should see what, and Data Access Control is updated in the same week.
The knowledge sources are kept honest. Runbooks changed after incidents go into the knowledge sources, so the chat's answer about the queue matches what the on-call engineer knows about the queue.
Chat is a question. Action is an incident. When a question reveals something that needs fixing in the runtime we operate, it becomes a work item or an incident, and under Critical Support our engineer takes it. The chat does not act. People do.
We operate the stack. You own the product.
A natural-language interface to the telemetry is as safe as the permissions underneath it and as useful as the context loaded into it. An implementation partner switches it on and leaves. A managed partner reads what was asked every month and fixes the roles, the knowledge and the dashboards the questions point at. We are the second kind. The roles, the knowledge sources and the record 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 Chat, answered plainly
Can Bits Chat see data the person asking cannot?
No. Bits Chat uses the Datadog role of the person asking to fetch data, so it can only access the resources that person has permission to view or modify. It can edit a dashboard only if the asker has edit permission on it. Using the chat at all requires the Bits Chat Access permission, which Datadog enables by default for the Admin, Standard and Read Only roles. The scope of an answer is therefore the scope of the role, which is why we review the roles before we open the chat up.
How is Datadog Bits Chat billed?
Through AI Credits, the meter shared across the Bits AI agents. Datadog sells credits on demand or in monthly bundles. Bundle credits reset on the first of each calendar month and do not roll over. Each chat message consumes credits, and administrators can cap credit usage for the organisation and per user. We do not publish prices. We decide which roles hold the Bits Chat Access permission, set a monthly credit budget with a named owner, and monitor consumption so the chat does not go quiet mid-month.
What can Bits Chat actually do, beyond answering?
It can build a dashboard from a description, edit an existing one where the asker has permission, write and run DDSQL queries, summarise dashboards and explore telemetry, and investigate an incident conversationally. It runs in the Datadog web app, the mobile app, Slack and Microsoft Teams. It does not change your runtime: nothing is restarted, scaled or deployed because of a chat. Action is a separate step taken by a person, or by another agent behind a guardrail.
Will it know about our systems, or just about Datadog?
Only what it is told. Out of the box it reasons from the telemetry and the Datadog documentation. With knowledge sources and the Skills Library filled in, it also knows your runbooks, your architecture notes and the seasonal patterns your on-call engineers know. The answer about the nightly spike then says it is the nightly export rather than reporting an anomaly. Loading that context is most of the implementation work.
What does Critical Cloud do with Bits Chat every month?
Under Managed Observability we review the questions asked: recurring ones become owned dashboards or monitors, wrong answers become knowledge-source fixes, and questions that should not have been answerable become role changes. We check the roles the chat inherits against the current org chart, update the knowledge sources with changed runbooks, and review credit consumption against the budget. Where a question reveals something that needs fixing in the runtime we operate, it becomes a work item and under Critical Support our engineer takes it.
- Datadog products: every product, and how we implement and run each one
- Bits AI: the agent family and the guardrails we run it under
- MCP Server: the same questions, asked from your own assistant
- Managed Observability: the monthly service that reviews the roles and the knowledge
A question answered within the permission to ask it.
Tell us the three questions your platform channel answers every week. We will show you what Bits Chat answers for them, what it needs to know first, and which roles should be allowed to ask.