Skip to main content

How to Monitor CPU Usage in Batch Script

Monitoring CPU usage is critical for identifying "Runaway" processes that are hogging system resources and slowing down the computer. While Windows Task Manager is the standard visual tool, a Batch script can monitor CPU load in the background, allowing you to log performance over time or delay work until the system is less busy. By querying performance data through PowerShell or WMI, you can get percentage-based utilization data.

This guide will explain how to capture and react to CPU load in a Batch script.

Why Pure Batch Cannot Do CPU Math​

CPU monitoring returns numeric values that must be compared against thresholds. While CPU percentages (0–100) fit within Batch's 32-bit integer limit, the challenges lie elsewhere: wmic output contains invisible trailing carriage-return characters that corrupt set /a comparisons, and for /f parsing of WMI performance counters is fragile across Windows versions. For reliable results, this guide uses PowerShell for the query-and-compare step, with Batch as the orchestrator.

Method 1: Getting the Current CPU Load​

The simplest approach queries the overall CPU utilization percentage and returns a pass/fail result based on a threshold.

@echo off
setlocal

set "Threshold=90"

echo [INFO] Querying CPU load...

:: PowerShell queries WMI and compares against the threshold
:: Outputs the load percentage to stdout; exits 1 if above threshold
for /f "delims=" %%a in (
    'powershell -NoProfile -Command ^
        "$load = (Get-CimInstance Win32_Processor).LoadPercentage;" ^
        "if ($null -eq $load) { Write-Output 'ERROR'; exit 2 };" ^
        "Write-Output $load;" ^
        "if ($load -gt %Threshold%) { exit 1 } else { exit 0 }"'
) do set "CPU_Load=%%a"

set "PSResult=%errorlevel%"

if "%CPU_Load%"=="ERROR" (
    echo [ERROR] Could not retrieve CPU load. >&2
    endlocal
    exit /b 1
)

echo Current CPU utilization: %CPU_Load%%%

if %PSResult% equ 1 (
    echo [WARNING] CPU usage exceeds %Threshold%%% - system is under heavy load.
)

endlocal
exit /b 0

Output:

[INFO] Querying CPU load...
Current CPU utilization: 1%

Why Get-CimInstance instead of wmic:​

  • wmic.exe is deprecated since Windows 10 21H1 and may be removed in future releases.
  • wmic output contains invisible trailing \r (carriage-return) characters that become part of the variable value when captured by for /f. This causes if %CPU_Load% GTR 90 to fail with a syntax error because the comparison sees 85\r instead of 85.
  • Get-CimInstance returns clean typed data that PowerShell can compare directly without string-parsing issues.
note

LoadPercentage is an instantaneous snapshot averaged across all CPU cores. A single-threaded process maxing out one core on an 8-core system will show approximately 12%, not 100%. For per-core or time-averaged data, see Method 3.

Method 2: Checking a Specific Process​

Sometimes you need to know whether a specific process is consuming excessive CPU rather than monitoring the system as a whole.

@echo off
setlocal enabledelayedexpansion

set "ProcessName=msedge"
set "Threshold=50"

echo [INFO] Checking CPU usage for: %ProcessName%...

:: We use a variable to hold the PowerShell command to avoid escaping hell inside the FOR loop
:: Note: '%%' is used here so that when the batch runs, it passes a single '%' to PowerShell.
set "PSCmd=$counters = (Get-Counter '\Process(%ProcessName%*)\%% Processor Time' -ErrorAction SilentlyContinue).CounterSamples; if (-not $counters) { Write-Output 'NOT_FOUND'; exit 2 }; $total = ($counters | Measure-Object -Property CookedValue -Sum).Sum; $cpuCount = [Environment]::ProcessorCount; $normalized = [math]::Round($total / $cpuCount, 1); Write-Output $normalized; if ($normalized -gt %Threshold%) { exit 1 } else { exit 0 }"

set "ProcCPU=NOT_FOUND"
set "PSResult=0"

:: Execute the PowerShell command and capture the output (the CPU percentage)
for /f "usebackq delims=" %%a in (`powershell -NoProfile -Command "%PSCmd%"`) do (
    set "ProcCPU=%%a"
)

:: Capture the exit code from the PowerShell process
set "PSResult=%errorlevel%"

if "%ProcCPU%"=="NOT_FOUND" (
    echo [INFO] Process "%ProcessName%" is not currently running.
    endlocal
    exit /b 0
)

echo [INFO] %ProcessName% CPU usage: %ProcCPU%%% (normalized across all cores^)

if %PSResult% equ 1 (
    echo [WARNING] %ProcessName% is consuming more than %Threshold%%% CPU.
)

endlocal
exit /b %PSResult%

Why normalization matters:​

Windows performance counters report per-process CPU as a percentage of a single core. On an 8-core system, a process using 4 full cores shows as 400%, not 50%. Dividing by the processor count normalizes this to a system-wide percentage that matches what Task Manager displays.

Method 3: Continuous Monitoring with Logging​

For tracking CPU load over time (e.g., diagnosing intermittent slowdowns), use a monitoring loop that logs timestamped readings to a CSV file.

@echo off
setlocal enabledelayedexpansion

set "LogFile=%~dp0cpu_history.csv"
set "Interval=5"
set "Threshold=90"

