"The app being up is good news about the app. It tells you almost nothing about the machine underneath it."
The tempting narrow scope
Say fleet control plane and most people picture app monitoring: is the web service up, is the queue draining, are the containers healthy. That's real and useful — but it's a subset. It watches the top floor of the building and calls it the building.
The subject is the computer
Watchfire's subject is one layer down: the Mac itself. Which OS build it runs. Whether it's an enrolled member of the fleet or just some device on the network. Whether it's reachable, and by which path. Whether its environment has drifted — shell, packages, config, background jobs. Whether the services it's supposed to run are actually loaded. The applications are one of those signals, consumed through a health contract — not the boundary of the job.
Why the wider scope earns its keep
The day your app is down, the cause is often a floor below it: the machine fell behind on an OS update and a dependency broke, or it lost its SSH path after a network change, or its environment drifted and a background job quietly stopped. App monitoring sees the symptom and shrugs at the cause. A control plane whose subject is the machine can see the OS build, the reachability, the drift, and the dead launchd job in one breath — and tell you which one actually broke.
Consume, don't absorb
There's a discipline hidden in here: Watchfire consumes a sibling engine's documented health — are you up? are you serving? — but it does not copy that engine's internal diagnostics or restart logic into itself. The machine layer stays its own; the app layer stays the app's. Watchfire asks the app how it feels; it never tries to become the app's doctor.