# net.device-status

Decides whether a monitored device is **up**, **degraded** or **down** from
its `net.latency-summary`, and says why, so an alert and a dashboard never
disagree about what "degraded" means.

## Rules, in order

1. No replies at all: **down**, `no replies: 3 of 3 probes lost`.
2. Loss at or above `downLossBasisPoints`: **down**,
   `loss 66.67% at or above the down threshold 50.00%`. Down wins outright;
   p95 and jitter are not judged.
3. Otherwise each threshold crossed adds a reason, in this order, and any
   reason makes it **degraded**:
   - loss at or above `degradedLossBasisPoints`: `loss 25.00% at or above 10.00%`
   - p95 at or above `degradedP95Us`: `p95 152.300 ms at or above 100.000 ms`
   - jitter at or above `degradedJitterUs` (skipped when the threshold or the
     jitter is null): `jitter 25.000 ms at or above 20.000 ms`
4. No reasons: **up**, with an empty list.

Every comparison is "at or above", so a threshold is the first value that
counts as bad. Percentages are printed from basis points with two places and
times from microseconds as milliseconds with three places, using integer
arithmetic only, so the text is identical in every language.

## Errors

- `summary is inconsistent` when `sent` is under 1 or `received + lost`
  differs from `sent`.
- `downLossBasisPoints must be 1 to 10000`
- `degradedLossBasisPoints must be 1 to downLossBasisPoints` (a degraded
  threshold of 0 would make every device degraded)
- `degradedP95Us must be at least 1`
- `degradedJitterUs must be null or at least 1`