Three questions I ask myself
I first check whether the service itself is reachable. I test the application's HTTP response instead of relying only on ping or an open port.
I then look at CPU, memory, storage usage, and error rates. I want to spot meaningful changes rather than interpret numbers without a baseline.
When a check fails, I use logs and events to diagnose it. I also want a clear answer to whether the service actually works for its users.
I check the service before diagnosing the cause
If a host answers ping but the web application returns an error, a host-only check would still look green to me. That's why I check the application endpoint and consider what users can actually access.
I separate availability from root-cause diagnosis. I use Uptime Kuma for targeted availability checks and Zabbix for additional system states and metrics. I choose each signal for the question it answers, not for how its dashboard looks.
I want alerts I can act on
Before adding a notification, I want three questions answered: What does this signal mean? When does it genuinely matter? What can I investigate or do when it fires?
When I can't answer those questions, I quickly end up with notifications I'd eventually ignore. I prefer a small set of dependable checks to a dashboard full of numbers without purpose.