I've had three side projects go down silently over the past year and only found out because someone emailed me asking why the page 404'd. Not great. So a couple weekends ago I finally sat down and built myself a tiny status/uptime setup instead of doing the thing I always do, which is bookmark some SaaS tool, sign up for a free trial, and then forget about it until it starts charging me $29 a month for a feature I use maybe twice a year.
Here's roughly what I ended up with, in case anyone else has been procrastinating on the same problem.
The checker
The core of it is embarrassingly small. A bash script that curls each site, checks the HTTP status, and writes a line to a log file:
#!/bin/bash
SITES=("https://example1.com" "https://example2.com" "https://example3.com")
for site in "${SITES[@]}"; do
code=$(curl -o /dev/null -s -w "%{http_code}" --max-time 10 "$site")
echo "$(date -u +%FT%TZ) $site $code" >> /var/log/uptime.log
if [ "$code" != "200" ]; then
./notify.sh "$site returned $code"
fi
done
I run that from cron every five minutes on a small VPS. Nothing fancy, no Docker, no dashboard framework, just a text file that grows forever until I remember to logrotate it. I did not remember to set up logrotate for the first three weeks and the log file hit 40MB before I noticed, which tells you something about how often I actually go check on this stuff myself.
The alerting part
This is the part that actually matters, because a status page nobody's looking at is useless. You want to know the second something's broken, not scroll a dashboard once a week hoping everything was fine the whole time. I wired the notify script to send an email through a simple sending API instead of fussing with SMTP auth directly on the VPS, since half the time that gets flagged as spam anyway and you spend an evening messing with SPF records instead of actually building anything. I already had domains and a VPS running through Tricknowtech for a couple of these projects, so I just used their email API for it too, one curl call from notify.sh and I get an email within a few seconds of a site returning a 500.
The actual "status page"
This is the part I overthought for way too long. I didn't need Statuspage.io, I didn't need a real-time dashboard with uptime graphs and incident history. I needed one plain HTML file that reads the last line of each site's log and shows green or red next to the name. A short Python script regenerates that file every five minutes right after the checker runs, cron drops it in the right folder, done. It's ugly. It looks like a webpage from 2009, which, fine, this blog kind of does too if we're being honest with ourselves here.
I did originally try to get clever and have the page auto-refresh with a bit of JavaScript polling a JSON endpoint every thirty seconds. It worked fine. It was also solving a problem I don't actually have. Nobody is sitting there staring at this page waiting for it to flip from red to green. It gets looked at maybe once a month, usually by me, and usually after I already know something's wrong because the email already told me an hour earlier. The clever version added maybe forty extra minutes of work for zero real benefit. I do this constantly with side projects, build the interesting version instead of the useful version, and I'm trying to get better at catching myself doing it before I sink an evening into it.
Was it worth it
Kind of. It ate most of a Saturday afternoon, including a solid forty-five minutes where I got distracted reading about cron syntax edge cases for no good reason. But I haven't paid a monthly fee for uptime monitoring since, and when a caching bug took one of my sites down for about ninety minutes back in June, I had an email sitting in my inbox at 11:47pm instead of finding out two days later from a confused visitor. If you've got two or three things running and keep meaning to set up "real" monitoring one of these days, you probably don't need real monitoring. You need a cron job, a curl command, and a text file that turns red when something's wrong.