If you already pay for Datadog, New Relic or Dynatrace, you do not need a second tool to tell you why something broke. You may still need one to tell you that it broke. All three observability platforms stop at a one-minute check interval, all three run their probes from infrastructure you are also paying them to watch, and two of the three meter every synthetic execution. A flat-priced external monitor covers the detection gap for about $19 a month, which is less than most teams spend on synthetic overage alone.
This is not an argument for replacing your platform. It is an argument about which job each tool is good at, and it comes up constantly in procurement because the platforms all ship something called synthetic monitoring that looks like it should cover uptime. Sometimes it does. Here is how to tell whether yours is one of those cases.
Grafana Cloud belongs in the same conversation and behaves the same way. Its synthetic monitoring is billed per test execution per probe location, so a single URL checked every minute from three probes runs to $64.80 a month at list rates, and browser checks cost exactly ten times more than API checks. The full breakdown is in our Grafana Cloud pricing writeup.
What plain uptime checks actually cost inside each platform
Start with the bill, because it decides the question more often than architecture does. A monitor running every minute executes 43,833 times in an average month of 30.44 days. That number is what turns a per-run rate into a real line item.
| Tool | Rate for a simple check | One 1-minute monitor, 1 location | Same monitor, 3 locations |
|---|---|---|---|
| New Relic (ping monitor) | Exempt from the meter | $0 | $0 |
| Datadog (API test) | Near $5 per 10,000 runs | $21.92 | $65.75 |
| Dynatrace (HTTP monitor) | $1.00 per 1,000 requests | $43.83 | $131.50 |
| New Relic (scripted, past allowance) | $0.005 per check | $219.16 | $657.49 |
| AlertPing | Flat plan, unlimited checks | Included from $19/mo | Included, 3 regions standard |
The honest headline in that table is the first row. New Relic exempts simple ping monitors from its synthetic check meter on every edition, including the free one. If you run New Relic and all you want is a URL polled and an email when it fails, that is free, and no external tool beats free. We have written the full New Relic rate card up separately, along with what Dynatrace costs and what Datadog synthetics cost.
Datadog and Dynatrace have no equivalent exemption. Every execution is metered, and the meter multiplies by interval and by location. That is why teams who set up a handful of one-minute checks across three regions get a surprising invoice: thirty endpoints watched that way is a four-figure monthly line on Dynatrace list pricing.
The one-minute floor is a product limit, not a budget question
New Relic documents EVERY_MINUTE as its shortest synthetic period. Dynatrace lists frequencies of 1, 2, 5, 10, 15, 30 and 60 minutes. Datadog documents one minute as its shortest test frequency. There is no faster tier on any of them, at any contract value. Engineers routinely assume this is something enterprise pricing unlocks. It is not.
Average detection latency runs at roughly half the check interval, plus whatever retry logic you run before paging someone. On a one-minute schedule a typical outage is already 30 seconds old before the first failed check, and a confirmation retry pushes that past 90 seconds. Measured against a 99.99% target, where the entire monthly error budget is 4 minutes and 23 seconds, a minute of detection lag spends a quarter of the budget before anyone's phone buzzes. The full arithmetic is on our SLA monitoring page.
Whether that matters depends entirely on your target. At 99.5%, where you have 3 hours and 39 minutes of budget a month, a minute of lag is noise and you should not pay anyone to remove it. At 99.99% on a revenue-carrying checkout, it is a meaningful slice of the number you promised.
A probe inside the failing account is not an independent witness
This is the structural argument, and it survives any pricing change. Observability platforms are excellent at seeing inside your system. That is the whole design. It also means that when the failure is your cloud region, your DNS, your CDN, your TLS certificate or your account's billing status, the thing meant to raise the alarm can be sitting on the wrong side of the outage.
Private locations make this worse, not better, because they run on your infrastructure by definition. Public locations help, but the alerting pipeline, the dashboards and the notification delivery still live in one vendor. If that vendor has a bad afternoon, your monitoring and your incident response go quiet together.
An external monitor is a cheap hedge against a correlated failure. It should reach your endpoints over the public internet, from more than one region, and it should be able to page someone without touching anything you operate. Ours confirms a failure from three regions before alerting, which is what keeps a single flaky probe from waking the on-call.
What to keep in the platform and what to move outside
The split is cleaner than most vendor material admits. Diagnosis belongs in the platform. Detection and customer communication usually do not.
| The question you are asking | Observability platform | External uptime monitor |
|---|---|---|
| Which query made checkout slow? | Yes | No |
| Which deploy introduced the regression? | Yes | No |
| What is the error rate by endpoint? | Yes | No |
| Is the site reachable from outside our cloud? | Partly | Yes |
| Will it still alert if our cloud account is down? | No | Yes |
| Is the TLS certificate about to expire? | Add-on or config | Yes |
| Did the nightly cron job run? | Partly | Yes |
| Can customers see a status page during the outage? | No, or a separate product | Yes |
| Can we detect faster than once a minute? | No | Yes |
Note the row about stale data, which is the one this table cannot really capture. An uptime check confirms that an endpoint answered with a 200 and the keyword you expected. It does not confirm that the numbers behind it are current, and a pipeline that quietly stopped loading last night will pass every uptime check you can write. Catching that needs lineage and freshness checks on the warehouse itself, which is a different discipline from either tool discussed here.
How to run both without doubling your alerts
The failure mode of adding a second tool is alert duplication, where every incident pages twice and people start muting things. Four rules avoid it.
- Give each tool one job. The external monitor owns "is it up, from outside". The platform owns "what is wrong with it". Do not build platform synthetics that duplicate the external checks, and do not try to reproduce APM signals externally.
- Route them to different severities. External detection pages immediately, because it means customers are affected right now. Platform alerts on error rate and latency should usually open a ticket rather than wake someone, unless they cross a hard threshold.
- Turn off platform synthetics you no longer need. This is where the migration pays for itself. Metered checks you forgot about keep billing. Cancelling twenty one-minute Dynatrace HTTP monitors saves $876 a month at list before you count locations.
- Point the status page at the external monitor. It is the one still running when your infrastructure is not, which is exactly when customers are looking at it.
When you genuinely do not need a second tool
Plenty of teams should skip this entirely, and it is worth saying so plainly on a page published by a company that sells the second tool.
If you run New Relic and your uptime need is a ping and an email, use the free ping monitors and stop reading. If your availability target is 99.5% or looser, the one-minute floor costs you nothing you will notice. If your service is internal-only with no customer-facing status page requirement, the independent-witness argument is much weaker. And if you have fewer than about five endpoints that matter, the platform's included allowance probably swallows them without a separate invoice.
The case for pairing gets strong in a specific shape: a customer-facing product, a tight availability promise, a metered synthetic bill that has started to show up in cost reviews, and a team that has been burned once by monitoring going down with the thing it was monitoring. If three of those four describe you, the $19 hedge is easy to justify.
Questions teams ask before buying both
Do I need uptime monitoring if I already have Datadog?
Usually yes, for two reasons. Datadog synthetics floor at a one-minute interval and meter every run, so faster detection is unavailable at any price and broad coverage gets expensive. Its probes and alerting also share a blast radius with the platform itself. An external monitor at a flat price covers detection and leaves Datadog to do diagnosis, which is what it is good at.
Is New Relic synthetic monitoring free?
Simple ping monitors are, on every edition including the free one, and they are exempt from the check meter with no allowance to exhaust. Scripted API checks and browser checks are not free: they draw on an allowance of 500, 10,000, 1,000,000 or 10,000,000 checks a month depending on edition, then cost $0.005 per check.
Can Datadog or Dynatrace check a site every 30 seconds?
No. Datadog documents one minute as its shortest synthetic frequency and Dynatrace offers 1, 2, 5, 10, 15, 30 and 60 minute schedules. New Relic matches them at EVERY_MINUTE. Sub-minute checking is not a tier you can buy on any of the three, so it has to come from a dedicated tool if you need it.
Will running two monitoring tools create duplicate alerts?
Only if both are configured to detect the same thing. Give the external monitor sole ownership of reachability alerts and page on those, and demote platform synthetics to ticket-level or retire them. Handled that way the two do not overlap, and retiring metered checks usually pays for the external tool several times over.
How much does it cost to add an external uptime monitor?
Flat-priced tools in this category start around $9 to $29 a month for a small set of monitors. Ours is $19 for the Starter plan and $59 for Team, which adds 30-second checks. Compared against metered synthetics, one Dynatrace HTTP monitor running every minute from three locations costs $131.50 a month on its own, so the external tool is frequently cheaper than the checks it lets you switch off.
Which platform is cheapest if I only care about uptime?
New Relic, decisively, because its ping monitors cost nothing. Datadog is next at roughly $21.92 per one-minute monitor per month from a single location, and Dynatrace is roughly double that at $43.83. None of them will check faster than once a minute. We compared the three in detail on New Relic vs Dynatrace and Datadog vs New Relic.
The short version
Observability platforms are bought to explain failures and they are worth their price for that. They are not designed to be the fastest or the most independent detector of an outage, and two of the three charge you per execution for trying. Keep the platform for diagnosis. Put detection, certificate expiry, cron heartbeats and the customer-facing status page on something external and flat-priced. Then go and turn off the metered synthetics you no longer need, which is the part that usually pays for the change.