Uptime is the single most visible reliability metric for any web service. A 99.9% uptime SLA sounds impressive until you realise it permits 8.7 hours of downtime per year. Achieving and proving that number requires monitoring at multiple layers — not just trusting that AWS is always up.
This guide covers every tool AWS provides for uptime monitoring and explains where each one fits in a production observability stack.
Why AWS being “up” doesn't mean your service is up
AWS maintains its own service health dashboard, but an AWS service being healthy doesn't guarantee your application is. Outages often come from:
- Misconfigured security groups blocking traffic after a deployment.
- Application bugs introduced by a code release.
- Database connection pool exhaustion.
- Memory leaks causing containers to crash and restart in a loop.
- DNS misconfiguration after a Route 53 change.
None of these show up on AWS's status page. You need to actively monitor your own service endpoints.
Layer 1: CloudWatch alarms on AWS service metrics
Start with the metrics AWS provides automatically. Every major service emits CloudWatch metrics:
- ALB:
HTTPCode_ELB_5XX_Count,UnHealthyHostCount,TargetResponseTime. - RDS:
DatabaseConnections,FreeStorageSpace,CPUUtilization. - ECS:
RunningTaskCount,CPUUtilization,MemoryUtilization. - CloudFront:
5xxErrorRate,TotalErrorRate,CacheHitRate.
Set alarms on the metrics most directly tied to user impact. An ALB returning 5xx errors is an outage from your users' perspective, regardless of what ECS reports.
Layer 2: Route 53 health checks
Route 53 can perform HTTP/HTTPS health checks against your endpoints from AWS-operated probe servers across multiple regions. If the check fails from a majority of probers, Route 53 marks the endpoint unhealthy and can automatically failover to a backup resource.
# Create a Route 53 health check via CLI
aws route53 create-health-check \
--caller-reference "api-check-$(date +%s)" \
--health-check-config '{
"Type": "HTTPS",
"FullyQualifiedDomainName": "api.yourapp.com",
"ResourcePath": "/api/health",
"Port": 443,
"RequestInterval": 30,
"FailureThreshold": 3
}'Route 53 health checks are useful for routing-level failover but have a limitation: they test connectivity and HTTP response codes, not whether your application is actually functioning correctly.
Layer 3: CloudWatch Synthetics canaries
Synthetic canaries run headless browser scripts or API calls on a schedule and verify that your application behaves correctly end-to-end. Unlike a simple ping, a canary can simulate a user login, click through a flow, or call an authenticated API.
Canaries are ideal for:
- E-commerce checkout flows where availability = revenue.
- Authentication endpoints that don't respond to unauthenticated pings.
- APIs that return 200 but with broken payloads.
The tradeoff: canaries cost more, require maintenance as your app changes, and have a 1-minute minimum interval. They complement rather than replace a basic uptime monitor.
Layer 4: External uptime monitoring
Internal monitoring (CloudWatch, Route 53) runs inside AWS's network. It doesn't reflect what a real user on the public internet experiences. External monitoring solves this by making requests from outside AWS, just like a browser would.
External monitors catch:
- CloudFront being inaccessible due to ACM certificate issues.
- Network path problems between ISPs and your AWS region.
- Origin shield or WAF rules silently blocking traffic.
- CORS misconfigurations causing browser-side failures.
PulseRadar runs external checks every 60 seconds against any HTTP or HTTPS endpoint. When consecutive checks fail, an incident is auto-created and your team is notified — no manual CloudWatch alert wiring needed.
Reporting uptime to stakeholders
Monitoring is internal. Uptime reporting is external — for customers, leadership, and SLA compliance. The best way to report uptime is through a public status page that shows:
- A 90-day uptime history bar for each service component.
- Current status (operational, degraded, partial outage, major outage).
- Incident history with resolution times.
- Upcoming maintenance windows.
This gives stakeholders a self-serve answer to “is it down?” and builds trust by making your reliability track record visible rather than hiding it.
Recommended monitoring stack
- CloudWatch alarms — for infrastructure-level metrics (5xx rates, task counts, DB connections).
- Route 53 health checks — for DNS-level failover between regions or endpoints.
- CloudWatch Synthetics — for critical user flows that require authenticated or multi-step checks.
- External uptime monitor (PulseRadar) — for public-internet availability and user-facing status page.
No single layer catches everything. The combination ensures that any failure — whether in AWS infrastructure, your application code, or the network between AWS and your users — is detected and surfaced before your users are the ones who tell you.