Universal Service Monitoring
Universal Service Monitoring (USM) is a feature that picks up request count, errors, and duration with the Agent alone, without touching code. It is the foundation for aligning the health of services you cannot instrument and for deciding where to put APM.
What it does
The system-probe of the Datadog Agent placed on a host observes HTTP / HTTPS traffic and, for each service running in containers or VMs, produces the three indicators of request count / error rate / duration plus dependencies as seen from the communication destinations. The results appear in the catalog and the service map, and you can build monitors and SLOs from the universal.http.* metrics.
When to use it
When you want to see the health of middleware or other teams' services that you cannot touch, without distributing an SDK. When you want to decide which of dozens of services are worth adding APM to, starting from the overall distribution of latency and errors. When you want to find, on the same screen regardless of instrumentation, the service whose error rate rose right after a deployment.
An everyday analogy
It is a mechanism close to a station's automatic ticket gate. Without giving passengers anything to carry, the gate itself can record how many people passed through (request count), how many could not pass (errors), and the time from entry to exit (duration). However, the gate cannot tell which route that passenger walked inside the station (the order of processing within the request); to know that, you need APM instrumentation, which gives the passenger a recording device.
Bottom line - without instrumentation, what you can see stops at service health
Let us settle the boundary of USM first. The official documentation defines USM as a feature to "view service health metrics across the entire stack without instrumenting code," and explains that it depends only on a configured Datadog Agent and Unified Service Tagging (as of September 2026, source: Universal Service Monitoring). The outputs listed are the golden signals of request count / errors / duration and the dependencies shown in the catalog and the service map; span-level information about which processing an individual request went through inside a service is not listed. That is the domain of APMtraces.
| Question | USM (no instrumentation) | APM (library instrumentation) |
|---|---|---|
| How much is this service being called right now, what share fails, and how many milliseconds does it take | Visible (universal.http.* metrics) | Visible (trace metrics) |
| Which service is communicating with where | Visible (service map dependencies) | Visible |
| In which processing step did one slow request wait | Out of scope | Visible (spans) |
| Which function is using CPU | Out of scope | Visible with Continuous Profiler |
Surprisingly many situations are covered by just the top two rows of this table, and if you leave those to USM, you can concentrate APM instrumentation effort and host unit prices on "the services that truly need the bottom two rows."
Prerequisites are the Agent and system-probe, supported OSes, and container environments
The prerequisite is the Agent's system-probe. On the setup page (as of September 2026), the requirements are Agent 6.40 / 7.40 or later, Linux kernel 4.14 or later, Windows 2012 R2 or later, and the supported protocols are HTTP / HTTPS (OpenSSL) (source: Setting up USM). The premises are that on Linux the service runs in a container (outside containers is Preview) and on Windows it runs on a VM. GKE Autopilot is out of scope because system-probe cannot be used. Additional protocols and encryption methods are in Preview, and the items on the setup page are Go / Node.js TLS, Istio (Agent 7.50 or later), HTTP/2, and Kafka Console (same point in time, same source). The judgment is mostly settled by two points: "Linux container or Windows VM?" and "HTTP / HTTPS?"
Where does the service name come from?
The key to determining "which service" without instrumentation is environment variables. The official documentation explains that USM detects the service name from the environment variables present when the process starts, reading /proc/PID/environ on Linux and the system API on Windows (as of September 2026, source: Setting up USM). As a prerequisite, attaching the env tag of Unified Service Tagging to the deployment is mandatory, while service and version are optional. Optional though it is, if you do not attach service, the same service ends up listed under different names in the catalog. In other words, USM is a feature that "does not touch code," but not a feature that "does not touch deployment definitions." The work of writing three tags in a Kubernetes manifest or an ECS task definition remains, and those three become the glue that connects the service as the same one when you add APM later.
What you see is the catalog, the service map, and three indicators
The official documentation says that services appear in the catalog about 5 minutes after the Agent is configured. If the operation name universal.http.server (inbound) or universal.http.client (outbound) appears at the top left of the service page, it comes from USM (as of September 2026, source: Universal Service Monitoring). There are three things you can do: visualize services and dependencies in the catalog and the service map, view the golden signals on the service page and correlate them with code changes through Deployment Tracking, and create monitors, dashboards, and SLOs from the universal.http.* metrics. The last item is the one that pays off: operating patterns such as "notify when the error rate exceeds 1%" and "99.9% monthly availability" can be applied to uninstrumented services in the same form as instrumented ones. The value is escaping the state where gaps in monitoring are determined by "whether we instrumented it."
Where is the gap between USM and APM?
There are three gaps between USM and APM. First, granularity: USM's output is metrics per service, and the breakdown into spans, such as the duration of DB calls or external API calls within a single request, is produced by APM instrumentation. Next, protocols: USM supports HTTP and HTTPS (OpenSSL), and additional protocols and encryption methods are in Preview (as of September 2026, source: Setting up USM). Finally, where it runs: because USM runs as a separate process on the Agent side, it cannot detect environment variables set at runtime inside the app's code, while the APM instrumentation library running inside the app can read them, according to the limitations on the same page. This third point is the cause of the phenomenon where "APM assigns the service name but USM shows a different name," and the remedy is to set the environment variables in the deployment definition before the app starts. If you know the gaps, you can read a discrepancy between USM and APM numbers as "they are looking at different layers."
How to think about pricing - there is no standalone SKU in the public table
On the official pricing page as of August 2026, USM is not listed as an independent SKU, and the official documentation's pricing page on billing has no entry for USM either (as of September 2026). Therefore this article does not give a unit price and defers the contractual treatment to the public price table at Datadog Pricing and confirmation with the sales contact. Two points about cost are certain. One is that because USM runs on hosts where the Agent is placed, the premise is a setup where those hosts are already within the billing scope of Infrastructure Monitoring (a monthly amount per host on Pro / Enterprise). The other is that because USM does not require an SDK, you can align the health of all services before adding APM, and choose afterward which ones to pay APM host unit prices for. For how the SKUs stack up, see how to read the pricing structure. This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page.
Conditions where USM suffices, and conditions where APM is needed
Putting the boundary in the form of conditions gives the following.
| USM suffices | APM is needed |
|---|---|
| Services owned by other teams whose code you cannot touch | Services you develop yourselves and whose latency breakdown you need to fix |
| Middleware or packaged products into which an SDK cannot be embedded | Things where you want to see the duration of each DB query or external API call separately |
| Communication is HTTP / HTTPS, and what you want to know is request count / errors / duration and dependencies | Communication is mainly non-HTTP such as gRPC, and you cannot wait for Preview protocol support |
| The stage of aligning SLO and notification patterns across all services | The stage of chasing error stack traces and slow functions |
In organizations where services owned by other teams are the majority, the first place USM pays off is not your own services but the neighboring team's. The right column is limited to services where "there is someone to fix it, and fixing it requires the breakdown." Dividing things this way gives you grounds for concentrating APM instrumentation effort and host unit prices on the few services where they truly pay off. It looks at a different layer from Network Monitoring, which views communication flows between hosts; USM is responsible for HTTP health per service.
The order of staged migration is USM to APM
USM is not a replacement for APM; it is the first step for deciding where to put APM. Think of the order as the following three steps.
- 1. Place the Agent on all hosts and write the
env/service/versiontags in the deployment definitions. USM aligns the health and dependencies of all services in about 5 minutes - 2. Add APM instrumentation to the services with bad error rates and durations. Because they connect through the same
servicetag, you can descend from the USM list to APM details without a gap - 3. Enable Continuous Profiler only for the services that need function-level CPU and memory
The advantage of this order is that the work of aligning tags in step 1 carries straight over to steps 2 and 3. The Agent placed for Container Monitoring and its tags satisfy the prerequisites for USM, and when you add APM later it connects as the same service. Conversely, if you start from APM, only the instrumented services are visible and the uninstrumented ones remain outside monitoring, so operations proceed with "the visible range" and "the running range" out of alignment. Without it, the monitoring net is full of holes depending on instrumentation; with it, you can line up the health of all services on the same screen and then choose the targets for deeper investigation. That is the landscape USM changes.
Things to watch out for
- This article is based on the official documentation as of September 2026. Supported OSes / protocols / the scope of Preview can change, so check the setup page before adopting.
- This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page. No standalone unit price for USM is listed on the official pricing page as of August 2026.
- USM does not detect environment variables set at runtime inside the app's code (as of September 2026). Set the service name in the container or deployment definition, before the app starts.