This is the sixth post in a series documenting the build of tacedata.ca — moving from WordPress to a Hugo static site on AWS. Stage 1 chose Hugo and PaperMod. Stage 2 migrated email. Stage 3 built the deploy pipeline. Stage 4 built out the site. Stage 5 cut over DNS.

The site is live. The next question is: how do we know if it goes down?

A static site on CloudFront is more resilient than a WordPress site on shared hosting, but it is not infallible. The S3 bucket could have a misconfigured policy. The CloudFront distribution could have a bad configuration change applied. DNS could drift. Any of these would take the site down silently — no error thrown, no notification sent.

The answer is availability monitoring. We want something that checks the site on a schedule and sends an alert when it stops responding.

why CloudWatch over a third-party tool

The simple answer is that we are already in AWS. CloudWatch Synthetics is an AWS-native monitoring tool that runs a small script on a schedule, checks the response, and reports results as metrics. Those metrics feed into CloudWatch Alarms, which publish to SNS, which sends an email.

The entire chain stays inside the AWS account — the same place as the S3 bucket, CloudFront distribution, and Route 53 zone. No third-party service, no additional account to manage.

Cost at this scale is negligible — under $0.15/month.

what we set up

Five resources:

  1. S3 bucket — stores canary run artifacts (results, screenshots). Required by CloudWatch Synthetics. A separate bucket from the one holding the site content — mixing the two would complicate the bucket policy and make the content harder to manage.
  2. IAM role — the canary runs as a Lambda function. It needs permission to write to S3 and publish CloudWatch metrics.
  3. CloudWatch Synthetics Canary — a Node.js script that hits https://tacedata.ca every 5 minutes and checks for HTTP 200.
  4. CloudWatch Alarm — monitors the canary’s success metric. Triggers after 2 consecutive failures — avoids false positives from transient blips.
  5. SNS Topic + Email subscription — the alarm publishes to SNS; the email subscription delivers the alert.

what it monitors

The canary checks two things: that the site responds, and that it responds with HTTP 200. A 403, 503, or timeout all register as failures.

The 5-minute interval means we know about an outage within 10 minutes at most — two failed runs before the alarm triggers. That is acceptable for a personal site.

the runbook

The full setup — IAM policy, canary script, alarm configuration — is in the repository.

CloudWatch monitoring runbook

tacedata.ca project write-up

Scott

The build series ends here. What happened next: security remediation — what we got wrong — a post-launch security review found sensitive AWS identifiers committed to the public repo.