A tiny serverless watchdog for my self-hosted sites. When one falls over, my phone buzzes — instead of me finding out three days later when I happen to visit it.
I self-host a few things on a Raspberry Pi that sits one kicked power cord away from oblivion — weather, blog, and rockies on tylerkno.ws. up is the thing that tells me the moment they disappear.
Every 5 minutes an AWS Lambda pokes each site. Goes down → Discord ping. Comes back → another ping. Cert about to expire → heads-up. It runs itself, costs $0/month, and it's already earned its keep.
It's a personal setup, but nothing's hardcoded to me. Swap the site list and the webhook and it's yours — small now, reproducible if it ever needs to be bigger.
| Alert | Fires when | |
|---|---|---|
| 🔴 | DOWN | A site misses 2 checks in a row (~10 min). One ping — it won't nag while it stays down. |
| 🟢 | RECOVERED | It answers again after being down. |
| 🟡 | CERT | A TLS certificate is within 14 days of expiring (a quiet way to go "down"). |
Real alerts from a real 5-minute outage one morning:
flowchart LR
S["⏰ EventBridge Scheduler<br/>every 5 min"] --> L["λ Lambda<br/>Python 3.14 · arm64"]
L -->|"GET, expect 200"| W["🌐 weather / blog / rockies<br/>tylerkno.ws"]
L <-->|"last up/down state"| D[("🗄️ DynamoDB")]
P["🔒 SSM Parameter Store<br/>(webhook, encrypted)"] -->|"read at runtime"| L
L -->|"down / up / cert"| DC["💬 Discord"]
Pure Python standard library plus boto3 (which the Lambda runtime already ships) — zero dependencies to install. The Discord webhook lives only in SSM, never in the repo.
# 1. Stash your Discord webhook (encrypted, out of the repo)
aws ssm put-parameter --name /uptime-monitor/discord-webhook \
--type SecureString --value "https://discord.com/api/webhooks/…" --region us-east-1
# 2. Deploy (no build step — there are no deps)
sam deployThat's it — the schedule starts firing immediately. Full walkthrough, CI setup, and teardown are in docs/setup.md.
- Design & the $0 story — every decision and why, plus how this stays free forever.
- Setup & operations — first deploy, CI, adding sites, troubleshooting, teardown.
- CI deploy policy — the least-privilege IAM the pipeline runs on.