How Datadog defines service criticality at scale

Datadog developed a centralized Service Criticality system to identify which internal services most affect customer-facing reliability, replacing a uniform approach that had slowed deployments and misallocated reliability effort as its global infrastructure grew. The company initially used LLMs to extract services involved in SEV-1 and SEV-2 incidents from thousands of unstructured postmortems, validating results against its Software Catalog and through a second model review, but recognized that incident history alone could miss reliable yet essential services or misattribute impact. Its system therefore combines incident, error-trace, traffic, and monitoring signals to assign services high, low, or unknown criticality levels and a confidence score, with dependency mapping planned as an additional input. The design deliberately favors false positives over false negatives, since treating a noncritical service cautiously is less costly than deploying too quickly to a truly critical one. Teams access classifications through a centralized API, while service owners can override results with explanations, preserving both automated evidence and human operational knowledge. Datadog uses the classifications to accelerate deployments of lower-criticality services, tier rollout strategies across data centers, and adjust pull request auto-merge requirements, while suggesting that smaller organizations can adopt similar multi-signal methods using incident records, dependency knowledge, and service-owner input.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.