Software Catalog

Overview

Software Catalog provides a centralized, dynamic view of your software ecosystem, enabling teams to track ownership, monitor performance, manage dependencies, and enforce security and compliance standards—all in one place.

Built on real-time telemetry and automated metadata collection, Software Catalog extends beyond traditional software catalogs by offering integrations with observability, security, and cost management tools. It empowers engineering, SRE, security, and platform teams to maintain visibility, streamline operations, and ensure service reliability at scale.

Opt in to the preview for our Internal Developer Portal!

Request Access

Use cases

Governance and optimization

  • Providing engineering leadership with a high-level view of best practices across teams and services through Service Scorecards.
  • Reducing application risks by finding and fixing known security vulnerabilities in the dependencies of your services.
  • Understanding trends and identifying inefficiencies in the costs related to your services.

Evaluate monitoring coverage

  • Detecting which services aren’t reporting observability data or having that data monitored.
  • Facilitating tagging best practices and checking for recommended setup configurations to optimize cross-telemetry insights.
  • Spotting issues like missing SLOs, monitors, or services without ownership.

Streamline collaboration during incidents

  • Improving the on-call experience for everyone by establishing correct ownership information and communication channels, alongside streamlined access to monitoring and troubleshooting details.
  • Embedding links to solutions and troubleshooting tools such as runbooks and documentation directly in the observability tooling engineers are already using.
  • Speeding incident recovery by increasing confidence and simplifying locating owners of upstream and downstream services and dependencies.

Getting started

Explore what Software Catalog has to offer:


Role based access and permissions

For general information, see Role Based Access Control and Role Permissions.

Read permission

The Software Catalog read permission allows a user to read Software Catalog data, which enables the following features:

  • Software Catalog list
  • Discover UI
  • Service Definition endpoint: /api/v2/services/definition/<service_name>

The permission is enabled by default in the Datadog Read Only Role and Datadog Standard Role.

Write permission

The Software Catalog write permission allows a user to modify Software Catalog data. The write permission is required for the following features:

  • Inserting or Updating a Service Definition with the POST /api/v2/services/definitions endpoint
  • Deleting a Service Definition with the DELETE /api/v2/services/definition/<service_name> endpoint
  • Completing the onboarding process in the Discover Services UI
  • Updating service metadata in the UI

The permission is enabled by default in the Datadog Admin Role and Datadog Standard Role.

Services types

Every monitored service is associated with a type. Datadog automatically determines this type based on the span.type attribute attached to incoming spans data. The type specifies the name of the application or framework that the Datadog Agent is integrating with.

For example, if you use the official Flask Integration, the Type is set to “Web”. If you are monitoring a custom application, the Type appears as “Custom”.

The type of the service can be one of:

  • Cache
  • Custom
  • DB
  • Serverless function
  • Web

Some integrations alias to types. For example, Postgres, MySQL, and Cassandra map to the type “DB”. Redis and Memcache integrations map to the type “Cache”.

Filtering Software Catalog entries by component

Every entry showing up in the Software Catalog is categorized as a component type:

  • Services
  • Datastores
  • Queues
  • RUM Apps
  • External providers
  • Endpoints
Software Catalog component selector

Datadog populates Software Catalog entries and determines their associated component type based on collected span attributes for APM (peer tags), but also based other collected telemetry types (USM, DSM, RUM, etc…).

Note: The component supersedes the type filter (derived from the span.type span attribute), as it detects more reliably and more granularly the different entity types. For instance, you can filter by datastore technology using the datastore type facet.

Data retention

The services and resources statistics, and span summaries on the Service List and Service Page are retained for up to 30 days. For customized queries on APM trace metrics, use Metric Explorer. Learn more about data retention for APM.

Further reading

Additional helpful documentation, links, and articles:

Registering Services with the Service Definition APIDOCUMENTATION more more Create and manage service definitions with TerraformEXTERNAL SITE more more See Upstream and Downstream Dependencies During an Active IncidentGUIDE more more Manage Service Catalog entries with the Service Definition JSON SchemaBLOG more more Gain visibility into risks, vulnerabilities, and attacks with APM Security ViewBLOG more more Easily add tags and metadata to your services using the simplified Service Catalog setupBLOG more more I use GitHub Ac­tions for Data­dog's Service Catalog, and you should, tooBLOG more more Improve your shift-left observability with the Datadog Service CatalogBLOG more more Best practices for end-to-end service ownership with Datadog Service CatalogBLOG more more Improve developer experience and collaboration with Service Catalog schema version 3.0BLOG more more Investigate memory leaks and OOMs with Datadog's guided workflowBLOG more more