title CPU Monitor - Logging to %LogFile% (Ctrl+C to stop)

:: Write CSV header if file is new
if not exist "%LogFile%" (
    echo Timestamp,CPU_Percent,Status > "%LogFile%"
)

echo [INFO] Monitoring CPU every %Interval% seconds. Press Ctrl+C to stop.
echo [INFO] Log file: %LogFile%
echo [INFO] Threshold: %Threshold%%%

:: We define the PowerShell command as a variable to prevent Batch from 
:: tripping over the % signs inside the FOR loop.
:: Note: %% is used here so that the variable contains a single % for PowerShell.
set "PSCmd=$sample = (Get-Counter '\Processor(_Total)\%% Processor Time' -ErrorAction SilentlyContinue).CounterSamples[0].CookedValue; if ($null -ne $sample) { $val = [math]::Round($sample, 1); $stat = if ($val -gt %Threshold%) { 'HIGH' } else { 'OK' }; Write-Output \"$val,$stat\" } else { Write-Output 'ERROR,ERROR' }"

:Loop
:: Use 'usebackq' and backticks to execute the command stored in the variable
for /f "usebackq tokens=1,2 delims=," %%a in (`powershell -NoProfile -Command "%PSCmd%"`) do (
    set "Load=%%a"
    set "Status=%%b"
)

if "%Load%"=="ERROR" (
    echo [%date% %time%] ERROR: Could not read CPU counter. >&2
    goto :Wait
)

:: Log to CSV
echo "%date% %time%",%Load%,%Status% >> "%LogFile%"

:: Display to console
echo [%date% %time%] CPU: %Load%%% [%Status%]

:Wait
timeout /t %Interval% >nul
goto :Loop

Why Get-Counter instead of LoadPercentage for monitoring:​

  • LoadPercentage (from Win32_Processor) is an instantaneous snapshot that can fluctuate wildly between readings.
  • Get-Counter with \Processor(_Total)\% Processor Time returns a value averaged over the sampling interval, producing smoother and more representative data.
  • Get-Counter also supports per-core counters (e.g., \Processor(0)\% Processor Time) if you need to identify single-core bottlenecks.

Performance note:​

Each iteration launches a powershell.exe process, which adds 1–3 seconds of overhead. For high-frequency monitoring (sub-second intervals), a pure PowerShell script would be more appropriate. The 5-second interval used here absorbs this overhead comfortably.

How to Avoid Common Errors​

Wrong Way: Using wmic Output Directly in Batch Comparisons​

:: BROKEN: the value contains an invisible trailing \r character
for /f "tokens=2 delims==" %%a in ('wmic cpu get loadpercentage /value') do set "load=%%a"
if %load% GTR 90 echo High

The wmic command outputs lines with trailing carriage-return characters (\r). When captured by for /f, the \r becomes part of the variable value. The if %load% GTR 90 comparison then fails with a syntax error because it sees 85\r instead of 85.

Correct Way: Use PowerShell for both the query and the comparison, so the data never passes through Batch's fragile text parsing.

Wrong Way: Monitoring in a Tight Loop​

Running wmic or PowerShell in a loop with no delay consumes significant CPU just to check the CPU, creating the very problem you are trying to detect.

Correct Way: Always add at least a 5-second delay between polls using timeout /t 5 >nul.

Problem: Localized Counter Names​

The typeperf and Get-Counter commands use performance counter paths that are localized. On English Windows the path is \Processor(_Total)\% Processor Time, but on German Windows it might be \Prozessor(_Total)\Prozessorzeit (%). If your script must run on non-English systems, use the counter index number or query via Get-CimInstance Win32_Processor (which uses language-independent WMI class names).

Best Practices and Rules​

1. Understand Multi-Core Averaging​

LoadPercentage and \Processor(_Total)\% Processor Time are averages across all cores. A single-threaded bottleneck will appear diluted. If you suspect a single-core issue, monitor individual cores with \Processor(0)\% Processor Time, etc.

2. Log to CSV for Trend Analysis​

Timestamped CSV logs allow you to graph CPU usage over hours or days, identifying patterns like nightly backup spikes or gradual memory-leak-induced CPU climbs.

3. Use Appropriate Intervals​

  • Quick health check: A single reading (Method 1) is sufficient.
  • Trend monitoring: 5–30 second intervals (Method 3) provide useful granularity without excessive overhead.
  • High-precision profiling: Use a dedicated tool (Performance Monitor, typeperf to a file, or a pure PowerShell script) instead of Batch.

4. Consider typeperf for Lightweight Continuous Logging​

If you only need to log CPU data to a CSV without any Batch logic, typeperf can do this natively without launching PowerShell repeatedly:

typeperf "\Processor(_Total)\%% Processor Time" -si 5 -o cpu_log.csv

Note that counter paths are localized (see Common Errors above).

Conclusions​

Monitoring CPU usage via Batch script provides a lightweight way to audit system health without installing third-party agents. By delegating the WMI queries and numeric comparisons to PowerShell, you avoid the text-parsing pitfalls that make pure-Batch WMI monitoring unreliable. Whether you use a single query for a quick health check or a continuous loop for trend analysis, this visibility allows you to build automation that adapts to system load, waiting for the CPU to cool down before starting intensive tasks.

Table of Contents