Every monitoring recommendation for small teams starts the same way: "just set up Datadog." For a team of 3 running four cron jobs, that's like installing airport security for a garden shed. The tooling isn't the bottleneck — the budget isn't either. What's missing is a stack decision: what you watch, what wakes you, and what you deliberately ignore.
Here's the $0 monitoring stack we run for a small ops lab. Four free tiers, one dead-man's switch, zero credit card.
Layer 1: Dead-man's switch (the most important $0 you'll never spend)
A dead-man's switch answers the only question that matters at 2am: did the job even run? Not "did it succeed" — did it run at all.
The pattern: every recurring job ends with curl https://hc-ping.com/<uuid>. Healthchecks.io's free tier (20 checks) or cron-monitor alternatives receive the ping. If a ping doesn't arrive on schedule, they email you. The monitor runs on someone else's server, which is the point — when your box dies, your monitoring doesn't die with it.
This catches the failure mode every team eventually meets: the job that silently stopped three weeks ago because a dependency moved. Green logs, zero output.
Layer 2: Outside-in uptime pings
Dead-man's switches watch jobs. Uptime pings watch things users touch — the site, the API, the webhook endpoint. UptimeRobot's free tier (50 monitors, 5-minute intervals) is enough for any small team's public surface.
The discipline that makes it useful: one monitor per user-visible thing, named for the user, not the host. "Checkout flow" not "web-3". When the alert fires at 2am, the name should tell you what customers can't do, not which machine to SSH into.
Layer 3: Run logs + the 10-minute review
Free, boring, and the highest-signal layer: every automation appends one JSON line to a log — timestamp, job, outcome. Then one calendar slot per month: read the logs, answer three questions (when did it last run, when did a human last look, what happens if it stops), kill or fix one thing.
We ran this against our own four-job stack and caught a zombie job that had "succeeded" 60 times against a dead URL. The log was green for two months. The review was the only thing that ever read it.
Layer 4: Alert routing that respects sleep
Free email alerts default to noise. Two rules make them survivable:
- Crawl-tier alerts (a ping missed once, a 5-minute blip) go to a folder, never a phone. Batch-read them weekly.
- Page-tier alerts (checkout down, dead-man's switch fired, three consecutive failures) go to the phone — but only after a bounded retry, because three restarts that fix it beat one page at 3am that wouldn't have.
The routing rules are where small teams actually fail. The tools are free; the judgment isn't, so write it down.
What we deliberately don't monitor
Metrics nobody reads, dashboards nobody opens, host-level stats on machines that run two cron jobs. A $0 stack stays $0 partly by refusing to watch things. If a metric has never changed a decision, deleting it is monitoring work too.
When to graduate
You outgrow this stack when: you have more than ~10 automations, more than one person is paged, or an incident costs more than a tool subscription. Until then, the free tiers plus written judgment cover the real risk.
The paperwork layer
We build the decision paperwork around this stack: Agent Ops 24/7 — The Solo Operator's Playbook covers unattended-agent monitoring, escalation ladders, and the watchdog patterns that page a human only when a human is actually needed — https://hive80lab.gumroad.com/l/agent-ops-24-7 (30% off launch month, code HIVE-LAUNCH30).
Start free: The First 30 Minutes is a one-page incident quick-start checklist, no email needed — https://hive80lab.gumroad.com/l/first-30-minutes
And the 10-minute review sheet above ships inside The Automation Starter Pack — https://hive80lab.gumroad.com/l/automation-starter-pack
Honest scope: free tiers change limits often — verify current quotas before relying on them. The stack's value is the design, not the vendor.
Top comments (0)