Every service, its owner, its score,
and the button that provisions the next one.
The Datadog Internal Developer Portal is a catalog built from live telemetry, scorecards that grade each service against your standards, and self-service actions that turn a platform process into a form. We implement it on a catalog that is true, and run it every month so it stays true.
Quick facts
Related
- Software Catalog, the inventory the portal is built on
- Teams, the ownership the catalog and scorecards depend on
- DORA Metrics and AI Impact, delivery performance per team and service
A service inventory that cannot go stale, because traffic keeps it honest
The incident is in a service nobody on the call has heard of. The spreadsheet says it belongs to a team that was merged into another team last year. The portal says who owns it now, because the catalog is built from the telemetry the service is emitting right now, and the ownership comes from the team directory, not a cell.
A catalog drawn from what runs. Services, their dependencies and their environments appear because they emit traces, metrics or logs. Ownership, tier, runbooks and repositories are added as metadata, in a definition file that lives with the code.
Scorecards against your standards. Production readiness, observability and ownership rules evaluated daily against every entity. Custom rules through the API for the standards that are yours alone. A score per service, a trend per team.
Self-service that runs the approved way. A new service, a database, a staging environment, from a form built in App Builder and run by Workflow Automation with the approvals in the right place. The developer waits minutes, not a ticket queue.
Reports a leadership team can read. Engineering reports on standards adoption and quality per team, from the same scorecards, without anyone building a slide. External provider status beside it, so the vendor outage is on the same page.
A catalog with three names for one service, a scorecard everyone fails, and a template that provisions last year's stack
How it bills. The portal is assembled from capabilities that each have their own arrangement. The catalog underneath it is included with every APM tier. Self-service actions run on App Builder and Workflow Automation, which are metered separately. Workflow Automation is metered on the workflows that execute, App Builder on the apps that are published. Scorecards and engineering reports evaluate entities already in the catalog, and Datadog's pricing list carries no separate meter for the portal, Scorecards or engineering reports. We publish nothing here, because the price is not the problem. Whether the catalog is true is.
The configuration traps. The catalog is populated from telemetry, so a service without unified service tags appears under one name from its traces and another from Universal Service Monitoring, and a third if someone registered it by hand. Scorecards are switched on with every default rule, and every service fails something on day one, so the scores are ignored on day two. Ownership is typed into definition files instead of synced from the team directory, and the reorganisation that follows makes every owner wrong at once. A self-service template is built for the platform of the day, and the platform moves. None of these raises an error. They show up as a portal that developers open once.
Field noteThe most common gap we see is duplicate entities. The same service is in the catalog under the name its tracer reports, the name Universal Service Monitoring detected and the name in its definition file. Each has a different owner, one has a scorecard, and the on-call engineer picks the wrong one at 2am.
Field noteEvery default scorecard rule is enabled on the first day, including the ones the estate has never aimed at. The report shows red across the board, leadership asks what happened, and the scorecards are turned off before anyone has had a chance to pass one.
Field noteThe pattern we keep finding is ownership typed by hand into every definition file during the rollout. It was correct that week. After the reorganisation it is correct for none of them, and the fix is a pull request into every repository in the estate.
Field noteThe self-service template for a new service was built with care against the standards of its day. Those standards moved, the template did not, and the newest services in the estate are the ones furthest from the current scorecard.
Catalog first. Ownership from the directory. Scorecards one rule set at a time.
The portal depends on a catalog that is true, and a catalog depends on tagging, so it is implemented after the observability foundation. The Software Delivery Accelerator brings the delivery stack into Datadog in four weeks, and the Service Management Accelerator is the route when ownership and on-call are the gap. If the catalog already exists, a Datadog HealthScan reports duplicate entities, missing owners and scorecard state before we change anything. Either way, the sequence is the same.
- Fix the tags before the catalog. One service name across traces, logs, metrics and Kubernetes, so each service appears once. The catalog is only as true as unified service tagging makes it.
- Sync ownership from the directory. Teams in Datadog, synced from the identity provider or GitHub teams, and referenced from each entity definition. A reorganisation is then one change, not one per repository.
- Write the definition files with the owners. Tier, runbook, repository, on-call and dependencies, in a file next to the code, reviewed by the team that owns the service.
- Switch on scorecards one rule set at a time. Ownership and documentation first, because the estate can pass it in a month. Observability second. Production readiness when the on-call model is real. Custom rules for your own standards once the defaults mean something.
- Build the first self-service action for the request the platform team gets most. One form, one workflow, the approvals it needs, a test in staging, and a date to review the template against the scorecards.
- Hand over, in writing. The entity model, the ownership sync, and which rule sets are live and why. The actions built, who owns their templates, and the catalog and scorecard state on the day we finished.
Access is admin on the Datadog organisation, read access to the identity provider or GitHub for team sync, and a pull request into each repository for its definition file. We do not need production shell access to implement the portal, and we do not ask for it.
A catalog is a claim about the estate. The estate reorganises.
A service ships without a definition file. A team is split in two. A template drifts from the standard. A scorecard rule is failed by everyone for a reason nobody has looked into. Managed Observability is the monthly service that keeps the portal describing the estate that exists.
Every month, we review the catalog against the traffic. Services that emitted telemetry and have no entity are registered. Entities that emitted nothing are flagged for retirement. Duplicates are merged at the tag, not the catalog.
Ownership follows the org chart. After each reorganisation we check the team sync and the entity references, so the owner the on-call engineer sees at 2am is the owner who exists at 2am.
The scorecards are kept honest. A rule everyone fails gets a reason: either the standard is wrong or the estate is, and each needs a different fix. A rule everyone passes for a quarter is a candidate for a harder one.
The catalog serves the incident. Under Critical Support our engineers use the catalog to find the owner, the runbook and the dependencies of the service that is paging, 24x7, which is the moment a stale catalog costs the most.
We operate the stack. You own the product.
An implementation partner populates the catalog and hands it over. A managed partner is still there after the reorganisation in March makes every owner wrong. We are the second kind. The entity definitions, the ownership sync, the scorecard rules, the actions and the decisions stay in your Datadog organisation and your repositories, documented, and you can take them in-house whenever you choose. Your engineering standards are yours. We make the portal report against them honestly.
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 Internal Developer Portal, answered plainly
How is the Datadog Internal Developer Portal billed?
The portal is assembled from several Datadog capabilities, and we confirm the meters on your contract before we scope anything. The catalog underneath it is included with every APM tier. Self-service actions are built on App Builder and Workflow Automation, which have their own meters. Workflow Automation is metered on the workflows that execute, App Builder on the apps that are published. Scorecards and engineering reports evaluate entities already in the catalog, and Datadog's pricing list carries no separate meter for the portal, Scorecards or engineering reports. We do not publish prices. Which entities are registered, and how often the automations run, is what we tune.
Is this the same as the Software Catalog?
The catalog is the foundation of the portal, not the whole of it. The Software Catalog is the inventory: every service, its owner, its dependencies and its telemetry, kept current from real traffic. The Internal Developer Portal adds scorecards that evaluate what is in the catalog, self-service actions that let a developer act on it, engineering reports that summarise it, and external provider status alongside it. If the catalog is empty or wrong, nothing above it means anything, which is why the catalog is where we start.
What do the default scorecards check?
Datadog ships three rule sets: production readiness, observability best practices, and documentation and ownership. They check things like whether a service has an on-call owner, an SLO, a runbook link, and monitors on its key signals. They are evaluated every day against every registered entity. Custom rules can be added through the API or Workflow Automation for the standards that are specific to your estate, and results can be summarised into a report delivered to Slack.
What is a self-service action?
A form a developer fills in that runs a process the platform team has already approved. Provision a database, scaffold a new service from a template, create the repository and open the first pull request. The form is built in App Builder, the steps are actions from the action catalog, and Workflow Automation chains them with approvals where they are needed. The developer gets a button. The platform team gets a process that runs the same way every time, with a record.
What does Critical Cloud do with the Internal Developer Portal every month?
Managed Observability runs it every month. We review the catalog against the services that actually received traffic, so new services are registered and retired ones removed. We check ownership still matches the teams that exist. We review scorecard trends and the rules that nobody is passing. We confirm the self-service actions still work after the infrastructure they provision changes, and we report what changed. Fixing a failing scorecard rule is work on the service, and we route it to its owner with the evidence attached.
- Datadog products: every product, and how we implement and run each one
- Software Catalog: the inventory, and the tagging it depends on
- Workflow Automation: the engine behind every self-service action
- Software Delivery Accelerator: the delivery stack in Datadog in four weeks
A catalog that is true. Scorecards the estate can pass. A button instead of a ticket.
Tell us which request the platform team answers by hand most often. We will tell you what the catalog already knows, what it would take to make it true, and what it costs to get there.