Every Datadog product.
Implemented, tuned and run by one team.
Datadog sells the platform. Each product on it still has to be switched on properly, scoped to the estate, billed on the right meter and looked at every month. These pages say how we do that for each one.
Four things, for every product
Each page says four things. What the product gives you, in buyer terms. Where implementations go wrong, and how it bills. How we implement it, and which service that starts with. And what Managed Observability or Critical Support does with it every month. No prices. Datadog publishes those. What we publish is the configuration that decides them.
The groups below follow Datadog's own product navigation, so a product is where Datadog puts it. A few platform features with no implementation decision to make are described at the end rather than given a page.
Infrastructure, applications, data and logs
The core of the platform and the core of what we run. These are the products on the invoice every month, and the ones where the configuration decides the bill.
Infrastructure
- Infrastructure MonitoringHosts, cloud services and the high-water mark that bills them
- Custom MetricsThe metric nobody meant to make expensive
- Network MonitoringFlows, devices and configuration drift
- Container MonitoringKubernetes, ECS and Fargate, counted correctly
- Kubernetes AutoscalingRightsizing from the data Datadog already has
- Serverless MonitoringLambda per active function, Azure Functions per active app instance
- Cloud Cost ManagementThe cloud bill next to the telemetry that explains it
- Storage ManagementObject storage, by prefix, by cost
- GPU MonitoringUtilisation of the most expensive hosts in the estate
Applications
- Application Performance MonitoringTraces, service map, sampling and retention filters
- Universal Service MonitoringRequest, error and latency with no tracer
- Continuous ProfilerWhere the CPU and memory go inside the service
- Dynamic InstrumentationLog points and metrics without a redeploy
Data
- Database MonitoringQuery performance and explain plans, per host
- Data ObservabilityFreshness, volume and schema of the data pipelines
- Data Streams MonitoringLag and throughput across queues and streams
Logs
- Log ManagementPipelines, indexes, Flex Logs and archives
- Audit TrailWho changed what in Datadog, kept as evidence
- Observability PipelinesShaping logs before Datadog sees them
- Error TrackingExceptions grouped into issues with owners
- Bring Your Own Cloud Log ManagementLog storage in your own cloud account
Code, cloud, SIEM, and the data and AI layer
We are not a security company. We operate the detection and posture tooling inside your Datadog, triage what it finds, fix what sits in the runtime we run, and route the rest to an owner with the evidence attached.
Code Security
- Code SecurityThe group, and how the findings reach a developer
- Software Composition AnalysisDependencies, licences and the SBOM
- Static Code AnalysisRules on the code before it merges
- Runtime Code AnalysisVulnerabilities seen in the running service
- IaC SecurityTerraform and CloudFormation checked before apply
- Secret ScanningKeys in the repository, found before someone else does
SIEM
- Cloud SIEMDetection rules on the logs already being sent
AI and data security
- AI GuardRuntime protection for agents and LLM applications
- Sensitive Data ScannerPersonal data found and redacted in logs and traces
Cloud Security
- Cloud SecurityThe group, scoped, with an owner for every finding
- Cloud Security Posture ManagementMisconfigurations in accounts and clusters
- Cloud Infrastructure Entitlement ManagementIdentities with more permission than use
- Vulnerability ManagementCVEs on hosts, containers and images, ranked by exposure
- ComplianceFindings mapped to frameworks, with the history kept
- Cloud Workload ProtectionProcesses, files and network watched at runtime
- App and API ProtectionAttacks seen in the trace, blocked in the service
What the user saw, and what they would have seen if the test had run first
- Real User MonitoringPage loads, errors and Core Web Vitals from real sessions
- Session ReplayThe session, replayed, with the trace underneath
- Synthetic MonitoringAPI and browser tests from where the users are
- Mobile App TestingReal devices, real builds, before the store does
- Product AnalyticsFunnels and retention on the same RUM data
- ExperimentsFeature flag experiments measured in RUM
The pipeline, the tests and the portal, in the same place as production
- CI VisibilityPipeline duration, flakiness and failure by stage
- Test OptimizationFlaky tests found, slow suites cut
- Continuous TestingSynthetic tests in the pipeline, blocking the deploy
- Code CoverageCoverage per commit, next to the test results
- Internal Developer PortalServices, owners, scorecards and the Software Catalog behind them
- Feature FlagsFlags evaluated and observed in the same tool
- DORA Metrics and AI ImpactDeploy frequency, lead time, failure rate and recovery
The page, the response and the record
This is the group where we are inside the product, not just configuring it. Under Critical Support our engineers are the escalation target on the rota, 24x7.
Incident Response
- Incident ManagementWith On-Call and Status Pages, staffed by us
- Work ManagementPostmortem actions tracked until closed
Context Graph
- Software CatalogEvery service, its owner and its dependencies
Actions
- Workflow AutomationThe steps that run before a human is paged
- Event ManagementCorrelation, so one cause raises one case
- Datadog AppsSmall tools built where the data already is
AI inside Datadog, and Datadog for the AI you run
Agents own the analysis. Humans own the outcome. That is how we run the Bits agents, and it is what Agent Observability is for. Where a Bits feature is still in Preview, its page says so.
AI for Datadog
- Bits AIThe agent family, and the guardrails we run it under
- Bits InvestigationRoot cause proposed, verified by an engineer
- Bits ChatQuestions against the telemetry, in plain language
- Bits Agent BuilderAgents for your own runbooks, with scope limits
- Bits CodeFixes proposed from the trace, reviewed before merge
- Bits Security AnalystSignals triaged, with a human on the decision
Datadog for AI
- Datadog for AIThe group: observability, protection and GPU for AI workloads
- Agent ObservabilityFormerly LLM Observability. Traces, tokens, evals and cost per call
- AI GuardPrompt injection and tool misuse, stopped at runtime
- GPU MonitoringAlso listed under Infrastructure
- MCP ServerDatadog as a tool for your own agents, with access limits
- Pup CLIDatadog from the terminal and the pipeline
The features every product depends on
Built-in features
- AlertsMonitors that page for a reason, reviewed monthly
- Fleet AutomationEvery Agent, its version and its config, from one place
- Access ControlRoles, teams and the permissions an auditor asks about
- Governance ConsoleOrganisations, usage and policy across the estate
- TeamsOwnership that routes the alert to the right people
Extensibility
- OpenTelemetryOTel data in Datadog without losing the correlation
- IntegrationsThe cloud, database and SaaS integrations, configured and kept current
- Service Level ObjectivesTargets, error budgets and the report the board reads
Not given a page. Dashboards and Notebooks are built on every engagement, and the dashboard guides on the blog cover them in more detail than a service page would. The mobile app, IDE plugins, Agent Directory, the API and the Marketplace are platform plumbing: we use them, there is nothing to implement, and there is no decision to sell against.
One team for the whole platform.
Tell us which products are switched on and which ones the invoice says are. We will tell you what each one is doing, what it should be doing, and what it takes to get there.