AWS uptime monitoring: AWS website uptime monitoring, CloudWatch uptime monitoring and external AWS uptime checks
Short answer: CloudWatch tells you how your AWS resources are behaving. It does not tell you whether a customer in Denver can load your site, because every native option runs inside the same account and the same network you are trying to measure. CloudWatch Synthetics canaries execute on Lambda in a region you choose; Route 53 health checks run from AWS infrastructure and cannot notify anyone until you wire them to a CloudWatch alarm and an SNS topic. External uptime monitoring is the independent second opinion, and it is also the only record you can hand to AWS when you claim a service credit, because the SLA makes you supply the logs. The three options are priced and compared below.
Last updated August 2026 · US dollar list prices, us-east-1
alertping ▸ run check
live
▸ type a domain and run a real-feel check
▸ probes from 3 regions · FRA · IAD · SIN
▸ waiting…▌
queued probing▌
If ever goes down, you get:
Alert fired ▸ 2 channels · 6.2 s after first failure
AlertPing app
● DOWN : HTTP timeout confirmed from 3/3 regions (FRA, IAD, SIN). Incident opened.
sms · on-call
AlertPing: DOWN. Confirmed 3/3 regions . First fail: Frankfurt.
read this first
Native AWS monitoring sits inside the thing it is watching
This is the whole argument, and it is not a marketing point. It is an architecture point that every SRE team relearns during its first regional event. Monitoring that shares a failure domain with the service goes quiet at exactly the moment you need it loudest, and a monitor that goes quiet looks identical to a service that is fine.
Inside the account
CloudWatch, Synthetics, Route 53 health checks
These see things nothing else can: CPU and memory on an instance, ALB target health, SQS queue depth, RDS connection counts, Lambda error rates. That visibility is real and you should keep it. What they cannot do is answer the question your customer is asking, which is whether the page loaded from where they are sitting.
A canary is a Lambda function. If the region degrades, the canary degrades with it, the metric stops arriving, and a CloudWatch alarm with the default missing-data treatment simply holds its last state instead of firing.
None of this is an AWS failing specifically. The identical argument applies to Azure uptime monitoring, where Application Insights availability tests run on Azure infrastructure and alert through Azure Monitor action groups, so the checker, the store and the notification path all sit inside the tenant being measured. It applies to GCP uptime monitoring too, where Cloud Monitoring uptime checks run on Google Cloud and feed a Google Cloud alerting policy. It reaches its sharpest form on application platforms: with Vercel uptime monitoring there is no built-in outside-in check at all, because every signal Vercel records begins with a request that already arrived.
Outside the account
Third-party uptime monitoring
Runs on somebody else's infrastructure, on somebody else's network, with its own alerting path. When your region has a bad morning, the thing telling you about it is not in that region. It also measures what a customer measures: DNS resolution, TLS handshake, the actual HTTP response, and the time all of that took.
AlertPing confirms every failure from three regions (Virginia, Frankfurt, Singapore) before it counts as downtime, so one flaky checker does not page your on-call at 3am.
The practical answer for most teams running on AWS is both, not either. Keep CloudWatch for resource metrics and internal alarms, keep Route 53 health checks if you use them for DNS failover, and add an external check on every endpoint a customer touches. The section below prices that third piece honestly, including the case where AWS is cheaper than we are.
the comparison
Four ways to run an AWS uptime check, compared
The column people skip is "alerts a human by itself". Two of the four native options produce a signal and stop there, which is how teams end up with a beautifully instrumented stack and nobody who found out about the outage before a customer emailed.
| Option | What it actually measures | Where it runs | Fastest interval | Alerts a human by itself | Best for |
|---|---|---|---|---|---|
| CloudWatch metric alarms | Resource and service metrics your AWS services already emit: ALB 5xx counts, target health, EC2 CPU, Lambda errors | Inside your account and region | 10 seconds (high resolution) | Only with an SNS topic attached | Knowing which component broke |
| CloudWatch Synthetics canaries | Scripted Puppeteer or Playwright runs against a URL or API, including multi-step browser flows | Lambda, in a region you pick | 1 minute (rate expression) | Only with an alarm plus SNS | Real browser journeys, checkout flows |
| Route 53 health checks | Endpoint reachability, optional HTTPS and response string matching | AWS health checker fleet | 10 seconds (billed as an optional feature) | No, health checks do not notify | Automatic DNS failover |
| AlertPing | What a customer gets: DNS, TLS, HTTP status, response body assertions, JSON path, response-time budget, port and TLS expiry | Outside AWS entirely, three regions | 30 seconds on Team, 15 seconds on Enterprise | Yes: SMS, email, Slack and webhook on every plan | Proving availability and waking someone up |
Two honest notes on that table. CloudWatch alarms can evaluate every 10 seconds and we only reach 15 seconds on a custom Enterprise plan, so on raw interval AWS wins. And Synthetics runs real browser scripts, which we do not do at all. If your requirement is "log in, add to cart, check out, assert the confirmation page", that is Synthetics or a synthetic monitoring platform, not us.
what it costs
What 20 AWS uptime checks actually cost per month
"Native AWS monitoring is free" is the belief that survives right up until the bill. It is free at tiny scale and metered everywhere else, and the metering is per feature rather than per plan, so the cost arrives in pieces. Here is the same job, 20 endpoints watched continuously, costed across all four options. An average month is 30.44 days, or 43,834 minutes.
| Setup | Unit price (USD, us-east-1) | 20 checks per month | What is still missing |
|---|---|---|---|
| Route 53, basic check on an AWS endpoint | $0.50 per health check per month, and AWS publishes a free allowance of up to 50 health checks on AWS endpoints | $0.00 inside the allowance | No HTTPS, no string matching, 30-second interval, and no notification of any kind |
| Route 53, AWS endpoint with HTTPS, string matching and fast interval | Optional features are $1.00 each per month on AWS endpoints, and three are in use | $60.00 | Still no notification: add a CloudWatch alarm per check at $0.10, plus SNS delivery |
| Route 53, non-AWS endpoint with the same three features | $0.75 basic plus $2.00 per optional feature, so $6.75 per check | $135.00 | Same: alarms and SNS are separate |
| CloudWatch Synthetics at a 5-minute rate | Canary runs are billed per run after the first 100 free per month; 8,767 runs per canary | Roughly $210 in canary runs alone | Lambda duration, CloudWatch Logs, S3 artifacts and custom metrics are billed on top |
| CloudWatch Synthetics at a 1-minute rate | 43,834 runs per canary per month | Roughly $1,052 in canary runs alone | Same additions, and they scale with run count |
| AlertPing Starter | $19 per month, or $15 billed annually | $19.00 flat, covering 20 monitors | 60-second interval on this tier, 1 status page |
| AlertPing Team | $59 per month, or $47 billed annually | $59.00 flat, covering 100 monitors | Nothing for this job: 30-second checks, unmetered SMS, escalation chains, 5 status pages |
Sourcing, because this is the part everyone gets wrong. The Route 53 figures come straight from the AWS Route 53 pricing page and are unambiguous. The Synthetics per-run rate is the one number AWS does not print plainly on its CloudWatch pricing page, which states the 100-run monthly free tier and then sends you to the calculator; third-party pricing breakdowns published through 2026 put it at $0.0012 per canary run, and that is the figure used above. Treat the Synthetics rows as an order of magnitude rather than a quote, and confirm against your own bill before you budget. The direction of the answer does not change: a per-run meter at a one-minute interval is expensive, and that is before Lambda, Logs and S3.
Where AWS is genuinely cheaper: if you need 20 plain reachability checks on AWS endpoints, no HTTPS validation, no string matching, no fast interval, and you already have an SNS topic wired to a distribution list, Route 53 does that inside the free allowance and we cost $19. That is a real scenario and we are not going to pretend otherwise. It stops being true the moment you want to know that the page contained the right content, or you want somebody's phone to ring.
how it works
Monitoring an AWS stack from outside, in four steps
1
Point at the public edge
Monitor the hostname customers use, so the CloudFront distribution, the ALB DNS name or the API Gateway stage URL. Checking a private ALB from outside will simply fail, and checking an instance IP skips the two layers most likely to break.
2
Assert on content, not just status
A 200 with an empty body is the classic AWS failure: the ALB is healthy, the app returned a cached error page. Assert a keyword, a JSON path, or a response-time budget so a degraded deploy registers as an incident rather than a green tick.
3
Add a heartbeat for the async half
SQS consumers, EventBridge schedules, Glue jobs and nightly exports have no URL to poll. Have them call a heartbeat URL on success; if the ping stops arriving inside the window, you get paged. Silence is the failure mode nothing else catches.
4
Route the alert to a person
SMS, email, Slack and webhook on every plan, unmetered, with no credit packs to run dry mid incident. On Team and above an escalation chain moves the alert on if the first responder does not acknowledge it.
the part that pays for itself
The AWS SLA makes you prove the outage
People assume AWS credits arrive automatically when a region has a bad day. They do not. The Compute SLA puts the burden of proof on the customer, with a deadline, and the evidence it asks for is exactly the sort of thing an external monitor produces and an internal one may have lost.
The commitment
Amazon EC2 commits to 99.99% monthly uptime at the region level across multiple availability zones, and 99.5% for an individual instance. At 99.99% the entire monthly allowance is 4 minutes 23 seconds. A five-minute check interval cannot resolve that: one missed check is longer than the whole budget.
The remedy
Credits are tiered: 10% for monthly uptime from 99.0% up to 99.99%, 30% from 95.0% to 99.0%, and 100% below 95.0%. Region-level and instance-level claims cannot be combined for the same instance, and AWS does not issue a credit worth less than one dollar.
The catch
You file the claim through AWS Support by the end of the second billing cycle after the incident, with dates and times, the affected regions, resource IDs, and request logs showing the errors. No evidence, no credit. An independent check history with timestamps is the cleanest evidence you can attach.
The same logic runs downhill to your own customers. If you sell on AWS under an availability commitment of your own, the number in your monthly report needs to come from a measurement neither side controls. That is SLA monitoring, and the mechanics of claiming and paying credits are in SLA service credits.
what to watch
What to put an external check on, service by service
A useful rule: if a customer or a paying integration talks to it, it needs a check from outside. If only your own code talks to it, a CloudWatch alarm is usually the better tool.
CloudFront and S3 static sites
Check the distribution hostname and assert a string from the rendered page. A broken deploy that uploads an empty index file still returns 200, so status code alone will not catch it.
Application Load Balancer
ALB target health tells you the target passed a health check on port 8080. It says nothing about DNS, TLS or the path a browser takes to reach it. Check the public hostname over HTTPS.
API Gateway and Lambda
Check a real stage URL with the headers a client sends, and assert a JSON path in the response. Throttling and authorizer misconfiguration both return valid HTTP that a status-only check calls healthy. More on API monitoring.
RDS and Aurora
You cannot and should not expose a database to a monitoring service. Instead expose a small health endpoint in your app that runs one trivial query, and check that. A failover then shows up as a real user-visible event.
SQS workers and scheduled jobs
Nothing to poll, so use a heartbeat. A consumer that silently stops draining a queue is the outage nobody notices for a day. This is the dead man's switch pattern.
TLS certificates
Certificates issued by ACM and attached to CloudFront or an ALB renew themselves, so this matters less than it does elsewhere. It matters a lot if you terminate TLS yourself on EC2 with a certificate ACM never sees. Expiry checks are on every plan.
where we are the wrong tool
Four AWS jobs we do not do
Resource metrics and infrastructure alarms
We have no server agent. CPU, memory, disk, queue depth, RDS connections and Lambda concurrency are CloudWatch's job and we are not trying to replace it. Keep your alarms.
Scripted browser journeys
No Puppeteer, no Playwright, no multi-step login and checkout. Our API checks are single requests with assertions. If you need a recorded journey, Synthetics and Checkly do this and we do not.
DNS failover
A Route 53 health check can flip a record and route traffic away from a sick endpoint automatically. We tell a human. If automated failover is why you have health checks configured, keep them and add us alongside.
Cost, security and log analysis
No Cost Explorer, no GuardDuty findings, no log search, no traces. We answer one question well: is it up, from outside, and who needs to know it is not.
questions people ask
AWS uptime monitoring questions
What is AWS uptime monitoring?
AWS uptime monitoring is the practice of checking that services you run on AWS are reachable and returning correct responses, on a fixed schedule, and alerting someone when they are not. It splits into native tooling inside your account (CloudWatch, Synthetics, Route 53 health checks) and external checks run from outside AWS, which are what prove availability to a customer.
Does AWS CloudWatch monitor uptime?
Indirectly. CloudWatch alarms watch metrics your AWS services emit, such as ALB 5xx counts or unhealthy target totals, and CloudWatch Synthetics canaries can request a URL on a schedule. Both run inside AWS, so neither is independent evidence of availability, and neither notifies anyone until you attach an SNS topic.
What is the AWS uptime SLA?
Amazon EC2 commits to 99.99% monthly uptime at the region level across multiple availability zones, and 99.5% for a single instance. Falling below the region commitment earns a 10% service credit, 30% below 99.0%, and 100% below 95.0%. Other AWS services publish their own SLAs with different numbers, so read the one for the service you use.
How do I check AWS uptime?
For AWS itself, the AWS Health Dashboard reports service events, and your personal Health Dashboard reports events affecting your account. For your own workloads, configure an external HTTP check against the public hostname at an interval fine enough to resolve your target, and keep the raw results as your availability record.
How do I monitor a website hosted on AWS?
Point a check at the hostname customers use rather than an instance IP, request it over HTTPS, and assert on a string from the page as well as the status code. Add a certificate expiry check if you terminate TLS yourself, alert to a channel someone actually watches, and confirm failures from more than one region before paging.
Is there a free AWS uptime checker?
AWS publishes a free allowance of up to 50 Route 53 health checks on AWS endpoints, which is the closest thing. It covers plain reachability only: HTTPS, string matching and the fast interval are billed optional features, and health checks cannot notify anyone without a CloudWatch alarm and an SNS topic behind them.
What are AWS monitoring best practices?
Instrument inside and outside. Use CloudWatch for the resource metrics that tell you which component failed, and an independent external check for the customer-facing answer of whether it worked at all. Set alarm thresholds against your error budget rather than round numbers, and treat missing data as a failure, not as healthy.
Why not just use Route 53 health checks?
Use them if you want DNS failover, because nothing else gives you that. As a monitoring product they are thin: no notifications on their own, no history you can export as a report, and every useful capability priced as a separate optional feature at $1.00 or $2.00 per check per month depending on whether the endpoint is inside AWS.
Does AWS tell you when your website goes down?
No. AWS tells you when AWS is having a problem, through the Health Dashboard. If your own deploy, certificate, DNS record or application breaks while every AWS service is healthy, AWS has nothing to report and will not contact you. That gap is what website down alerts exist to close.
How often should an AWS uptime check run?
Fine enough that one missed check is smaller than your downtime allowance. At 99.9% you have 43 minutes 50 seconds a month and a one-minute check is fine. At 99.99% you have 4 minutes 23 seconds, so 30 seconds is the practical floor and a five-minute check is worthless. The reasoning is in how often you should check uptime.
Watch your AWS stack from outside your AWS account
AlertPing checks your CloudFront, ALB and API Gateway endpoints as often as every 30 seconds, confirms every failure from three regions before it counts as downtime, and sends SMS, email, Slack and webhook alerts on every plan with no credit packs. Flat pricing from $19 a month.