Datadog review: pricing, alternatives and setup

The Datadog Agent runs on each host or as a container, collects system and integration metrics, and forwards them to your Datadog site. It also receives traces from language tracers such as dd-trace on port 8126 and custom metrics through DogStatsD on UDP port 8125. Everything is stored and queried in Datadog’s cloud, so there is no database to size or run, which is the main operational difference from a Prometheus and Grafana stack. Accounts live on a specific site, such as US1 at datadoghq.com or one of the EU and other regional sites, and every Agent, tracer and API call must use the same site through DD_SITE.

Three reserved tags, env, service and version, set through DD_ENV, DD_SERVICE and DD_VERSION, connect metrics, traces and logs from the same deployment. For testing this is what makes results attributable. If the staging deployment sets env to staging and version to the build number, a load test’s traces, error logs and latency graphs can be filtered to exactly that build, and two builds can be compared under the same load. Without these tags, data from several environments and releases blends together and a performance regression cannot be pinned to a change.

Synthetic tests run from Datadog-managed locations around the world or from private locations you host, which is how internal APIs and websites are monitored. API tests cover HTTP, SSL, DNS, WebSocket, TCP, UDP, ICMP and gRPC, singly or as multistep chains. Browser tests are created from templates, from scratch or by recording with the Datadog Record Test Chrome extension, and run on Chrome, Firefox and Edge at chosen device sizes, at frequencies from every minute to once a week. Mobile app tests and network path tests complete the set. Continuous Testing triggers the same tests from CI instead of a schedule.

Test Optimization reports each automated test as a span, so test duration, failures and flakiness become searchable data rather than CI log lines. A language library hooks into the test framework: for JavaScript, dd-trace loaded through NODE_OPTIONS instruments Jest 28 or later with jest-circus, and Playwright 1.38 or later; .NET, Java, Python, Ruby, Swift and Go are supported, and JUnit XML can be uploaded for anything else. In agentless mode results go straight to Datadog with an API key. When an integration test calls services that are themselves traced, the backend trace appears in the test’s details.

Traces only explain a performance test if they were collected during it, so instrument staging first. Run the Agent with APM enabled, attach the tracer to each service, and set the unified service tags, using the build number as version. Confirm that a single request appears as a full trace across services before scheduling the test. During the run, keep sampling in mind: by default the Agent adjusts sampling to target about ten traces per second overall, so under load most requests are not kept as traces. Judge latency from metrics and use traces to explain representative slow requests, not to count them.

Run the synthetic tests tagged for end-to-end checks on every pull request, against the preview or staging URL the pipeline just deployed. The official action reads *.synthetics.json files by default, or selects tests by public ID or search query, and waits for results so a failure fails the job. If the environment is private, set tunnel to true rather than opening it to the internet. The batch timeout defaults to 30 minutes and failOnTimeout defaults to true, so a stuck test fails the build rather than hanging it.

For a JavaScript suite in GitHub Actions, install dd-trace as a development dependency and run the tests with agentless mode on. Set NODE_OPTIONS only on the test step: if it is set for the whole job, npm install also tries to preload dd-trace before it is installed and fails with Cannot find module dd-trace/ci/init. With parallel runners, the variables must be on the parent process so every worker inherits them. Once results arrive, enable flaky test detection and retries in the Test Optimization settings rather than adding retries in the framework, so Datadog can tell a real failure from a flake.

Post an event before and after each performance test, tagged with the run ID, the build and the scenario. The v1 Events endpoint accepts a title and text with an API key, which is enough for run markers; the v2 endpoint adds structured change and alert categories and needs an application key as well. Use the API host for your site, such as api.datadoghq.eu for EU accounts. Then overlay the events on the performance dashboard, so every graph shows exactly which window belongs to which run.

Treat synthetic tests like any other suite. Tag every test with its owner, journey and purpose, such as production monitor or CI gate, so search queries select the right set. Keep CI-only tests unscheduled and trigger them from pipelines, since scheduled runs are billed whether anyone reads them or not. Use test overrides and global variables for URLs and credentials instead of cloning a test per environment. Review run volume monthly against the billing units, and delete tests nobody owns. Because recorded browser tests live in Datadog, export their definitions through the API or manage them with Terraform if you need review and history.