Advanced health-rule recipes

Use these as starting points in Alerts → Health rules → New health rule. Choose Metric query (advanced) for the condition, paste its query, and set the rule’s scope and timing below. Start in Shadow and use Preview to check the result with your actual cadence and measurements. These are suggested rules, not automatically installed defaults.

from tests accepts full metric names across storage sources. Each condition ends in pick and evaluates one numeric output per scope. Formulas operate on the inputs’ aggregates over the evaluation window, not on per-chart-bucket ratios. Missing inputs and zero divisors produce no calculated value.

Keep test_id and agent_id as scope dimensions so duplicate names and renames do not merge or replace health identities. IntelliSense shows the names when choosing an ID filter. test_id means a check definition; test.group_id is its containing test group. Put filters specific to an input in its own query: the rule-wide Only entities matching selector applies to every input of every condition, including joined inputs.

HTTP failures per test and agent

The library’s target-level HTTP availability rule pools observations for a target. This variant can reveal a failing vantage or check that a pooled average hides. Use it when each test/agent pair needs its own health state.

from tests
| where test_type = "http_check"
| summarize avg(http_check_passed) as pass_rate by test_id, agent_id
| extend failure_ratio = 1 - pass_rate
| pick failure_ratio

• Scope by: test_id, agent_id.
• Tiers: warning when > 0.2; critical when > 0.5.
• Minimum samples: 3. Leave minimum trusted agents at its default. A scope with only one contributing worker becomes indeterminate if you require two.
• Timing: evaluate every 60 seconds over 5 minutes; fire after 2 minutes; resolve after 5 minutes clear.
• No data: Hold. Require measuring-agent fidelity: on.

http_check_passed is 1 when the check passes its configured expectations and 0 when it fails. A result of 0.2 means 20% of observed checks failed. A response alone (http_check_responded) does not establish success. Unsent checks and missing samples are not failures. This is a sample fraction, not a requests-per- second rate; do not apply rate to the pass flag.

For one check or agent, add a test_id or agent_id equality to where; choose the entity by name in IntelliSense to insert its ID. Review policy routing if you also keep the pooled rule, to avoid duplicate pages for the same outage.

Monitored-service absence with collection coverage

Configure the exact name in the host check’s Processes to monitor first. Replace postgres with that configured executable name. An opportunistic top-process list cannot establish absence.

from tests
| where process_name = "postgres"
| summarize max(host_service_instances) as instances,
            min(host_service_coverage) as coverage
  by test_id, agent_id
| extend observed_instances = instances / coverage
| pick observed_instances

• Scope by: test_id, agent_id.
• Tier: critical when == 0.
• Minimum samples: 3.
• Timing: evaluate every 60 seconds over 5 minutes; fire after 2 minutes; resolve after 5 minutes clear.
• No data: Hold. Require measuring-agent fidelity: on.

The maximum count is zero only when all reported counts in the window are zero. Collection emits zero instances only for a complete monitored collection. Taking minimum coverage makes any reported incomplete collection yield a zero divisor, suppressing the numeric result instead of declaring the service absent. The sample floor for a calculated output is the minimum of its inputs’ counts.

Coverage only describes collections that arrived; it does not prove continuous reporting. Pair this with collector-freshness monitoring using host_service_sample_age_seconds{process_name="postgres"} | min by (test_id, agent_id) and deliberate no-data handling. The freshness value measures the age of the newest matching sample within the evaluation window; once the window is empty, the condition has no data. Choose its threshold relative to the configured collection interval. See Service absence and collection coverage.

Agent probe-budget utilization

This expresses the library’s probe-budget ratio as named inputs and a calculated output, making the formula easier to inspect and extend. It detects pressure on the measuring agent’s budget; it is not a network packet-loss estimate.

from tests
| where test_type = "agent_health"
| summarize avg(agent_pps_current) as sent,
            max(agent_pps_ceiling) as ceiling by agent_id
| extend utilization = sent / ceiling
| pick utilization

• Scope by: agent_id.
• Tiers: warning when > 0.8; critical when > 0.95.
• Minimum samples: 3.
• Timing: evaluate every 60 seconds over 10 minutes; fire after 5 minutes; resolve after 10 minutes clear.
• No data: Hold. Require measuring-agent fidelity: off.

Fidelity must stay off for a rule measuring agent health itself, or the degraded agent can suppress its own health signal. The ratio is the window’s average probe rate divided by its maximum reported ceiling, so a ceiling change inside the window affects the interpretation. A zero or missing ceiling is indeterminate. This recipe recommends Hold on missing data; the existing library rule uses Treat as OK. Choose that behavior deliberately when adopting the recipe.

Scope, missing data, and baselines

These rules evaluate observed entities. A configured test that has never produced a matching sample cannot be discovered by a metric query alone. For previously tracked entities that stop reporting, no-data handling applies after the evaluator’s grace period; Hold is not evidence of healthy recovery. A collector heartbeat or inventory-based expectation is a separate health question.

Do not use ordering or limits in a picked condition; they are rejected. Dropping out of a top-N chart is not proof of recovery. The calculated outputs in these three recipes use fixed thresholds. Learned-baseline conditions can instead use a selector or source query that picks one measured output, with stable IDs and recorded labels. Joins and calculations need their own learned history. See baseline-based latency rules for the HTTP, DNS, and TCP regression templates, and Health rules for combining conditions, fidelity, lifecycle, and incident behavior.