build log · 9 entries · in progress

Service Monitor: the build log

A monitor that keeps an eye on your websites and tells you, honestly, when something breaks. Written in Rust, built in the open, one tested step at a time.

Service Monitor keeps an eye on your websites and services. Every minute, it checks that they answer properly. When one stops answering, you get one alert, with the evidence. When it’s back, you get one “all good”. No alert storms.

It’s the first piece of a bigger plan: tools that make AI apps easier to run, and easier to fix when they break.

I’m building it in Rust with Claude Code, and writing up every step here, including the mistakes.

The rules it lives by

  • No green without proof. If it didn’t check, it says “unknown”, never “fine”.
  • One check, one try. No hidden retries that hide problems or pile onto a struggling service.
  • Everything has a limit: time, retries, memory and disk.
  • Written in Rust, where every piece of data has exactly one owner and things clean up after themselves.
  • No bragging without numbers. No speed or memory claims until a 24-hour test backs them up.

Early days: nothing here is production-ready yet.

M0 one check

A single check, tested against four kinds of failure.

  • day 0 experiment
    I read the code first. It found 4 traps.

    Before building my uptime monitor, I checked how its libraries really behave. Four surprises, any of which would have quietly broken it.

  • 0.1 experiment
    Rules first, code second

    An empty project sounds boring. It's also the cheapest moment to decide what the compiler should never let me do.

  • 0.2 experiment
    Making bad settings impossible

    Instead of checking settings everywhere they're used, check them once at the door, then make them impossible to change.

  • 0.3 experiment
    127.0.0.1 has a lot of disguises

    How I stopped my monitor from being tricked into poking around a private network, and three attacks the tests had to catch.

  • 0.4 experiment
    A test server that fails on purpose

    Eight ways for a server to have a bad day, on demand, and why throwing away one object shuts all of them down.

  • 0.5 experiment
    The first real check

    My monitor can finally look at a website and tell the truth about it. Plus two of my own mistakes that the tests caught.

  • 0.6 experiment
    A command you can actually run

    The monitor gets a front door: one command, clear answers, and exit codes a script can trust. Using it for real found two rough edges.

  • 0.7 experiment
    I let a tool attack my code. It found 19 holes.

    Hand-picked tests said everything was fine. Automatic mutation testing, random inputs and 400 checks at once disagreed.

M1 checking on repeat

Checks every minute with no overlaps, watches a real Node.js app under load, and gets its first dashboard.

  • 1.1 experiment
    I pushed a real app until it broke, and watched

    A small Node.js API, traffic climbing from 20 to 400 requests a second, and my monitor checking every second. It saw trouble 20 seconds before users did.

  • 1.2
    Checking on repeat, with a confirmation rule

    Being built now.

M2 remembering

Saves everything, so a restart never loses track of an outage.

M3 alerts

Tells you when something breaks: first by webhook, then by email.

M4 a real dashboard

A dashboard, maintenance windows and a public status page.

M5 running on its own

Its own server, backups, and a 24-hour stress test.

← Home