[BUG] High CPU Alert always shows 0,0% as current value

[ehaar]

Component

Lite

Performance Monitor Version

3.3.0

SQL Server Version

Microsoft SQL Server 2022 (RTM-CU25-GDR)

Windows Version

Windows 11 Enterprise 25H2

Describe the Bug

Alerts of type 'High CPU' in the Lite version on tab 'Alert History' always show 0% as Value (or Current Value when viewing details of the alert). See image:

Steps to Reproduce

1. Open SQL Server Performance Monitor Lite (Version 3.3.0)
2. Click Tab 'Alert History'
3. Result: Alerts of type 'High CPU' (if any present) all contain zero percent as 'Value'

Expected Behavior

Alerts show the real current version of CPU percentage.

Actual Behavior

Alerts of type 'High CPU' (if any present) all contain zero percent as 'Value'

Error Messages / Log Output

Screenshots

Additional Context

No response

[erikdarlingdata]

Good catch. Confirmed and fixed. The alert engine hands the history store the display text but never handed it the number, and the store's fallback parser choked on the "(Total CPU)" label after the percentage - so it recorded zero for every High CPU alert ever written. Your toasts, emails, and webhooks always carried the right percentage, which is exactly why nobody caught it sooner: only the stored history row was wrong.

Fixed in the next release - the engine passes the real number now, and the fallback parser learned to read decorated text so this class of bug cannot come back. If you want it sooner, the nightly build off the dev branch carries it: https://github.com/erikdarlingdata/PerformanceMonitor/releases/tag/nightly. Your existing history rows will keep their stored zeros (the real values were never persisted, so there is nothing to restore them from), but every alert from the fix onward records correctly.

[erikdarlingdata]

Following up to close this out. The fix shipped on dev the day you reported it: the High CPU alert engine now passes the real measured value instead of a text fallback that parsed to zero, and the same sweep fixed every other alert that had the same shape, including a second round that hardened the parsing for locales that use comma decimals like yours. It will be in the next regular release, and tonight's nightly has it now.

Closing as fixed. If you still see 0,0% as a current value after updating, comment here and it reopens.