Server Monitoring Checklist for Small Teams

Five signals, one alert rule, and a 10-minute weekly review. Written for teams of 2–30 who can't staff a NOC and don't need one — just a system that screams only when it should.

Small teams fail at monitoring in one of two ways. The first is no monitoring at all: you find out from a customer tweet, four hours after the outage started. The second is the opposite — every metric alerts, all the time — and the team installs a mute on the whole channel. Muted alerting is worse than no alerting, because you believe you're covered. Both failures come from the same mistake: treating monitoring as a tooling purchase instead of a 30-minute checklist.

Here's the whole checklist. It assumes nothing fancier than uptime checks and a free tier of whatever you already use.

The five signals that catch 90% of small-team outages

1. Is the service up? (HTTPS check from outside.) One request per minute to your most important URL, from a box that isn't yours (UptimeRobot free tier, a cron job on another VPS, whatever). Must check the status code and the page content, not just TCP connect — a port that answers with a 500 stack trace is not up. Expect 10–20 false alarms a year; still cheaper than one four-hour silent outage.
2. Is the disk filling up? The #1 silent killer of small servers. A log rotation you never configured, a backup directory nobody prunes, a database that grew 3GB in a month. Alert at 80% disk. At 100%, everything fails at once: the database stops writing, your logs vanish, and the postmortem has no evidence.
3. Did the job actually run? (Heartbeat.) Every cron job or scheduled script that matters should ping a dead-man's-switch service (healthchecks.io free tier) when it finishes. Alert when the ping is late. "The backup failed silently on Tuesday and we noticed on Thursday" is the standard small-team horror story, and a heartbeat kills it dead.
4. Are the certificates and domains expiring? SSL cert expired, domain lapsed, payment card on the registrar expired. All three are 30-second fixes that produce full outages. Check expiry at 21 days out, and put the renewals on a calendar that isn't owned by one person.
5. Does the login path work? A synthetic "can a user actually log in and do the one action that pays us" check. This catches what the other four can't: the service is up, the ports are open, but the auth provider is rate-limiting you or the session store is dead. It's the difference between "nobody noticed" and "a user noticed."

The one alert rule that doesn't spam you

Two rules follow from that table. First: every phone-channel alert has a runbook line attached — one sentence saying what to do. "Disk 82% — run du -x / | sort -h | tail, likely /var/log." If the alert fires and the reader's first thought is "so… what do I do?", the alert was misconfigured. Second: anything that can wait until morning goes to email, and email alerts get triaged in the weekly review — see the weekly ops review. A phone channel with 5 alerts a week will be muted by Friday. A phone channel that fires once a month, with a fix attached, is the whole point.

Alert fatigue: the silent outage killer

When the phone channel starts chiming with non-actionable noise (single blips, CPU spikes that mean nothing), teams don't tune the alerts — they turn the channel down. Then the real alert lands in a channel that's been muted for weeks. The countermeasure is cheap and boring:

• Any alert that pages someone and requires no action gets fixed or downgraded within a week. Log it in the alert channel. Non-actionable alerts are bugs in your configuration, not facts about your servers.
• Consecutive-failure logic everywhere. One missed ping from a free-tier monitor is weather; two in a row is data. (Yes, this doubles detection time. From 1 minute to 2. Worth it.)
• Weekly review: count the pages. More than ~5 phone alerts a week means thresholds are wrong. Fix the threshold, not the volume.

The 10-minute weekly monitoring review

Same slot as your patch review (or the weekly ops review):

1. Skim the week's alerts: every one should be either fixed, downgraded, or documented. Any orphan (fired, nobody acted) gets a line in the log.
2. Check disk trend on every host. 80% is the alert line; the weekly review should notice the curve, not the threshold — a disk that grows 5% a week is a known incident waiting for its date.
3. Heartbeat audit: every cron job that matters has a heartbeat, and every heartbeat has an owner.
4. Expiry sweep: SSL certs, domains, and any paid API with a card on file. 21-day rule.
5. One question: "If the phone fired tonight, would the on-call person know what to do?" If no — that's this week's fix. (The on-call rotation template covers who gets the phone; the handover notes what they'll find.)

What you can skip (for now)

You do not need Prometheus, Grafana, ELK, or an observability engineer. Those are tools for teams with more servers than people. A checklist, a free uptime monitor, a dead-man's switch for your jobs, and one disciplined weekly review will outperform an abandoned Grafana dashboard on every metric that matters: time-to-detect, time-to-restore, and how much the team trusts the alerts. Migrate to real dashboards when (a) the five signals genuinely can't see a failure you've had, or (b) you have more than ~5 servers. Not before.

The pattern behind this page is the same one behind the first 30 minutes of an incident: detection is only half the job — the alert has to land on a person who has a card in their hand telling them what to do next. Monitoring without runbooks just moves the panic from the outage to the alert.

---

The Ops Starter Kit Vol. 2 ($27) includes the full monitoring pack — the 5-signal checklist, the alert-rule table, and the 10-minute weekly review card — plus the advanced incident response and continuity templates. Launch week: 30% off any paid kit with code HIVE-LAUNCH30 at checkout.