The $0 monitoring stack for a five-person team: what to watch, what to ignore

Big-company monitoring advice doesn't shrink. It assumes a platform team, a paging rotation, and a budget for APM. A five-person team that copies it ends up with seventeen dashboards, no sleep, and still misses the one thing that mattered: the customer-facing thing was down for two hours and nobody noticed.

Here is the opposite: a monitoring stack that costs $0, fits on one screen, and catches ~90% of the incidents a small team will actually have.

Tier 0 — the two questions that matter

Every monitor you add must answer one of these:

1. Can customers use the product right now? (up/down, login works, checkout works)
2. If it breaks, will we know within minutes without a customer telling us?

Anything that answers neither — JVM thread pools, cache hit ratios, disk queue depths — goes on the ignore list until you have a dedicated operator. Monitoring theater is real, and it's the reason small teams stop looking at dashboards entirely.

Tier 1 — outside-in checks (free, ~1 hour to build)

Don't monitor inside the app first. Monitor from outside, like a user:

• Uptime checks on your real user paths, not just /. Log in, add one item, reach the confirmation page. Free options: a 20-line GitHub Action on a cron (every 5 minutes), or UptimeRobot's free tier. Alert to email and a channel someone actually reads.
• The email path. Send one transactional email to a sink address every hour; check it arrives. Email silently dying is the most common unnoticed failure in small SaaS.
• Certificate expiry. One cron + curl -vI https://yourapp.example 2>&1 | grep expire. It still happens to teams with three monitoring tools.

Why outside-in: it tests the whole chain — DNS, CDN, TLS, app, database — the way customers experience it. It can't drift out of sync with your deploys the way internal metrics can.

Tier 2 — the log you actually read

Skip the log aggregator. Do this instead:

• Your app logs one line per failed request, with the error class. One file, one grep.
• A daily cron greps that file for new error classes and posts the count to your team channel: new error classes today: 2 (detail in log).
• You read the channel. That's the whole "observability stack."

The moment the daily message becomes noise you always ignore, you've outgrown this tier — that's the signal to graduate to a real log tool, not before.

Tier 3 — the heartbeat humans

Two artifacts, both free:

• A weekly 15-minute "would we have caught it?" review. Look at the last incident (you'll have one). Ask which monitor should have caught it. Add or fix exactly one check. This is how the stack gets better instead of bigger.
• A one-page "who gets called" card. Names, order, phone numbers, and the first three things each person does. Paper, or one shared doc. When something breaks at 2am, nobody opens a dashboard first — they open the card.

What we deliberately left out (and when to add it)

• Metrics dashboards / APM — add when debugging regularly takes more than an hour of "where is it slow" guessing.
• On-call paging software — add when two people can't reliably cover the alerts you have.
• Synthetic multi-region checks — add when you have customers on more than one continent complaining about different things.

Each of these is a good tool at the wrong stage. The stack above is the stage before them.

When it does break

Monitoring tells you that; it doesn't tell you what to do. That's a different document — a runbook. If you want ours, the first 30 minutes of any incident are free as a checklist, and the full kit covers the small-team version end to end:

• Free checklist: The First 30 Minutes
• Full kit: Ops Starter Kit
• Comms/postmortems: Ops Starter Kit Vol. 2

No signup wall on the checklist. Take it, run one tabletop with your team this month, and sleep better.