Monitoring CPU Thermal, Power, and Frequency Throttling with Custom ControlUp Scripts and Dashboards

A common challenge in monitoring CPU performance is that traditional CPU utilization metrics often fail to reveal the underlying causes of slowdowns, especially in cases related to thermal or power throttling that reduce CPU frequency without triggering high CPU%. To address this, a detailed custom PowerShell script and accompanying dashboard have been developed to report CPU temperature, frequency, and distinct throttling signals in a granular and actionable way. This solution creates a dedicated data index named `custom_cpu_throttle` to track multiple independent throttling signals, enabling more precise diagnostics of CPU performance issues.

The core innovation of this approach lies in splitting CPU throttling indicators into three separate categories: thermal throttling (hardware/BIOS-related issues such as overheating or dust), power throttling (policy-related causes like power plans, Intune profiles, or BIOS max-state configurations), and frequency throttling (cases where the CPU clock speed drops below 85% of the rated max under load, capturing otherwise silent throttling scenarios common on AMD processors or CPUs with boost frequencies). By differentiating these factors, the method captures scenarios where traditional Event ID 37 logs or CPU utilization metrics miss critical performance degradations.

The script captures a range of per-device metrics during each run, including temperature and its source, throttle status types, current and maximum CPU frequency with a ratio percentage, and comprehensive throttling evidence logs that correlate performance drops with frequency and utilization data. This data feeds into a customizable ControlUp dashboard that aggregates key performance indicators, categorizes throttle types, tracks frequency trends, and identifies devices exhibiting the hottest or most throttled behavior. The dashboard also correlates these metrics with user experience signals like application crashes and digital employee experience (DEX) scores, enabling targeted troubleshooting from a single pane of glass.

Technical details specify that the solution runs on Microsoft Windows devices using PowerShell scripts triggered every two minutes (120 seconds) with a 60-second timeout and sends data to the `custom_cpu_throttle` index only when devices are online. The solution supports filtering by device, throttle type, and status for focused analysis. While the script covers many AMD-specific throttling scenarios, some complexities remain given AMD’s diverse behaviors, though unrealistic values are filtered out to maintain accuracy. This tool is well-suited for IT administrators and helpdesk teams looking to resolve performance tickets where CPU utilization appears normal but throttling impacts response times, such as in Outlook or other user-facing applications.

For detailed setup or a walkthrough, the script (`SP-CPU-Throttle-v2.ps1`) and ControlUp dashboard configuration (`SP-CPU-Throttle-Dashboard.json`) are available on request. This solution is an example of extending ControlUp’s monitoring capabilities via custom scripts and dashboards to deliver deeper insights into CPU performance issues that go beyond default instrumentation.

Read the entire ‘Monitoring CPU Thermal, Power, and Frequency Throttling with Custom ControlUp Scripts and Dashboards’ thread below:

Moin all,

sharing is caring and as the temperature is still rising:fire:, here is something for anyone tired of CPU% telling you nothing useful and heat is killing us.

I built a logic that reports CPU temperature, frequency and throttling to a custom index (`custom_cpu_throttle`). Simple: CPU’s can slow down due to several reasons: Power Managment, Temperature, etc…

The whole point: throttling is split into three independent signals.
• throttle_thermal: Fix path: hardware, BIOS, dust.
• throttle_power: Policy problem. Fix path: power plan, EPP, Intune profile, GPO, BIOS max-state.
• throttle_frequency_(new)_: effective CPU clock below 85% of rated max under load. Catches the cases the other two miss: silent AMD throttling without Event 37, boost-vs-base CPUs that never reach boost, sub-second bursts between samples, VRM and PL1/PL2 firmware caps.
Why it helps in real life: “Outlook is slow” tickets where CPU% looks fine and helpdesk bounces them back. Throttled devices are invisible to your normal monitoring. This makes them a dashboard line.

“`What gets captured per device per run:
status (OK / Warning / Critical / Throttling)
temp_c + temp_source (MSAcpi, LibreHardwareMonitor, OpenHardwareMonitor)
throttle_thermal, throttle_power, throttle_frequency
throttle_type (none / thermal / power / frequency / combinations)
freq_current_mhz, freq_max_mhz, freq_ratio_pct
throttling_evidence (“EventID 37 at 2026-04-17T10:14; Perf=72%; Freq=1800/3600MHz (50%) Util=85%”)“`
Attached:
• SP-CPU-Throttle-v2.ps1: the SBA itself
• SP-CPU-Throttle-Dashboard.json: matching dashboard with KPI rows, throttling-type breakdown, freq ratio trend, top hottest / most-clocked-down / most throttle events, UX cross-correlation (app crashes + worst DEX scores), and three filter variables (Device, Status, ThrottleType) so you can drill straight to a problem.
Script settings: Devices product, Microsoft Windows, PowerShell, Trigger = Short Interval Timer (120s), Timeout 60s, Sends Data ON, Data Index `custom_cpu_throttle`, Run Only When Online ON.

Drop me a message if you want a walkthrough!

Lieben Gruß,

Séb

P.S.: AMD is a pain to handle, I tried to cover most, but I can’t guarantee they all work. Non realistic values are filtered out fyi.

Download the scripts and more info in the community below…

Continue reading and comment on the thread ‘Monitoring CPU Thermal, Power, and Frequency Throttling with Custom ControlUp Scripts and Dashboards’.  Not a member? Join Here!