Synthetics

Failures that external monitoring catches and internal monitoring cannot see

The server's CPU and error logs are normal, yet users cannot reach the site. Failures that happen "outside yourself," such as a DNS misconfiguration, an expired certificate, or a CDN or load balancer malfunction, cannot be caught by internal monitoring alone. Synthetic Monitoring is the mechanism that fills this blind spot; in Datadog, simulated requests and interactions are sent from locations around the world, and the behavior of web pages and APIs is continuously verified under stable conditions. The range of network layers it can target is broad: HTTP, SSL, DNS, WebSocket, TCP, UDP, ICMP, and gRPC (as of August 2026, source: Synthetic Testing and Monitoring). Because the verification results can also feed the calculation of SLOs for key endpoints and user journeys, "our login path goes through 99.9% of the time" becomes a measured value rather than a verbal promise. Tests can be created not only in the UI but also through the API or Terraform, so there is a path for teams that want to manage monitoring as code.

The first step is an API test

What the official documentation offers as the starting point for adoption is the API test. There is a form that sends a single request and a multistep form that chains multiple requests, and with an HTTP test you can build in a few minutes a check like "GET this endpoint, status 200 returns within 500 milliseconds, and the response body contains a specific string" (as of August 2026, source: API Tests). The SSL test watches certificate validity, and the DNS test watches the correctness of name resolution. In practice, the standard move is to start with two tests: an HTTP test against a health check endpoint and an SSL test on the production domain. With just these two, the witness to the two most embarrassing incidents, "the site is completely down" and "the certificate is about to expire," changes from your users to a machine. Multistep is the next move when you proceed to checks that a single request cannot express, such as obtaining an authentication token and then calling the real API.

The ease of building browser tests and their fragility are two sides of the same coin

A browser test runs a scenario that operates a web app in a real browser on a schedule, from locations around the world, across multiple browsers and devices, and you create it by recording the steps with the recorder while actually performing them. You can also start from a prepared template (as of August 2026, source: Browser Tests). The flip side of being able to build one just by recording is that browser tests are fated to break easily when the UI changes. There are four practical techniques for keeping them robust. First, limit scenarios to "paths whose failure stops the business." Three tests on the checkout path are easier to maintain than 30 that aim for coverage. Second, limit assertions to the essential success conditions. If you verify the wording character by character, the test breaks every time the wording is revised. Third, turn URLs and credentials into variables so the tests withstand environment changes. Fourth, tie them to downtime settings during planned maintenance. Tests are automatically paused during downtime windows, so you can escape the practice of waking people up with false alerts at every late-night maintenance.

Estimate run-count billing as frequency multiplied by locations

The billing unit for Synthetics is the number of test runs. On the official pricing page as of August 2026, API tests are 5 dollars per 10,000 runs per month and browser tests are 12 dollars per 1,000 runs per month (both annual commitment), so the unit prices differ by an order of magnitude. In addition, browser tests have a rule that counts every 25 steps as 1 run, so a 50-step test is counted as 2 runs every time. Accidents come from overlooking this multiplication. Let us count along the lines of the official example.

Nothing flashy is being done as a single test, yet it reaches this scale. The estimation procedure is just one step, "multiply the run interval, number of locations, number of devices, and number of steps to get the monthly run count, then apply the price table," and conversely, skipping this one step guarantees a surprise. Two defenses work: split run intervals by test importance (liveness at 1 minute, path checks at 15 minutes, coverage checks at 1 hour), and limit locations to the regions where your users actually are. Note that the prices in this article are examples at each point in time and do not reflect price changes made after writing. The overall pricing structure is covered in the pricing guide.

Private Locations - a mystery shopper for internal systems too

For internal apps and private endpoints that cannot be reached from the public internet, you use Private Locations. When you install a worker inside your own network as a Docker container, a Windows service, or on Kubernetes (Helm), the worker fetches test configurations from the Datadog side over HTTPS, runs the tests inside the network, and returns the results (as of August 2026, source: Private Locations). Because the worker reaches outward to fetch, the design does not require opening a new communication path from outside into the internal network. The uses the official documentation lists are monitoring internal apps, standing up your own locations in regions important to the business, verifying app behavior in a CI environment before a production release, and comparing performance inside and outside the corporate network. The comparison at the end is the one that is welcome in practice: when "fast from inside the company but slow from outside" is visible as numbers, determining whether the problem is on the app side or the network path side proceeds with data instead of conversation. Because managed locations and Private Locations are handled the same way from the test's point of view, the operating pattern does not change.

How far to go with Synthetics, and where to draw the line with E2E tests

If you can build browser tests, the idea comes up that pre-release UI tests could all be done with Synthetics too. The criterion for drawing the line is "when that test fails, do you page someone?" Things that need immediate action when they fail, such as production liveness, critical paths, and certificates, are the domain of Synthetics, operated together with a notification setup through monitors. On the other hand, comprehensive UI verification of features under development is the domain of CI E2E tests managed in the same repository as the code. When test code and product code are changed and reviewed together, the cost of keeping up with UI changes stays lower. Datadog also has a CI/CD integration mechanism called Continuous Testing that sits between the two, but it is enough to start from the simple line "production monitoring = Synthetics, development-time verification = CI" and think about it once you run into trouble. Also, since Synthetics is simulated access, it cannot see the actual experience of real users. Observing real customers is the domain of RUM, and if you think of the complementary relationship as "Synthetics watches during hours when nobody is there, RUM captures reality during hours when they are," the investment decision for both falls neatly into place.