The alert about the blackout needs the internet too

Sat, 17 Oct 2026 00:00:00 +0000

Part 5 left the observer able to shut machines down and unable to tell me anything, with one item still open: an alert for an observer that stops. The alerts looked like one function. Log the line, and if a notifier is configured, hand it over:

func alertf(format string, a ...any) {
	msg := fmt.Sprintf(format, a...)
	log.Print(msg)
	if alerts != nil {
		alerts.Send(msg)
	}
}

That function hasn't changed since. The file around it, notify.go, is now 217 lines, and its tests are another 197. Most of it comes from one inconvenient fact: a message about a power cut leaves through an internet uplink, and the cut can take the uplink with it. I can keep the router running on battery. I can't vouch for anything upstream of it.

Designing alerts you'll actually understand at 3am

Wed, 08 Jul 2026 00:00:00 +0000

TL;DR A digest that dumps raw SMART counters is complete and useless: re=344 means nothing at 3am. Alert on growth — compare today's counters against yesterday's row for the same serial, and push urgently only when a number moved. Seed the first sighting of a drive silently, or every new disk pages you on day one. Two channels, two intents: a calm daily digest that reassures, and an urgent push that interrupts.

Here is the notification my daily SMART logger pushed on day one. Four drives, one line each, everything the tool knew:

Monitoring on tsvinc

The alert about the blackout needs the internet too

Designing alerts you'll actually understand at 3am