Every service has an owner,
and the catalog can prove it.
Datadog Software Catalog, listed under Context Graph in Datadog's navigation, is the record of every service, datastore, queue and system: who owns it, what it depends on, and whether it meets the standards you set. We build it from the telemetry that already exists and the definitions that do not yet, and we keep it true every month so the page that an incident lands on names a person.
Quick facts
Related
- Internal Developer Portal, Scorecards and self-service actions on top of the catalog
- Teams, the owners the catalog points to
- APM, where most of the entities are discovered
The answer to "who owns this?", before the incident asks
The alert names a service. The service was written by a team that was reorganised twice. Its repository is in an archived group and its on-call rota is a person who now works somewhere else. Twenty minutes into the incident, someone finds the right team by reading commit history. Software Catalog is where that answer is kept, and kept current.
Entities from telemetry, then from definitions. Services, datastores and queues appear on their own from APM, USM and RUM. What telemetry cannot see, a cron job, a package, a vendor API, is declared in an entity definition or imported from Backstage or ServiceNow.
Ownership that reaches a person. Each entity belongs to a Team, and the Team carries its Slack channel, its repositories and its on-call schedule. The incident page shows who to call, not who wrote it originally.
Dependencies drawn from traffic. The Relationships view maps what calls what from real requests, and links each service to the infrastructure it runs on. The diagram in the wiki is replaced by one that cannot be out of date.
Standards you can measure. Scorecards, part of the Internal Developer Portal built on the catalog, check each service against rules you set: has an owner, has a runbook, has an SLO, has a paging monitor. The gaps are a list, not an opinion.
Three names for one service, an owner called "platform", and a definition file nobody has edited since the migration
How it bills. Datadog's pricing list carries no separate meter for Software Catalog or Scorecards. Its APM pricing lists Software Catalog in every APM tier, and Datadog documents resource collection as free for any Infrastructure Monitoring customer. The entities the catalog shows are discovered through products that do bill, APM, USM and RUM among them, so the catalog's cost is the cost of the telemetry beneath it. Self-service actions built on the catalog run on App Builder and Workflow Automation, which have meters of their own. We publish no rates. The lever here is not a meter. It is whether the catalog is believed, and a catalog with unowned services is not.
The configuration traps. The same service appears three times because the Agent, the tracer and the log pipeline each gave it a different name, and unified service tagging was never finished. Ownership is set to a team called "platform" that has nine people and no rota. Entity definitions were written once during the migration and never updated, so the catalog describes the architecture of the previous year. Backstage is imported and Datadog detection is on, and the two disagree about what exists. Scorecards are enabled with every default rule, so every service fails most of them and the score means nothing. None of these is a product fault. Each is a catalog that was built once and treated as finished.
Field noteThe most common gap we see is the catalog that is complete and untrusted. The entries exist. The owners are the team names from the org chart two reorganisations ago, so during an incident everyone goes back to asking in the channel.
Field noteThe pattern we keep finding is three entries for one service, split by the tag convention. The service map draws three half-services, Scorecards fail all three for missing an owner, and the real service has one.
Field noteEntity definition files live in the repositories, which is the right place, and are reviewed by nobody, which is the wrong state. A service is renamed in code, the definition is not, and the catalog carries a ghost that still has an on-call schedule.
Field noteThe default Scorecards start evaluating on a Friday with every rule on. By Monday every service is red, which is accurate and useless. The teams stop looking, and the one rule that mattered, has a paging monitor, is lost in the list.
Tags first. Owners second. Standards only once the first two are true.
The catalog is the first week of the Service Management Accelerator, a four-week, fixed-scope delivery, because Incident Management, Event Management and Work Management all route to the owners the catalog names. If services are already in the catalog, a Datadog HealthScan reports duplicates, orphans and tag consistency before we change anything. It is read-only and fully automated.
- Finish unified service tagging. One value each for env, service and version across the Agent, the tracer and the log pipeline. This decides how many entries one service gets, and it is not optional.
- Reconcile the detected list. Every service Datadog detected, checked against what the team recognises. Duplicates merged by fixing their tags, test and tooling noise excluded, and the real list agreed in writing.
- Set up Teams with real contacts. A Team per owning group with its Slack channel, repositories and On-Call schedule. "Platform" with nine people is split until each entity has a rota that answers.
- Declare what telemetry cannot see. Entity definitions for datastores, queues, cron jobs and vendor dependencies, kept in the repositories and validated in CI. Where Backstage or ServiceNow is the source of truth, it is imported, and the conflict rules are set.
- Switch on the Scorecards that matter. Three or four rules the organisation will actually enforce: an owner, a paging monitor, a runbook, an SLO. The rest stay off until those are green.
- Hand over the catalog and its review rule. The agreed service list, the Teams, the definition locations and the Scorecard rules. With them, a written rule for how a new service enters the catalog before it enters production.
Access is admin on the Datadog organisation plus read access to the repositories that hold entity definitions, and read access to Backstage or ServiceNow where either is the source of truth. We do not need write access to your code to build the catalog, and we hand you the definition files to commit.
A catalog is a claim about the estate, and the estate changes every week
A new service ships without a definition. A team is renamed. A datastore is migrated and its old entry is left behind. Managed Observability is the monthly service that reconciles the catalog against what is actually running, so the owner the incident reaches is still the owner.
Every month, orphans are found. Services detected in telemetry with no owner, no Team or no definition are listed and assigned, and the tag or deploy pipeline that let them in is fixed.
The catalog follows the org chart. When a Team splits or a rota changes, the entities move with it in the same week, because the catalog review checks Teams against On-Call and the incident history.
Definitions are kept true. Entity definitions are validated against the detected estate. A ghost entry for a renamed service is removed, a migrated datastore is updated, and the diff is in the monthly report.
The Scorecard means something. The few rules that are on are reviewed against the incidents that happened. A service that paged without a runbook is a rule that was right. A rule that stays red for a quarter is a conversation about whether it is wanted.
We operate the stack. You own the product.
A catalog that was accurate at handover is a photograph. A catalog that is reconciled every month is a record. We build the first and run the second. The entities, the Teams and the definition files stay in your Datadog and your repositories, and you can take the catalog 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 Software Catalog, answered plainly
Is Software Catalog the same as Service Catalog?
It is the renamed and widened version of it. Service Catalog listed services. Software Catalog lists services, datastores, queues, APIs, systems and whatever else you define as an entity, and links each to the infrastructure it runs on. It sits under Context Graph in Datadog's navigation alongside the Internal Developer Portal. The Internal Developer Portal, with Scorecards and self-service actions, is built on top of the catalog.
How is Datadog Software Catalog billed?
Datadog's pricing list carries no separate meter for Software Catalog, and its APM pricing lists Software Catalog in every APM tier. Datadog documents resource collection as free for any Infrastructure Monitoring customer. The entities it shows are discovered through APM, USM, RUM and the infrastructure products, which bill on their own meters. We do not publish prices. The work in a catalog is accuracy rather than cost, and accuracy is what the monthly review maintains.
Do we need APM for the catalog to be useful?
No, but it helps. Datadog states that the catalog works without telemetry: you can declare entities in definition files or import them from Backstage or ServiceNow, and ownership, documentation and Scorecards all work from that. APM and Universal Service Monitoring add the part a file cannot: dependencies drawn from real traffic and the link from each service to the host or pod it is running on right now.
Can we keep Backstage and still use Software Catalog?
Yes. Datadog imports entities from Backstage and ServiceNow and keeps them in sync, so a team that maintains its catalog in Backstage does not have to maintain it twice. What needs deciding is which system wins when the two disagree, and we set that rule during the implementation rather than leaving both to drift.
What does Critical Cloud do with Software Catalog every month?
Under Managed Observability we reconcile the catalog against the estate. Services detected with no owner or no definition are assigned, and the gap that let them in is fixed. Teams are checked against On-Call and the incident history. Entity definitions are validated and ghost entries removed. The Scorecard rules are reviewed against what actually paged. The diff is in the monthly report, so the catalog stays something the incident process can rely on.
- Datadog products: every product, and how we implement and run each one
- Internal Developer Portal: Scorecards and self-service actions on the catalog
- Service Management Accelerator: the catalog, incidents, events, workflows and work items in four weeks
An owner for every service, every month.
Tell us how many services Datadog shows and how many your team recognises. We will tell you what the catalog should contain, who should own each entry, and what it takes to keep that true.