CloudWatch Synthetics Canaries (2026): Production Guide for Journey Probes That Actually Page

On July 22, 2026, customer-facing availability on AWS is still measured poorly when teams rely only on EC2 or container “healthy” metrics. CloudWatch Synthetics canaries probe the journey a user actually takes — login, checkout, critical API — on a schedule you control. Done well, they are the sharp end of monitoring vs alerting. Done poorly, a fleet of 1-minute browser canaries becomes a CloudWatch line item that rivals the app.

This guide covers when to use heartbeat vs browser canaries, VPC pitfalls, alarm wiring to Application Signals SLOs, and cost levers. Confirm current runtimes and prices on the CloudWatch Synthetics docs and pricing page.

Opinionated Defaults

Opinionated take: One excellent checkout canary beats ten CPU alarms. Pair it with an Application Signals SLO on the same path (SLA/SLO design).

Reproduce this — Follow the Synthetics canary checklist: name the journey, pin runtime, set VPC if private, wire SuccessPercent alarm, link to an SLO, and estimate runs/month ≈ (43,200 / interval_minutes) × canary_count.

Heartbeat vs Browser

• Heartbeat / API canaries — Fast, cheap, stable. Assert status codes and JSON fields.
• Browser canaries — Required when the failure mode is client-side (broken JS bundle, auth redirect loop). Heavier artifacts and more flakiness.

VPC and Private Targets

Private ALB or internal APIs need canary VPC config. Failures usually come from:

1. Wrong subnet (no path to target or to CloudWatch)
2. Security groups blocking canary ENIs
3. Private DNS not resolving the hostname the script uses

Treat VPC canaries as a networking change with a rollback plan.

Alarms That Should Page

Page on SuccessPercent (or blueprint equivalent) sustained below threshold — not on every transient blip. Use two evaluation periods. Put the runbook URL in the alarm description. See monitoring vs alerting for ownership rules.

Wire the same journey into Application Signals SLOs so a canary fail and an SLO burn describe one incident. Instrumentation for the app itself should be ADOT / Application Signals, not net-new X-Ray SDKs (maintenance mode since February 25, 2026).

What broke — A team set 12 browser canaries at 1-minute intervals against staging and production. Monthly Synthetics + artifact storage spiked; staging noise trained on-call to ignore failures. Production checkout outage was delayed by 20 minutes of alert fatigue. Fix: delete staging pages, keep two production canaries at 5 minutes, page only on production SuccessPercent.

Cost Levers

1. Interval (largest)
2. Canary count
3. Browser vs API
4. Artifact retention

Model the CloudWatch stack with the observability stack calculator and the Synthetics dimensions in the CloudWatch pricing post.

What to Do This Week

1. List Tier-1 user journeys (≤ 3).
2. Create or retune one canary per journey using the checklist.
3. Attach alarms with owners; disable Slack-only noise.
4. Align Application Signals SLOs to the same journeys.
5. Need hands-on ops? Managed services or contact us.

What This Post Doesn’t Cover

• Every Synthetics runtime blueprint matrix (pin from current AWS docs).
• CloudWatch RUM / Core Web Vitals (separate guide).
• Third-party synthetic vendors (Pingdom, Catchpoint) comparisons.