Datadog Synthetic Monitoring is billed per test run, not per monitor. List rates sit near $5 per 10,000 API test runs and $12 per 1,000 browser test runs on an annual commitment, with pay as you go higher. Because a single one-minute API test is about 43,833 runs a month, that one monitor costs roughly $21.92, and every extra location multiplies it again.
That is the whole answer, and it is also why the question keeps getting asked. Datadog does not publish a "synthetics plan" with a monthly price next to it. It publishes a unit rate, and the unit is an execution. Whether that turns into $8 a month or $2,000 a month depends entirely on choices you make inside the product, which is a genuinely uncomfortable way to buy monitoring if you have never modelled it first.
So let us model it properly, with the arithmetic shown, so you can work out your own number before the invoice does it for you.
How Datadog bills synthetic monitoring
Datadog's own billing documentation is unusually precise about the units, and the precision matters because the two test types are not billed on the same scale. It states that Datadog "charges per ten thousand API tests runs executed to the Datadog Synthetic Monitoring service" and "per thousand browser tests executed to the Datadog Synthetic Monitoring service."
Read that twice. API tests are billed per 10,000. Browser tests are billed per 1,000. That is a tenfold difference in the denominator before you even look at the rate, and it is the single most common misreading of Datadog synthetics pricing. Plenty of comparison articles quote browser tests at "per 10,000" and land on a figure that is ten times too cheap.
| Test type | Billing unit | Annual commitment | Pay as you go |
|---|---|---|---|
| API tests (HTTP, SSL, TCP, DNS) | Per 10,000 runs | About $5 | Higher, varies by commitment |
| Browser tests | Per 1,000 runs | About $12 | About $15 to $18 |
Two more things shape the bill. Overage rates on usage above your committed volume run meaningfully higher than the committed price, so a month where you add monitors without adjusting the commitment is punished twice. And every test location you select executes the test independently, so choosing three regions triples the run count for that monitor rather than adding a small premium.
How much does one Datadog synthetic monitor cost?
Here is the arithmetic in full. An average month is 30.44 days, which is 43,833 minutes. A test running once a minute from one location therefore executes 43,833 times. Divide by 10,000 and multiply by $5, and you get $21.92 for that single monitor.
Now watch what happens as you scale the two dimensions people scale without thinking: how many endpoints you watch, and how many places you watch them from.
| Setup (API tests) | Runs per month | Cost at $5 per 10,000 |
|---|---|---|
| 1 monitor, 5-minute interval, 1 location | 8,767 | About $4.38 |
| 1 monitor, 1-minute interval, 1 location | 43,833 | About $21.92 |
| 1 monitor, 1-minute interval, 3 locations | 131,499 | About $65.75 |
| 10 monitors, 1-minute interval, 1 location | 438,330 | About $219 |
| 25 monitors, 1-minute interval, 2 locations | 2,191,650 | About $1,096 |
| 100 monitors, 1-minute interval, 1 location | 4,383,300 | About $2,192 |
Browser tests are the line that catches teams out hardest, because the instinct is to treat them like uptime checks. One browser test every five minutes from a single location is 8,767 runs, and at $12 per 1,000 that is about $105 a month. For one journey. Run the same test from three locations and you are past $315 a month before you have monitored anything else.
This is why experienced Datadog users run browser tests on a deliberately slow cadence, often every 15 or 30 minutes, and reserve the fast intervals for cheap API checks. It is a sensible pattern, but notice that it is a pattern driven by the pricing model rather than by what you would monitor if cost were not a factor.
Is Datadog synthetic monitoring expensive?
Not for the job it is designed to do. It is expensive for a job it was not designed to do. Those are different claims and the distinction is worth holding onto.
If you run eight API tests against critical internal services at five-minute intervals, your synthetics line is roughly $35 a month. For that you get something no dedicated uptime tool can offer: the failed check lands in the same timeline as the trace, the log line and the host metric that explain it. When a check fails at 3am, you are not switching tabs to correlate. That is worth real money to a team already standardized on the platform.
Where it turns expensive is the general uptime use case: broad coverage across dozens or hundreds of public endpoints, at a fast interval, from several regions. That is a run-count maximiser, and the meter is unforgiving about it. A hundred endpoints at one-minute checks costs about $2,192 a month on Datadog against $95 on Pingdom Advanced or $59 on a flat plan. Nothing is wrong with Datadog's pricing there. It is simply the wrong tool for that shape of work.
The trap in between is the team that starts with a handful of tests, likes them, and quietly grows to sixty without re-modelling. Since Datadog spend is usually reviewed as one platform number rather than per module, this can run for a long time before anyone asks where it came from. If your cloud and SaaS invoices have reached the point where nobody can attribute a line item to a decision, getting a read-only view of where the spend actually goes is usually a faster fix than another round of guessing.
Does Datadog do 30-second checks?
No. Datadog documents one minute as the shortest available frequency for synthetic tests, and there is no faster tier to buy your way into. If sub-minute detection is a firm requirement, Datadog is out on capability rather than on price, and no amount of budget changes that.
This surprises people because Datadog is the expensive, enterprise-grade option in most other categories, so the assumption is that it must also be the fastest. It is not. Pingdom holds the same one-minute floor on every tier including its $249 Professional plan. Among the big names, the one-minute floor is closer to an industry default than an outlier.
Whether that matters depends on your exposure. A one-minute floor means up to a full minute can pass before detection even begins, and if you have an SLA with service credits attached, that minute is time you cannot subtract from the outage afterwards. Our guide to what counts as a good uptime percentage works through how quickly a monthly error budget disappears at each target.
How to estimate your own Datadog synthetics bill
Do this before you commit, not after. It takes about five minutes and it is the difference between a budget and a surprise.
- Count your endpoints. Separate them into "must know within a minute" and "should know within fifteen". Most estates are 80% the second category even though everything gets configured as the first.
- Multiply out the runs. Runs per month equals 43,833 divided by your interval in minutes, times the number of locations, times the number of monitors. Use 43,833 rather than 43,200, because a 30-day month understates a real year by about five days.
- Apply the right unit. API runs divided by 10,000, times $5. Browser runs divided by 1,000, times $12. Keep the two totals separate so you can see which one is driving the bill.
- Add headroom for overage. If your committed volume is tight, a single new service can push you into overage rates for the whole billing period.
- Compare against a flat plan for the bulk. Price the "should know within fifteen" group separately. That group is almost always cheaper on a flat subscription, and moving it frees your Datadog commitment for the checks that genuinely benefit from correlation.
Is Datadog worth it for uptime monitoring?
It is worth it when correlation is the reason you are buying. If a failing synthetic check needs to sit beside the trace and log that explain it, and your team already lives in Datadog dashboards, then paying per run for a focused set of critical tests is a reasonable trade and the bill stays modest.
It is not worth it as a general uptime monitor. Per-run billing punishes exactly the behaviour good uptime monitoring depends on: watching many things, often, from several places. Teams that try it end up throttling intervals to control spend, which quietly degrades the thing they bought monitoring for.
The setup most large Datadog customers land on is both, deliberately split. Datadog covers the handful of user journeys and internal API contracts where the surrounding telemetry earns its keep. A flat-priced tool covers everything else at a fast interval, so breadth costs nothing extra. If you are weighing that split, our Pingdom vs Datadog comparison puts the two billing models side by side with the run math, and the Datadog alternative page covers what a focused monitor does and does not replace. If the shortlist is Datadog against the other big observability platform, the Datadog vs New Relic head-to-head compares the two metering models directly, since New Relic prices synthetics on an included allowance rather than a pure per-run rate.
Frequently asked questions
How much does Datadog synthetic monitoring cost per month?
There is no fixed monthly price. Datadog bills per test run at roughly $5 per 10,000 API runs and $12 per 1,000 browser runs on an annual commitment. A single API test at a one-minute interval from one location is about 43,833 runs, or roughly $21.92 a month. Ten such monitors run about $219.
Is there a free tier for Datadog Synthetics?
There is no standalone free uptime product. Datadog's wider platform includes a free tier covering a limited number of hosts, and new accounts get a trial period, but synthetic test runs are a metered line item rather than something bundled into a free allowance.
Why is my Datadog synthetics bill higher than I calculated?
Almost always one of three things: you counted locations as one when each executes separately, you used the per-10,000 rate for browser tests when they bill per 1,000, or you exceeded your committed volume and moved onto overage rates. Check the location multiplier first, since it is the easiest to overlook.
What is the cheapest way to run uptime checks on Datadog?
Use API tests rather than browser tests wherever the check does not need a rendered page, keep the location count to what you genuinely need for confirmation, and set intervals by how fast you must know rather than setting everything to one minute. Those three choices routinely cut a synthetics bill by more than half.