---
title: "Device Health Score - Algorithms and Calculations"
slug: "device-health-score-algorithms-and-calculations"
updated: 2026-01-30T19:14:28Z
published: 2026-01-30T19:14:28Z
canonical: "support.controlup.com/device-health-score-algorithms-and-calculations"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://support.controlup.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Device Health Score – Algorithms and Calculations

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