Every service has an owner.
Now the alert knows it too.
Datadog Teams puts an owner on each service, monitor, dashboard and SLO, and routes the notification to that team's channel. It is a small feature that most of the platform depends on. We implement it from the organisation as it is, and keep it true as the organisation changes.
Quick facts
Related
- Software Catalog, where service ownership is recorded
- Incident Management, the rota the handle pages
- Access Control, the roles built around the same teams
Ownership that the platform can act on
Somebody owns the payments service. Everybody knows who. It is not written anywhere Datadog can read, so the monitor notifies a channel, the channel has every engineer in it, and the person who owns the service finds out from a colleague. Teams writes the ownership down where the platform uses it.
A handle that is also a tag. A team's handle appears as a tag on dashboards, monitors, SLOs, incidents and Catalog entries, so ownership is searchable and the team filter shows a team its own estate by default.
Routing that follows the handle. A monitor that notifies the team handle is redirected to that team's Slack or Microsoft Teams channel. The routing changes when the team changes, not when somebody edits every monitor.
Membership from the identity provider. Teams can be synced from SAML groups, strictly or with manual additions, so the team in Datadog is the team in the directory.
Governance that can see the gaps. Monitors, dashboards and services without a team tag are a Governance Console control, so the unowned things are a list rather than a suspicion.
A free feature with no owner, handles that are typos, and a team that still exists in Datadog after it was dissolved
How it bills. Teams is not metered. Datadog lists it among the platform's built-in features, its pricing list carries no meter for it, and a monitor, dashboard or service tagged with a team handle is billed no differently for it. The cost of not using it is the alert that reaches nobody.
The configuration traps. A team handle that is not attached to a defined team behaves as a plain tag, so a handle typed slightly differently on one monitor routes nowhere and looks like it routes somewhere. Teams created by hand drift from the organisation chart within a quarter. Membership managed in the UI and in SAML at once produces a team whose members depend on which source wrote last. A team with no notification channel is a label: Datadog has no channel to redirect its handle's alerts to.
Field noteThe most common gap we see is the team handle with three spellings. The monitors that use the right one reach the team's channel. The rest use a handle that matches no defined team, which Datadog treats as a plain tag: it looks like ownership and routes nowhere.
Field noteThe pattern we keep finding is a team structure created on the rollout day and never touched. Teams were renamed, merged and split in the organisation. In Datadog, the originals still own the services.
Field noteServices have team tags in the Catalog, and the monitors for the same services do not. The service page shows an owner. The alert for it goes to the shared channel.
Field noteTeam provisioning is switched to SAML strict after the teams were built by hand. Datadog removes every member the identity provider does not list, and the engineers added through the UI drop out of their teams the same afternoon.
Start from the organisation chart. Then tag everything. Then route.
We start with a Datadog HealthScan. It is read-only and fully automated. Before anything changes, it reports the teams and their members, the handles in use that match no team, the monitors and services without a team tag, and the teams without a channel. Then the sequence is short.
- Agree the teams. From the organisation as it is, not as the last rollout left it, with subteams where the structure has them and a manager for each.
- Choose the membership source. SAML strict where the identity provider is the truth, all sources where manual additions are needed, and never both without a decision written down.
- Attach the channels. Each team's Slack or Microsoft Teams channel, and its On-Call schedule where one exists, so the handle routes somewhere from day one.
- Tag the estate. Services in the Catalog, then monitors, dashboards, SLOs and Synthetic tests, by team, with the handles that match no team corrected.
- Rewrite the notifications. Monitors that name a channel or a person are changed to name the team handle, so the routing follows the team rather than the monitor.
- Hand over, in writing. The team list, the membership source, the channel map, and the count of untagged assets on the day we finished.
Access is the Teams Manage and User Access Manage permissions, plus write access to the monitors, dashboards, SLOs and Synthetic tests we tag. Where SAML sync is used, we also need the identity provider's group names. We do not need access to the identity provider itself, and we do not ask for it.
Teams change every quarter. The tags do not change themselves.
A team is renamed. A channel is archived. A new service ships with no owner. Managed Observability reconciles the teams in Datadog with the organisation every month, so the handle on the monitor still means somebody.
Every month, the handles are reconciled. Teams in Datadog against the organisation, handles in use against teams that exist, and members against the identity provider where sync is on.
Coverage follows the estate. New services, monitors and dashboards without a team tag are listed from the Governance Console control and tagged with the owner before their first alert.
Routing is kept honest. Teams without a channel, channels that were archived, and On-Call schedules that no longer match the team are corrected before the page that needs them.
The incident is ours to take. Under Critical Support our engineers are on the rota the team handle routes to, 24x7, and the owning team is informed by the same handle rather than found by hand.
We operate the stack. You own the product.
Teams is the smallest configuration on the platform and the one the most things depend on. We implement it from the organisation as it is and reconcile it every month, because the organisation will not stay as it is. The teams, the handles and the routing live in your Datadog organisation, and you can take them 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 Teams, answered plainly
How is Datadog Teams billed?
It is not metered. Datadog lists Teams among the platform's built-in features and its pricing list carries no meter for it, and tagging a monitor, dashboard or service with a team handle does not change how any of them is billed. We do not publish prices. The work is in the mapping and the monthly reconciliation, not on the invoice.
What can be assigned to a Datadog team?
Dashboards, monitors, Service Level Objectives, incidents, Synthetic tests and their global variables and private locations, and entities in the Catalog, including services. The team handle acts as a tag on each, and the team filter uses those tags to scope list pages and dashboards to the teams you select.
How does Datadog route an alert to a team?
A monitor notifies the team handle, written as the handle with the team prefix. When the team has a notification channel configured, Slack or Microsoft Teams, the notification is redirected there. If the handle matches no defined team, it behaves as a plain tag and routes nowhere, which is why every handle in use is checked against the team list.
Can Datadog Teams sync with our identity provider?
Yes. Team membership can come from SAML group attributes in two modes. In strict mode the identity provider decides membership and manual changes are removed. With the All sources option SAML provides the starting point and additions through the UI or API are kept. The choice is per organisation and needs to be made deliberately, because the two sources will otherwise disagree.
What does Critical Cloud do with Teams every month?
Managed Observability reconciles the teams in Datadog with the organisation and the identity provider. It corrects handles that match no team and tags the new monitors, dashboards and services that arrived without an owner. It confirms each team still has a working notification channel, and reports what changed. Under Critical Support our engineers sit on the rota the handle routes to, 24x7.
- Datadog products: every product, and how we implement and run each one
- Software Catalog: every service, its owner and its dependencies
- Incident Management: the rota the team handle pages, staffed by us
- Datadog HealthScan: teams, handles and unowned monitors reported before anything changes
Every service owned. Every alert routed to its owner.
Tell us how the teams are organised today. We will show you what Datadog thinks the teams are, where they differ, and what it takes to make the alert reach the right one.