Website Uptime Monitor with Email Alerts
Build a Bash monitor that checks your websites every few minutes with curl, records each check's status code and response time in a CSV history, and emails you with mailx when a site goes down or becomes too slow, and again when it recovers, without sending the same alert over and over. It runs from cron, keeps its state between runs, rotates its history file, and includes recent history in each alert so you can see what happened. Only monitor sites you own or manage. You'll learn curl's --write-out for timing, cron scheduling, keeping state between runs, avoiding alert spam with state transitions, sending email from the command line, log rotation, and testing shell scripts.
- Estimate
- ~9h
- Steps
- 7
- Completed by
- 0
- Proposed by
- codeseed.app
curl · cron · mailx
Project roadmap
- 01
Create the watchlist
~1hWrite a config file format: one site per line with a name, URL, expected status codes (such as 200 or 200,301) and a slow threshold in milliseconds, plus global settings (alert email address, timeout and how many failed checks in a row mean down). Write README.md describing it. Done when: README.md and a sample config are written.
- 02
Check each site with curl
~1.5hWrite monitor.sh with set -euo pipefail that reads the config and, for each site, runs curl --silent --output /dev/null --max-time N --write-out "%{http_code} %{time_total}" (following redirects if configured), and classifies the result as up, slow, down (wrong status) or unreachable (curl error or timeout). Done when: running the script prints each site's status and time.
- 03
Record the history
~1hAppend each check to history.csv (timestamp, name, status code, time in ms and classification), writing the header only when creating the file. Done when: each run adds one line per site.
- 04
Alert only on changes
~2hKeep each site's state (up, slow or down, the number of consecutive failures and since when) in a state file. A site is declared down only after N failed checks in a row, and an alert is sent only when the state changes (up to down, down to up, up to slow and slow to up), never repeatedly for the same state. Protect the state file with flock so overlapping runs can't corrupt it. Done when: a site that stays down sends one alert, and one recovery message when it comes back.
- 05
Send email alerts
~1hSend alerts with mailx (or sendmail), with a subject such as [DOWN] shop.example.com and a body with the time, status, how long it's been down, and the last 10 checks from the history (extracted with grep and tail). Add a --test-email option to check the email setup. Done when: a test alert arrives in your inbox with the recent history.
- 06
Schedule and rotate logs
~1hAdd a crontab line running the monitor every 5 minutes (with full paths, since cron has a minimal environment, and output redirected to a log), and a weekly rotation of history.csv (with logrotate or a small rotation step in the script that compresses old files and keeps 8 weeks). Done when: the monitor runs from cron, and old history is rotated.
- 07
Test it
~1.5hTest with a local server you can stop, slow down and make return errors (for example a small Python script), and with a fake mailx that records messages instead of sending them. Write bats-core tests for classification, state changes, no repeated alerts and history lines, and run shellcheck. Done when: the tests pass, and shellcheck reports no warnings.
Resources
Ready to build this?
Get a GitHub repo and start building. Your AI reviewer checks each step as you go.
Tech stack