AWS Health Check: Route 53, ELB and the Dashboard

An AWS health check can mean three different features, and search results mix all three. Route 53 probes an endpoint you own and can fail DNS over to a backup. A target group probes instances behind a load balancer. The AWS Health Dashboard reports on AWS itself. Only the first is what most people are looking for.

Which one do you mean?

The three share a name and overlap nowhere. Sorting them takes one table and saves an afternoon.

Feature	What it probes	What it can do about a failure
Route 53 health check	Any public endpoint, by IP or hostname	Remove a record from DNS answers, fail over to a backup
ELB target group check	Registered targets in one VPC	Take a target out of rotation
AWS Health Dashboard	AWS services and your account's resources	Nothing, it reports service events

Target groups are covered separately in our walkthrough of the load balancer health check. The dashboard is a status page, not something you configure. That leaves Route 53, which is the rest of this post.

How a Route 53 health check works

Amazon's checkers sit in multiple AWS locations and each one requests your endpoint on a schedule. AWS documents three kinds, and the difference matters more than the settings do.

• Endpoint checks request an IP address or a domain name and judge the response.
• Calculated checks combine other health checks with boolean logic, so a parent goes unhealthy only when several children do.
• CloudWatch alarm checks take their verdict from an alarm state, which is how you get a metric inside your account to drive DNS.

An endpoint check supports a standard interval of 30 seconds or a fast interval of 10, and it flips state after a configurable number of consecutive agreeing observations. Three is the usual threshold. Combine 30 seconds with a threshold of three and a hard failure takes about a minute and a half to register.

Here is the part that catches people out. Because many checkers each run the interval independently, a single endpoint receives far more requests than the interval implies. AWS publishes a troubleshooting note on unwanted health check traffic for exactly this reason. Exclude the path from your access logs and your rate limiter before you turn it on.

Creating an AWS health check

The console is fine for a single check, and the CLI is better when there are ten of them.

aws route53 create-health-check \
  --caller-reference api-prod-2026-09-24 \
  --health-check-config '{
    "Type": "HTTPS",
    "FullyQualifiedDomainName": "api.example.com",
    "ResourcePath": "/healthz",
    "Port": 443,
    "RequestInterval": 30,
    "FailureThreshold": 3,
    "MeasureLatency": true
  }'

Pricing follows the same shape as the configuration. Basic endpoint checks cost $0.50 each per month against AWS endpoints and $0.75 against endpoints outside AWS. Optional features such as HTTPS, string matching, the fast interval and latency measurement are billed on top, as of September 2026 on the Route 53 pricing page. Turning on every option for a dozen endpoints adds up faster than people expect.

What DNS failover actually does

This is the reason to use a route 53 health check rather than any other probe. Attach it to a record in a failover routing policy and Route 53 stops handing out the primary answer once the check goes unhealthy.

The limit is the resolver cache. A record with a 300 second time to live keeps being served downstream long after Route 53 changed its mind. Failover is therefore measured in minutes rather than seconds. Set the TTL on records that participate in failover to 60 seconds and accept the extra queries. Record behaviour under change is worth watching separately, which is the subject of DNS monitoring.

Private endpoints need the CloudWatch route. Route 53 checkers run on the public internet, so a resource in a private subnet cannot be probed directly. Publish a metric, alarm on it, and point a health check at the alarm.

What none of these can tell you

Every feature above is evaluated inside AWS. That is fine until the question is whether a customer on a different network reached you, and no measurement taken inside the thing under test can answer it.

The failure modes that escape are ordinary ones. A certificate on the CloudFront distribution expires while the origin stays healthy. A WAF rule starts refusing a country. A resolver chain outside AWS caches a stale answer. In each case the dashboards inside the account look untroubled.

An outside-in probe closes that gap by starting from a different network entirely. Uptime Room checks the public hostname from six regions as of September 2026, and requires agreement from more than one before a state changes. Egress addresses for allowlisting live on the probe IPs page, and the monitor fields are documented in the API reference.

We tested both layers side by side against a deliberately broken origin. The useful signal was the disagreement between them rather than either alarm. There is an honest boundary here too. An external check reports that users are affected, but it cannot flip a DNS record for you, so keep failover where it belongs.

Common mistakes

Pointing the check at the homepage. It touches the database and every third-party script on the page. Give the check a dedicated route that returns a small body and no secrets.

Leaving the TTL long on a failover record. DNS failover cannot outrun a cache. A 3600 second TTL turns a working AWS health check into a decorative one.

Reading the dashboard as your own uptime. Service events are AWS's view of AWS. Your account can be broken while every service shows green, and the reverse happens too.

Forgetting string matching. An endpoint returning 200 with an error page passes a plain check. Enable the search-string option, or assert on content from a probe that sits outside the account.

Sort the three meanings first, then configure the one you need. For most teams that is a Route 53 endpoint check on the public hostname, a short TTL on the failover record, and a CloudWatch-backed check for anything private.

An AWS health check is a control inside the platform rather than an independent opinion about it, so pair it with a check that runs somewhere else. Our free plan covers that second opinion for ten endpoints without a card, as of September 2026.