Monitoring

1. Resolves the endpoint and opens a connection.
2. Sends the configured method, headers and no body.
3. Reads the response status and headers, then closes.
4. Writes one row: timestamp, status, latency, verdict, error.

The probe reads headers and stops. It does not download the body, so a large JSON payload does not inflate the latency it reports or the bill it costs.

up

The status code was in expected_status_codes and no transport error occurred.

failed

Either the status was outside the expected set, or the request produced no response (DNS, TLS, connection, timeout).

blocked

A failure inside the observation path itself - the probe could not be trusted. Blocked observations are excluded from availability arithmetic and counted separately.

Vendor-internal state

The probe is outside the vendor’s network. It sees what the vendor’s edge returned.

Other customers

A 200 from this path does not mean every caller got a 200. It means this one did.

Erratic paths

A dependency that fails for one in twenty requests may never produce the consecutive failures the rule needs. Reported latency distribution is the signal to read in that case.

Anything behind your auth

If the endpoint requires a session you cannot supply, the probe cannot reach what your application reaches.

Latency is the wall-clock time from issuing the request to receiving the complete response, redirect hops included, measured from one observation point. It therefore contains DNS, TLS and the network path between RELIASTRA and the endpoint - none of which your users experience identically. Use it to detect change over time on the same dependency, not to rank one dependency against another.

reliastra checks recent --limit 200 --json \
  | jq '[.[] | select(.is_up)] | (map(.latency_ms) | sort) as $l
        | { count: ($l|length), p50: $l[($l|length*0.5|floor)], p95: $l[($l|length*0.95|floor)] }'