Software Catalog
A feature that gathers the services Datadog observes into a single registry and ties owners, dependencies, and documents to them. Formerly called Service Catalog. It consists of two layers: a list that grows automatically from observability data, and information that people add through definition files.
What it does
Automatically lists the services and frontend apps discovered from telemetry such as APM, USM, and RUM, and lets you add the owning team, contacts, dependencies, and documentation links through YAML definition files. The same registry is queried from the reliability, performance, security, and cost views, and you can follow it through the dependency graph down to the infrastructure it runs on.
When to use it
When services exceed 100 and "whose is this?" becomes a problem at every incident. When you want to eliminate the time spent hunting for the on-call contact or runbook link during incident response. When you want to connect a registry that already exists in Backstage or ServiceNow with Datadog's observability data. When you want to check production readiness and gaps in observability configuration organization-wide with scorecards.
An everyday analogy
It is close to a municipal resident registry. Services discovered through observation are entered automatically, like a change-of-address notification, and the head of household (owning team) and contacts are filled in through declarations (definition files). You can tell automatically who lives there, but you cannot tell who is responsible without a declaration. That two-layer relationship applies exactly.
The catalog has two layers - a list that grows automatically and definitions that people write
Once services exceed a few dozen, every incident creates time spent going around asking people "who owns this and what does it depend on?" Datadog's Software Catalog is the registry that answers this question, and the official documentation organizes it as the "Catalog" of the Internal Developer Portal (IDP) (as of September 2026, source: Catalog). There are three ways an item gets into the registry: when Datadog detects it from telemetry, when a user declares it in a definition file (Entity Definition), and when it is imported from outside, such as Backstage or ServiceNow. In other words, it is a two-layer structure of "a layer that grows automatically from observability data" and "a layer that people add to," where the former provides coverage and the latter carries information that does not come out of observation, such as owners and documents. If you know this division, you understand that "we added it but the owner is blank" is by design, and filling it in is the job of the definition file.
| Entry point | What goes in | Who acts |
|---|---|---|
| Automatic detection from telemetry | Services and frontend apps found by APM / USM / RUM. Import from logs and host metrics is also possible | Datadog (automatic) |
| Definition file (Entity Definition) | Metadata such as owning team, contacts, dependencies, and documentation links | Users (UI / Git / automation) |
| Import from outside | Backstage entities, ServiceNow CMDB configuration items | Users (plugin / API / scheduled sync) |
What enters automatically is the services found by APM, USM, and RUM
By default, three things fill the registry: APM, Universal Service Monitoring (USM), and RUM. APM draws services and dependencies from the traces of instrumented apps, USM detects request counts / errors / durations with eBPF without touching code and connects dependencies, and RUM apps are listed as frontend apps (as of September 2026, source: Set Up Catalog). You can also import from logs and from host / container / network / process metrics, but this works by searching for the DD_SERVICE tag, and the official documentation cautions to limit it to cases where tags are well maintained. If tag values are not consistent, the same service appears as two rows under different names. Each service is assigned a type determined from span.type (Web / DB / Cache / Serverless function / Custom), which becomes an axis for filtering.
What do you write in the definition file?
The vessel for the layer that people add is the definition file, written in Kubernetes-style YAML and positioned as the source of truth for the registry (as of September 2026, source: Set Up Catalog). The schema has four versions, v3.0 / v2.2 / v2.1 / v2.0, and v3.0 can handle multiple kinds such as systems / queues / datastores and supports ownership by multiple teams and manual declaration of dependencies (same point in time, source: Entity Model). There is one key point: make the definition's name match the service tag of Unified Service Tagging exactly. If they do not match, the observability data and the definition are not linked. There are three registration routes: the UI, placing the file in Git and syncing through the source code integration (changes are reflected within minutes), and automation. Keeping the definition file in the service's repository and updating it through review is the way to keep owner information from going stale.
What you see on the catalog screen
The registry is not just a tool for browsing a list. The official documentation lists eight catalog views: Ownership / Reliability / Performance / Security / Costs / Software Delivery / Relationships / Infrastructure (as of September 2026, source: Catalog).
| View | Question it answers |
|---|---|
| Ownership | Where are the owning team's Slack, repository, and on-call information? |
| Reliability | Which services have a recent deployment, a rise in error rate, an ongoing incident, or a failing monitor? |
| Performance | Comparison of latency, traffic, error rate, and Apdex per environment |
| Security | Which services carry vulnerable libraries and ongoing attacks? |
| Costs | AWS cost trends tied to code and infrastructure changes |
| Software Delivery | CI pipeline health, static analysis violations, DORA metrics |
| Relationships | The dependency graph between services and the infrastructure resources each service runs on |
| Infrastructure | A list of cloud infrastructure resources and links to the software running on them |
The significance of being able to query the same registry from eight angles is that one roster serves both incident response and organizational management. From a service in the dependency graph you can move directly to the infrastructure resources it runs on, and the documentation states explicitly that collecting infrastructure resources is free for Infrastructure Monitoring customers. Dashboards have a "Developer Portal" data source, and you can place widgets that aggregate entity counts by owner or tier.
How its role differs from the APM service page
Selecting a single service in the catalog takes you to the APM service page. The official documentation defines a service as "a set of processes that do the same job" and explains that the service page lines up service health, monitor status, Watchdog insights, dependencies, the resource list, deployments, and more (as of September 2026, source: Service Page). Service health consolidates signals from monitors, incidents, and Watchdog into a single state (Critical / Warning / Ok). The difference in role is the time axis. The service page answers "how is this service doing right now," and the catalog answers "what is this service, whose is it, and what does it depend on." In incident response, you go back and forth: get the contact from Ownership and look at the symptoms on the service page. The span summaries and service statistics shown in the catalog are retained for up to 30 days, and analysis over a longer period is assumed to be done on the Metrics side (same point in time, source: Catalog).
Where Backstage, ServiceNow, and Scorecards fit
Registries in Backstage or the ServiceNow CMDB can be used without rebuilding them. Backstage syncs in two ways, through a plugin or by importing descriptor files (API / Terraform / GitHub), and ServiceNow syncs by periodically querying CI tables (as of September 2026, source: Set Up Catalog). The value lies in observability data being attached to each row. Sitting on top of the catalog are Scorecards, with three default sets, Production Readiness / Observability Best Practices / Documentation & Ownership, which evaluate all entities as pass or fail every 24 hours and can deliver results to Slack (same point in time, source: Scorecards). You can produce the number of services with no owner filled in every day. The IDP as a whole has four components: the catalog, scorecards, self-service actions, and engineering reports (same point in time, source: IDP).
How to view pricing - there is no standalone unit price in the public table
Software Catalog has no independent SKU listed on the official pricing page as of August 2026. This article does not give a unit price and defers confirmation to the public price table at Datadog Pricing. There are two points to keep in mind. One is that the material that automatically fills the registry is telemetry from APM / USM / RUM, and the billing of each of those products is the foundation. The other is that the official documentation states explicitly that collecting the infrastructure resources used in the Relationships and Infrastructure views is free for Infrastructure Monitoring customers (as of September 2026, source: Catalog). Cost effectiveness is measured not by "whether to buy a new SKU" but by how much of the APM and Infrastructure Monitoring data you already pay for you can put to use as a registry. For how to read the accumulation per SKU, see how to read the pricing structure. This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page.
The three-step operating order for eliminating services with unknown owners
Just adding the catalog does not reduce "unknown owner." It goes down when you build operations in the following order.
- 1. Settle the tag conventions - align the values of
servicewith Unified Service Tagging, and first create a state where the same service does not appear as two rows under different names - 2. Fill in owners with definition files - keep the YAML in the service's repository, write the team and contacts, and count the blanks every day with the Documentation & Ownership scorecard
- 3. Route notifications to owners - tie monitor notification targets and on-call information to Ownership, so nobody has to search for "who to call" during an incident
Reversing the order breaks it. Even if you write the definition files first, they will not link unless the service values on the telemetry side are consistent, and you end up with rows that have an owner but no observability data alongside rows that have observability data but no owner. Not skipping step 1 is the cheapest improvement this product offers. Once all three steps are running, ownership of SLOs and production readiness checks can be organized on the premise that "every service has a responsible person," and the registry turns from a list into the foundation of operations. Without it, the first 10 minutes of an incident disappear into "who do we ask," and with it, the contact and runbook open in the first minute. That is where the catalog pays off.
Things to watch out for
- This article is based on the official documentation as of September 2026. The composition of views / the definition schema version / the method of external integration can change, so when adopting, give priority to the official documentation.
- This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page. Because no standalone unit price for Software Catalog is listed on the official pricing page as of August 2026, this article does not show a figure.
- The official documentation URLs for the former name Service Catalog / Software Catalog redirect to internal_developer_portal/catalog/ (as of September 2026). Searching under the former name reaches the same page.