No news is good news?

On 19 June 2026 my monitoring stopped. I found out on 29 July. It reported nothing the whole time, and I took that as good news.

My monitoring runs on a Raspberry Pi called Josie, which does nothing else. It’s a key piece of infrastructure, so I stripped as much out of its configuration as I could — the fewer external things it depends on, the less of it there is to maintain, and it sits on separate hardware from everything it watches. I built it after being caught out by an outage I hadn’t known about.

Josie runs Uptime Kuma, which does a fairly simple thing. It holds a list of checks — can I reach this service, does it answer, does it return what it should — runs them every minute, and shows the results on a dashboard. Each check is called a monitor. Mine had sixteen, covering Pinky — my container host — and the services on it.

Telling me about a failure is a separate step. A monitor going red doesn’t send anything on its own — you attach a notification to it, and the notification is what puts a message on your phone. Mine go to a Telegram bot.

What I hadn’t arranged was anything to watch Josie. I didn’t think about it at all.

I was adding a service, went to add a monitor for it, and the dashboard didn’t load. If I hadn’t deployed anything that week it could have been months.

I don’t remember exactly what I did next — probably jumped straight into Claude or Gemini and asked what was going on. The process had died and the process manager hadn’t restarted it. I never worked out why. By the time I looked, the logs I’d have needed were long gone.

When I brought it back up I went through the monitors one at a time, which I hadn’t done in a long while.

Not misconfigured, not pointing at a dead chat — attached to nothing at all, so every one of them could go red and no message would leave the box. The alert path had never fired successfully once, in months of uptime.

The forty days are the smaller half of this. For months before it I had a dashboard that went green and red correctly and never once sent an alert, and I’d have told you I monitored my infrastructure.

Three things have changed since.

A job on Pinky now polls Uptime Kuma’s heartbeat API rather than its port. Kuma will serve HTTP quite happily while its check loop is wedged, so a port check would have returned a healthy 200 for most of those forty days. That job alerts to Telegram directly rather than through Kuma, because Kuma can’t be the thing that tells me Kuma is down.

Every scheduled job now emits a positive “I ran and I did the thing” on a known cadence, and something separate alerts when that signal stops arriving.

And I broke the alert on purpose, to watch it fire. That’s the step I’d skipped for years.

There’s still a hole in it. Josie watches Pinky, and Pinky watches Josie. If both go down together nothing alerts, and I find out when the morning brief doesn’t arrive. Closing that needs an external monitor — something like healthchecks.io or a cheap VPS — that expects a ping from me every hour and messages me when it stops. I’m still working out what that looks like in practical terms.

Go and check that your alerts have ever fired. Not that they’re configured — that one of them has actually arrived somewhere a human read it. If you can’t remember the last one, you don’t have monitoring. You have a dashboard and a habit of glancing at it.

No news is good news — if you’ve checked that the news can reach you. Nothing gets set and forgotten. Something always has to be checked by a person, and the aim is to make that the smallest number of checks you can, so that you can trust all the others are working.