Quiet has to be earned

FoxWatch is the PC health monitor I'm building at Narcoleptic Fox. The whole idea fits in one line: stay quiet unless there's something specific to do.

I last wrote about it in July, when it was a design document and a screen that deliberately opened to nothing. Since then it has become a working Windows desktop app and a command-line monitor for Linux servers. It isn't released yet. But it's far enough along that I can tell you what building it taught me, and it taught me one thing, over and over, from different directions: a quiet result has to earn its quiet.

What it does today

On Windows, FoxWatch reads the machine's own health signals: disk space, with a "full in N days" estimate instead of a percentage; drive health, read without administrator rights; crashes and unexpected shutdowns from the event log; hardware errors and graphics driver resets; devices that have stopped working; the network link; battery wear. It sorts every one into act now, review or ignore with plain, deterministic rules. No cloud, no telemetry, no machine learning. The data stays in a local database. A fox in the system tray changes colour with the state, and most days it just sleeps.

On Linux it runs headless, on a timer, and answers on the command line with an exit code a script can act on.

Here are five times a quiet result, or a loud one, turned out to be wrong.

1. Fourteen unexpected shutdowns that weren't

The first time I installed the app on a real machine and looked at what it said, the dashboard reported 14 unexpected shutdowns. That's alarming. It was also wrong.

Windows records one unclean shutdown twice, as two different events five to eleven seconds apart. So 4 power cuts became 8 rows. On top of that, 6 hardware-error records sat in the same table. 8 plus 6 is 14. And because every power cut counted double, a crash threshold of 3 was really tripping at one and a half real events.

Two of those six hardware errors were logged in the same second as a power cut. They were fallout from the power cut, not evidence of failing hardware.

The part that bothered me most was what the dashboard didn't say. The real early warning in that data was three hardware errors on one night, a minute apart: 01:31, 01:32, 01:33. They sat under a count threshold of 10, so FoxWatch said nothing. A count over a long window can't tell three errors in three minutes from three errors in three months. The rule now measures density: errors in any 10-minute span.

One more thing came out of it. Four different parts of the app had been counting shutdowns, and they gave four different numbers. They now share one function. Two implementations of one idea is where a bug hides; four is worse.

None of this showed up in code review. It showed up when I ran the real app against a real machine's history and read what it told me.

2. The driver that turned into malware overnight

A health monitor wants motherboard temperatures and fan speeds. On Windows, the usual way to read them for years was a driver called WinRing0, used by a lot of well-known hardware tools.

I checked it instead of trusting my memory of it. It has a published vulnerability (CVE-2020-14979) that lets any user on the machine read and write kernel memory. It hasn't changed since 2008. And in March 2025, Microsoft Defender started flagging it as a severe threat, which broke several popular fan and monitoring tools at once. It was fine for fifteen years, and then, overnight, it wasn't.

If FoxWatch had bundled it, the antivirus would have quarantined the health monitor. So it doesn't. Board sensors sit behind an interface that lets the driver underneath be swapped, and writing my own kernel driver was off the table.

The replacement I'm evaluating is PawnIO, a driver the user installs themselves. The question that decides the design is simple: can an ordinary user account open it? So I measured all three cases:

That settles it: reading board sensors needs a small privileged service, not just a library call.

The interesting part is how that table almost went wrong. The administrator case is the control, the one that should simply work, and the first time I ran it, it failed. The bug was mine: I'd given the driver's version call an 8-byte buffer, and it accepts exactly 4. With that bug in place, the standard-user result still looked perfect, because the driver refused the standard user before my code ever reached the broken call. Without the control run, I'd have written down a correct conclusion, measured with a broken instrument, and never known.

Until that privileged service exists, FoxWatch on Windows shows board sensors as not watched. Not as fine.

3. Every signal says why it's quiet

That became the core design rule: no number without its verdict, and absence is never painted as health. A signal that isn't present on this machine, needs administrator rights, or has stopped reporting is labelled as exactly that. None of those is ever green.

It sounds obvious. Here's what the machines said when I measured instead of assuming:

• On Linux, journalctl exits successfully even when it isn't allowed to read anything. "Insufficient permissions" still comes back as status 0. Trusting the exit status would have reported a machine whose crash log it was forbidden to read as a machine that had never crashed.
• A Linux system library reported 19 disks on a machine with 1. The rest were host mounts and package images. Count them as drives and the disk-space checks fill up with noise.
• Windows exposes 8 board sensors to an ordinary user: 4 temperature, 2 fan, 2 voltage. All 8 report "Status: OK". None of them report a reading.
• The one temperature zone an ordinary user can read said 3010, which is 301.0 kelvin, about 28°C. It said 3010 for 20 samples at idle. Then I ran all 32 processor cores at 100% for 90 seconds, and it still said 3010. A number that never moves isn't a measurement. That one test settled a design question in about forty minutes.

Every one of those would have produced a calm, green, wrong dashboard.

4. The leak that would have taken years

FoxWatch keeps raw samples for a week, then rolls them up into hourly and daily summaries so the database doesn't grow forever. On a headless Linux install, the rollup had never run. Not once.

Eight hours of running produced 527 raw rows and zero hourly rows, about 160 KB. That projects to roughly 68 MB a year, with no end. Not an emergency. The kind of bug that bites in year three, when nobody remembers why the disk is filling. With the fix, the database stays flat at about 1.3 MB.

A health monitor slowly filling the disk it's supposed to be watching is exactly the kind of irony I'd rather find myself.

5. The tests that agreed with me

The last one is the most uncomfortable. FoxWatch had over a hundred test scenarios at the time, all passing, and none of them caught a message that would have told a user: "Tctl spent 100% of the last 24 hours."

Tctl is the register name of a temperature sensor on AMD processors. It means nothing to a person. The tests missed it because every fixture label was written by hand, and 13 of the 18 processor fixtures quietly defaulted to the class "other". The tests checked my assumptions about the data, not the data. A fixture is a memory of what I assumed.

The message now names the part in plain words: "The processor".

Where it stands

FoxWatch isn't released. Between here and a release: the privileged sensor service on Windows, board sensors on Linux, and a proper release pipeline and download. I'll write about it again when there's something you can install.

Also on the blog this week

My contrast check found nothing, so I broke it on purpose. An AI review of my company's site said some text looked muted. Before touching a colour, I measured. The first measurement reported every colour on the site as black: the converter couldn't parse the modern CSS colour format and silently fell back to black, then compared black with black everywhere and called it fact. The rebuilt check passed three pairs with known answers (21:1, 1:1 and 4.54:1), found zero real failures, and only then got trusted, after I planted two failures on purpose and watched it catch both. What was actually wrong was text size. No colour changed.

Same lesson, different week.

If you're buying software

Ask what a vendor's monitoring shows when it can't see something. If the answer is green, the dashboard is guessing. And when someone tells you a check passed, ask whether anyone has seen it fail. "No issues found" is only worth something from a check that has been caught finding one.

Built while the rest are sleeping. Narcoleptic Fox, Orlando FL.