Checked from regions with auto-retry. No single-location false alarms.
All systems operational. Steady pulse across every region.
api.example.com returned no response from all 6 regions. Auto-retry confirmed the outage, then we alerted your team.
api.example.com is back up. The incident is logged to your status page history automatically.
90-day uptime · branded · your domain
Live demo · drive it, no signup needed
A standard CloudWatch alarm costs $0.10 per alarm metric a month in US East (N. Virginia), and the first 10 are free. High-resolution alarms are $0.30, composite alarms $0.50, and an anomaly detection alarm is billed as three metrics, so $0.30 at standard resolution. For downtime alerting, the alarm is almost never the expensive part: on 20 endpoints it is $1 of a $56 to $1,038 monthly bill, depending on what does the checking.
Every rate below comes from the AWS Price List for CloudWatch, Route 53 and SNS in US East (N. Virginia), in US dollars, and the billing rules come from AWS's CloudWatch pricing page. Other Regions can differ slightly.
How much do CloudWatch alarms cost?
CloudWatch bills alarms by the metric, not by the alarm, and it bills them for existing, not for firing. An alarm that has sat in the OK state for a year has cost $1.20 like any other.
| Alarm type | Free each month | Price a month |
|---|---|---|
| Standard resolution, per alarm metric | First 10 | $0.10 |
| High resolution (10 or 30 second periods), per alarm metric | None | $0.30 |
| Composite alarm | None | $0.50, however many alarms it combines |
| Anomaly detection, standard resolution | None | $0.30 (the metric plus two band metrics) |
| Anomaly detection, high resolution | None | $0.90 |
| Metrics Insights, PromQL or log query alarm | None | $0.10 plus query charges |
"Per alarm metric" is the phrase that matters. A standard alarm using metric math over four metrics is billed as four alarm metrics, $0.40 a month, and AWS counts up to ten metrics in one expression. The free 10 apply only to standard-resolution alarms that list their metrics directly, so a query-based alarm is billed from the first one.
Is a CloudWatch anomaly detection alarm $3 or $0.30?
It is $0.30 at standard resolution. A figure of $3.00 a month turns up in search summaries of CloudWatch pricing, and it does not match AWS. The CloudWatch pricing page bills an anomaly detection alarm for each metric in its expression plus two more for the upper and lower bands, and its own worked example is five alarms at $0.30 each, $1.50 a month. At high resolution the same alarm is three metrics at $0.30, so $0.90.
Anomaly detection is useful on response time, where a fixed threshold is either noisy at peak or blind at night. It is less useful for uptime itself, which is a yes or no question a plain threshold answers well. The same banded approach is common on data pipelines, where people alarm on rows landed per hour; if that is the real job, dedicated freshness and volume checks on your warehouse tables cover it with lineage, and CloudWatch can stay on the infrastructure.
What does a CloudWatch downtime alert really cost?
An alarm needs something to watch. On AWS, the two usual sources for "is the site up" are a Route 53 health check and a CloudWatch Synthetics canary. Here is one endpoint priced end to end, ignoring free tiers so the unit cost is clear.
| Setup, one public HTTPS endpoint | The check | The alarm | Per month |
|---|---|---|---|
| Route 53 health check, outside AWS, HTTPS option | $2.75 | $0.10 | $2.85 |
| Route 53 health check, HTTPS and string matching | $4.75 | $0.10 | $4.85 |
| Synthetics canary every 5 minutes (8,640 runs) | $10.37 | $0.10 | $10.47 |
| Synthetics canary every minute (43,200 runs) | $51.84 | $0.10 | $51.94 |
Canary figures are runs at $0.0012 in a 30-day month and leave out the Lambda, S3 and log charges each run also creates, which are covered in our CloudWatch Synthetics pricing breakdown. The Route 53 figures are for an endpoint outside AWS, where the check is $0.75 and each option, HTTPS included, is $2.00.
CloudWatch alarm cost for 20 endpoints
Scale that to a normal set of things worth watching: the marketing site, the app, the login, the API, a few webhooks and customer-facing subdomains. Twenty endpoints, one standard alarm each, free tiers applied.
| Line, 20 endpoints | Route 53 HTTPS | Canary, 5 minutes | Canary, 1 minute |
|---|---|---|---|
| Checks | $55.00 | $207.24 | $1,036.68 |
| CloudWatch alarms (10 free) | $1.00 | $1.00 | $1.00 |
| SNS email, under 1,000 a month | $0.00 | $0.00 | $0.00 |
| Monthly total | $56.00 | $208.24 | $1,037.68 |
| Alarm share of the bill | 1.8% | 0.5% | 0.1% |
Canary rows take off the 100 free runs a month. Email is free here because a team of five getting an alert and a recovery for 40 incidents is 400 emails, well inside the 1,000 free, and SNS HTTPS deliveries to a webhook are free up to 100,000 a month.
That last row is the finding. Across all three setups the alarms cost the same dollar, and they never reach 2% of the total. If you are trying to bring an AWS downtime monitoring bill down, trimming alarms is the wrong place to spend the afternoon. The per-check option fees on Route 53, laid out with a calculator in our Route 53 health checks pricing breakdown, and the run count on canaries are where the money is.
Are CloudWatch alarms free?
The first 10 standard-resolution alarm metrics each month are free, which covers a small setup entirely. After that every alarm metric is billed, including alarms that never fire and alarms on resources you deleted months ago. High-resolution, composite, anomaly detection and query-based alarms have no free allowance at all.
Does CloudWatch charge for alarm notifications?
Not directly. The alarm publishes to an SNS topic, and SNS bills the delivery: email is free for the first 1,000 a month and $2.00 per 100,000 after that, HTTPS webhooks are free for the first 100,000 and $0.06 per 100,000 after. Text messages are billed per message by destination, and sending to US numbers requires a registered origination number, which is its own small project.
Does a CloudWatch alarm keep paging during a long outage?
No. Alarm actions run when the state changes, so a site that goes down sends one notification on the move to ALARM and, if you add an OK action, one on recovery. A four-hour outage produces the same two messages as a four-minute one. That keeps SNS costs negligible, and it also means nobody is re-notified unless your incident tooling does the repeating.
How to lower the alarm part of the bill
Delete alarms on resources that no longer exist, since they bill whether or not they have data. Use standard resolution unless a 10 or 30 second period changes what someone does, because high resolution triples the price. Check metric math alarms for metrics that add nothing, since each one is billed. A composite alarm does not save money, it adds $0.50, but it can cut noise by paging once when both the health check and the canary agree something is wrong.
Then look at the bigger line. Keep Route 53 health checks where they drive DNS failover, and drop the optional features on the ones that do not need them. For the public checks that exist only to tell a person the site is down, a flat per-monitor tool usually costs less than the checks alone: UptimeHub Starter watches 20 endpoints every minute for $24 a month billed yearly, with HTTPS, SSL expiry warnings, alerts by email, Slack, SMS and webhook and a status page included, which is under half the $56 Route 53 setup above. The Azure version of the same exercise, where alerting is also about 1% of the bill, is in Azure Monitor alerts pricing for downtime alerts.
Know your site is down before your customers do
Start monitoring your sites, APIs and services from six regions, with alerts by Slack, email, SMS and webhook and a branded status page. Transparent, flat pricing per monitor.