Monitor your services and run your own status page
Run your own uptime monitor in one container, point it at real services, and get a public status page with response times, TLS and content checks, and alerts that fire only when something is actually wrong. You break a service on purpose, watch it go down and recover, and learn why thresholds and deduplication keep alerts worth reading.
config.yaml you can read, back up and version- Alert thresholds and deduplication set up so a single blip stays quiet, plus a starter kit (Gatus config, compose file, a breakable demo service, a webhook receiver)
- Docker installed and working. New to it? Do Docker without fear first: this mission uses the same
docker compose up -d, volumes and127.0.0.1port habits. - The terminal basics from Level 0: opening a terminal, pasting a command, and
cdinto a folder. - About 200MB of disk space for the images (Gatus is a 71MB download, the Python base image 79MB) and a few spare minutes to watch a check recover.
Why monitor, and why a status page
The words in every monitoring tool mean specific things. Five minutes on them now makes the config file in step 2 read like plain settings.
Uptime monitoring is a service outside your app that checks, on a schedule, whether the app is working, and records the answer over time. This is active monitoring: the monitor reaches out and tests the service itself, every few seconds. That is different from passive monitoring, which waits for signals the app already produces, such as error logs or a drop in traffic. Active monitoring notices a problem even when nobody is using the app, which is exactly when you want to find out.
Each test is a health check. The three kinds you will use here:
- HTTP check: ask for a URL and look at the reply. A
200status means the server answered normally; most other codes, or no answer at all, mean trouble. - TCP check: open a connection to a host and port without speaking HTTP. Useful for databases, mail servers and anything that is not a website.
- Keyword (content) check: read the reply body and confirm an expected word or value is in it. A login page can return
200while showing a stack trace; a keyword check catches that.
- HTTP check: ask for a URL and look at the reply. A
Two more terms. Response time (also called latency) is how long the service took to answer. A service can be up but slow, and slow is often the first sign of a service about to fall over. Uptime percentage is the share of checks that passed over a period. It is the plain-English version of an SLA (service level agreement), the promise a provider makes about availability. The gap between the nines is larger than it looks:
- 99% uptime allows about 7 hours 18 minutes of downtime a month.
- 99.9% ("three nines") allows about 43 minutes a month.
- 99.99% ("four nines") allows about 4 minutes 20 seconds a month.
A status page is the public, read-only view of all this: a simple page that shows each service as up or down, with its recent history and response times, so you (and anyone who depends on you) can see the picture without logging in. An incident is a period when a service was failing its checks, from the moment it went down to the moment it recovered. That is the whole job: check often, record honestly, show it clearly, and tell someone when it matters.
TipThis mission uses Gatus because its entire setup is one YAML file, which makes it reproducible and easy to read. Uptime Kuma is the popular alternative with a click-through web interface instead of a config file; Docker without fear runs it. The ideas here (checks, thresholds, alerts, a status page) are the same in both.