Small observability for small fleets
Small fleets do not need a observability platform. They need four signals and the discipline to look at them in the right order. I have run this pattern on a handful of boxes for years, and it has caught more incidents than any dashboard with forty panels.
The four signals
First, is the process up and answering its health endpoint. Second, is it accepting new connections at the rate you expect. Third, what is the error ratio over a short window. Fourth, how much headroom is left on the resource that fails first, usually file descriptors or memory.
That is it. Latency percentiles are useful, but they are a second-order signal: if the process is up, accepting, and not erroring, latency usually explains itself. If it is not, percentiles are noise until you know which of the four broke.
Make the check cheap
A health endpoint should do the smallest possible amount of work: confirm the listener, confirm the backend dependency, return a status. Do not make it query three databases and call it readiness. The check runs often, and a heavy check becomes its own outage.
Write down the recovery step
Every alert should have one sentence attached: what to do first. Restart the process, rotate the certificate, drain the node, or ignore it until morning. If the sentence is missing, the alert is not finished. The goal is not to eliminate thinking at 3 a.m.; it is to eliminate the part of the thinking that can be done in advance.