Device Health Score – Algorithms and Calculations

Prev Next

This article describes how Device Health Scores and rightsizing recommendations are calculated: formulas, thresholds, and pillar weights. Use it when you need to interpret scores or troubleshoot unexpected results.

Overview of the Scoring Model

The Device Health Score uses a Penalty-First model:

  1. Each device starts at 10.0.
  2. Each pillar produces a penalty from 0 to 100.
  3. Penalties are combined using fixed weights.
  4. The final score is: 10 − (WeightedTotalPenalty / 10), clamped between 0.0 and 10.0.

Important: If the operating system is Unsupported (EOL), the final score is capped at 7.0 regardless of other pillars.

All rightsizing and stability logic uses data only from active user sessions. Data is typically sampled at 1-minute intervals over a 30-day trailing window.

Pillar Weights

Pillar Weight Description
Rightsizing 30% Resource pressure (CPU, RAM, Disk IO, GPU) during active sessions.
Stability 20% Crash/freeze frequency (Windows) or sustained resource pressure (macOS/Linux).
Battery Health 25% Battery capacity vs. design.
OS Lifecycle 15% OS support status (EOL = full penalty and score cap at 7.0).
Storage Space 10% Free disk space.

Rightsizing Pillar (30%)

A breach (stress) or idle (underuse) is counted when a resource is beyond its threshold during an active session sample.

Bands and Thresholds

Resource Breach (Undersized risk) Idle (Oversized potential)
CPU Utilization > 80% Utilization < 40%
RAM Available % < 10% Available % > 60%
Disk Active time > 60% Active time < 10%
GPU Utilization > 80% Utilization < 10%

Penalty Within the Rightsizing Pillar

The rightsizing penalty is a weighted average of four resource penalties (0–100 each):

Metric Weight within pillar Penalty formula (0–100)
RAM 50% Quadratic: 100 × (Breach% / 15)²
CPU 30% Quadratic: 100 × (Breach% / 15)²
Disk IO 10% Quadratic: 100 × (Breach% / 15)²
GPU 10% Quadratic: 100 × (Breach% / 15)²

Breach% is the percentage of active session samples in which the resource was in the breach band. The quadratic curve increases penalties more sharply as breach% approaches 15%, reflecting accelerating user impact near the undersized threshold.

Stability Pillar (20%)

Windows (Native Events)

  • BSOD / system crash: One or more events → 100 penalty (about 2.0 points off the total score).
  • App crashes / hangs:
    • MTBF = Total active hours ÷ Crash count (if crashes > 0; else MTBF = Total active hours).
    • Penalty (0–100):
      • MTBF > 24 h → 0
      • MTBF < 1 h → 100
      • 1 h ≤ MTBF ≤ 24 h → (24 − MTBF) × (100 / 23) (capped 0–100)

macOS and Linux (Performance Proxy)

Native crash data is not used. Sustained resource exhaustion is used as a proxy:

  • Metric: Combined CPU and RAM breach percentage (share of active session time in breach).
  • Condition: Penalty applies if combined breach > 25%.
  • Formula: (CombinedBreach% − 25) × 2 (capped at 100).

Battery Health (25%)

Battery health is expressed as a percentage of design capacity. Penalty is 0 when no battery is present (e.g. desktops).

Health range Penalty formula (0–100)
> 80% 0
70% – 80% (80 − Health) × 3.5
50% – 70% 35 + (70 − Health) × 1.75
< 50% 70 + (50 − Health) × 1.26

OS Lifecycle (15%)

Status is derived from a lifecycle database (e.g. EOL date) at runtime.

Status Condition Penalty
Supported EOL date in future 0
Expiring Soon EOL within 90 days 0 (informational)
Unsupported EOL date passed 100 (and score capped at 7.0)
Unknown OS/version not in database 0
Linux (N/A) Out of scope 0

Storage Space (10%)

Condition Penalty formula (0–100)
Free % ≥ 15% 0
Free % < 15% (15 − Free%) × 10 (capped at 100)

Final Health Score

Formula:
HealthScore = Max(0, Min(10, 10 − (WeightedTotalPenalty / 10)))

WeightedTotalPenalty is the sum of (each pillar’s penalty × pillar weight). Pillar weights are in decimal form (e.g. 0.30 for Rightsizing).

Hard cap: If OS is Unsupported, HealthScore = Min(HealthScore, 7.0).

Health Bands (Labels)

Score range Label
9.0 – 10.0 Excellent
7.5 – 8.9 Good
6.0 – 7.4 Fair
4.0 – 5.9 Poor
0.0 – 3.9 Critical

Rightsizing Recommendation Logic

Recommendations are mutually exclusive and follow a Risk-First rule: undersized is evaluated first; a device with any resource stress is never labeled Oversized.

Recommendation Condition
Undersized Any of CPU, RAM, Disk, or GPU has breach% > 15% of active session time.
Oversized Zero breaches and all four resources in idle band for > 90% of active session time; requires at least Medium confidence (≥ 100 samples).
Appropriate All other cases with sufficient data.
Insufficient data Fewer than 100 active session samples.

Confidence Levels

Level Active session samples Effect
High > 1,000 Full score and recommendation.
Medium 100 – 1,000 Full score and recommendation.
Low < 100 Sizing recommendation forced to Insufficient data.

Samples are 1-minute intervals during active sessions; 100 samples ≈ 1.6 hours of active use.

Top Issue Determination

The Top Issue is the first matching condition in this order:

  1. OS EOL — OS support status = End of Life
  2. OS Near EOL — OS support status = Expiring Soon
  3. Battery Health — Battery penalty > 25
  4. Stability/Crash Events — Stability penalty > 50
  5. Low Disk Space — Storage space penalty > 50
  6. High RAM Pressure — RAM penalty > 50
  7. High CPU Pressure — CPU penalty > 50
  8. Resource Constraints — Sizing recommendation = Undersized
  9. None — No condition met