At 2 a.m. nobody opens a dashboard. They open a terminal. If your monitoring stack needs a login, a zoom call and a coffee to tell you what's broken, it has already failed.
Here are the five checks that actually carry you through an incident night — all copy-paste ready.
1. Is the box even alive?
uptime && free -m && df -h /
Load, memory, and the disk that eats weekends first. If df -h / shows above 85%, you have an incident scheduled for later — go fix it now.
2. Is the service answering, not just running?
curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://yourapp.example.com/health
systemd saying "active" means nothing. A 200 in under a second is the only answer that counts.
3. Are the logs screaming before users do?
journalctl -u yourapp --since "15 min ago" -p err --no-pager | tail -20
Error rate in the last 15 minutes predicts tomorrow's outage better than any weekly report.
4. Are your backups real or theoretical?
ls -lt /backups | head -5
A backup directory with last week's timestamp is a resignation letter you haven't written yet. Restore-test one file monthly.
5. What changed before it broke?
git -C /opt/yourapp log --oneline -5
Ninety percent of 2 a.m. incidents are yesterday's deploy. Knowing this one fact turns a four-hour hunt into a four-minute rollback.
None of this requires a SaaS subscription. It requires five commands saved somewhere you can find them at 2 a.m., and the discipline to run them daily.
That's exactly why we built the Ops Starter Kit — the runbook templates, check scripts and escalation cards for small teams without a dedicated SRE — and the Automation Starter Pack for the cron jobs, backup proofs and health-check loops that run these checks for you.
Ship the checks tonight. Your future 2 a.m. self is the customer.
Top comments (0)