Every team uses the platform.
Somebody has to read the whole of it.
Datadog Governance Console shows usage, adoption and configuration drift across a multi-team Datadog account, with controls that detect, notify and enforce: unscoped keys, unused dashboards, indexes at quota, monitors with broken handles. It is available on the Enterprise plan. We configure the controls, decide what is enforced, and run them every month.
Quick facts
Related
- Access Control, the roles and keys the security controls check
- Cloud Cost Management, the cloud bill beside the Datadog usage
- Audit Trail, who made the change the control detected
The whole organisation on one page, with the drift named
One Datadog organisation, many teams, no single owner. Each team's corner is tidy by its own standards. Between the corners sit the dashboards nobody views, the keys nobody scoped, the log index that hit its quota every night, and the monitors that notify a handle that no longer exists. The Governance Console reads the whole and lists them.
Usage and adoption, by product. Which products each team uses, how far from their limits and quotas, and where adoption stalled after the licence was bought.
Controls that detect drift. Leaked, unused and unscoped keys. Roles with no users. Unqueried metrics and inactive metric tags. Indexes at quota. Dashboards, monitors and notebooks with no team tag. Downtimes with no end.
Notification to the accountable person. Each control notifies the people responsible on a cadence, with a summary of what is unresolved, so the drift reaches the team that can fix it rather than a central inbox.
Enforcement, when it is earned. Off by default. For the controls where the fix is safe, an automated action or a Workflow, with a remediation delay so the owner can object first.
An Enterprise feature that notifies the wrong person, controls scoped per organisation, and an enforce toggle that is either too brave or never used
How it bills. The Governance Console is not metered on its own. Datadog's pricing page lists it as part of the Infrastructure Enterprise plan, and access to it is controlled by the Governance Console Read permission. The lever is not cost. It is which controls are on, who is notified, and what is enforced.
The configuration traps. The console is per organisation. Control behaviour and scope do not span organisations, so an estate with a parent and several child organisations configures the controls in each and reads several summaries. Notifications go to whoever was named when the control was set up, which is the person who set it up, so the cost controls report to someone with no budget. Enforcement is a toggle: on for a control that deletes unused dashboards, it deletes the board report that is viewed once a quarter. Left off everywhere, the console is a report that nobody acts on.
Field noteThe most common gap we see is the control with no accountable recipient. It detects every month, notifies the engineer who enabled it, and the drift it reports is in a team that engineer has never met.
Field noteThe pattern we keep finding is enforcement switched on for the unused-dashboards control at the default threshold, and a dashboard that is read once a quarter removed in the first run. The toggle is turned off for every control afterwards.
Field noteThe console runs in the production organisation only. The sandbox organisation, where keys are created freely and never scoped, has none of the controls and most of the exposure.
Field noteThe index quota control fires every night for the same index. The quota is raised each time it is reached, because raising it is the automated action, and the question of why the index grows is never asked.
Recipients first. Thresholds second. Enforcement last, and only where the fix is safe.
We start with a Datadog HealthScan. It is read-only and fully automated, and it reports what the console would detect before it is on: dashboards unviewed, keys unscoped, monitors with broken handles, indexes at quota, downtimes without an end. The first conversation with each team is then about real objects. Then the sequence is deliberately slow.
- Grant access to the console. On each organisation in the estate, with the Governance Console Read permission granted to a role rather than to individuals.
- Name the recipients. For each control, the team or role accountable for the drift it detects: security controls to security, cost controls to the budget holder.
- Set the thresholds. Unused-dashboard, inactive-key and persistent-alert thresholds from the estate's real rhythm, including the quarterly reports and the annual keys.
- Run detection only for a cycle. Every control on, nothing enforced, the detections reviewed with the recipients so the false positives are known before anything is automated.
- Enforce where it is safe. Revoking keys unused for a long period, closing downtimes with no end, mitigated by a Workflow with a remediation delay. Deleting dashboards stays manual.
- Hand over, in writing. Which controls are on, their thresholds, their recipients, what is enforced and why, and the detections open on the day we finished.
Access is the governance console read permission on each organisation plus the product permissions the enforced controls need, held by a role we document. We do not enforce anything we did not run in detection first.
A control that nobody reads is a report. A control with an owner is governance.
Teams split. Budget holders change. A new organisation is added to the estate with none of the controls. Managed Observability reads the detections every month with the people they affect and keeps the configuration matching the organisation.
Every month, the detections are reviewed. Open detections per control, who was notified, and which ones were mitigated, delayed or ignored, with the reasons recorded.
Recipients follow the organisation. A team that split, a budget holder who changed, or a new organisation added to the estate is reflected in the control configuration before the next notification goes to the wrong person.
Thresholds are kept honest. A control that fires every cycle on the same object is a threshold problem or a real problem. Each gets named and resolved rather than mitigated again.
Enforcement earns its place. A control that ran in detection for a cycle without a false positive is a candidate for enforcement. A control that caused one is pulled back to detection until it is understood.
We operate the stack. You own the product.
The Governance Console is a list of things that drifted. Governance is the practice of reading the list, with the right people, every month, and deciding what to do about each line. We run that practice as part of Managed Observability. The controls, the recipients and the decisions live in your Datadog organisation, and you can take the practice 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 Governance Console, answered plainly
How is the Datadog Governance Console billed?
It is not metered on its own. Datadog's pricing page lists the Governance Console as part of the Infrastructure Enterprise plan. We do not publish prices. What we configure is which controls are on, who they notify, and which are enforced.
What does the Datadog Governance Console detect?
Its controls fall into three groups. Security: leaked, unused and unscoped keys, roles with no users, users in no team. Cost optimisation: unqueried metrics, inactive metric tags, metric cardinality spikes, log indexes hitting their daily quota, Synthetic tests with muted monitors. Data hygiene: dashboards, monitors and notebooks without team tags, unused dashboards, downtimes with no end, monitors with broken notification handles, persistent alerts, inactive log pipelines and empty indexes. Datadog adds controls over time.
Does the Governance Console work across multiple Datadog organisations?
It is designed for multi-team accounts, but control behaviour and scope are defined per organisation and do not span organisations. An estate with a parent and several child organisations configures the controls in each and reads each summary. We treat that as a configuration task repeated per organisation, with the same recipients and thresholds where they apply.
Should we turn on enforcement?
Only after a control has run in detection for a cycle and the detections have been reviewed with the people they affect. Enforcement is off by default, and each control's automated action is specific: revoking a key, deleting a dashboard. Some of those are safe with a remediation delay. Some, such as deleting dashboards, are better kept manual. We decide per control and write the reason down.
What does Critical Cloud do with the Governance Console every month?
Managed Observability reviews the open detections per control with the accountable recipients and records what was mitigated, delayed or ignored, and why. It updates recipients and thresholds as the organisation changes. It promotes controls to enforcement when they have earned it, pulls them back when they have not, and reports what changed.
- Datadog products: every product, and how we implement and run each one
- Access Control: the roles, keys and sign-on the security controls check
- Datadog Cloud Cost Management: the cloud bill next to the telemetry that explains it
- Audit Trail: who made the change a control detected, kept as evidence
- Datadog cost management guides: the usage the Summary page reports, and how to reduce it
The whole platform, read monthly, by somebody who owns the reading.
Tell us how many teams share the organisation. We will show you what the Governance Console would list on day one, and what it takes to make each line somebody's.