Skip to main content

CPU Threshold Violation Monitoring

Purpose

The CPU Threshold Violation Monitoring solution continuously tracks CPU usage on Windows endpoints and alerts you only when a sustained, high‑load condition persists for a configurable amount of time. It is designed to ignore brief, harmless spikes and only generate tickets when a true performance issue requires your attention.

Unlike traditional monitoring that looks at a single fixed percentage, this solution uses a two‑threshold logic:

  1. High Threshold – the CPU percentage that starts the timer.
  2. Low Threshold – the percentage that resets the timer if the CPU falls below it.
  3. Sustained Minutes – the number of minutes the CPU must remain above the low threshold (after first exceeding the high threshold) before an alert is raised.

The actual monitoring is performed by a lightweight monitor that reads a local JSON configuration file every 15 minutes. A separate daily configuration writer task pulls the threshold values from ConnectWise RMM custom fields and writes that file, allowing you to manage policies entirely through custom fields without touching scripts.

Key Capabilities

  • Two‑Threshold Alerting with Automatic Reset: Alert only on sustained high CPU. Brief spikes that drop back down reset the timer automatically.
  • Automatic Ticket Resolution: Once CPU falls below the low threshold, the monitor clears and the ticket is automatically closed.
  • Hierarchical Policy Management: Set Company‑wide defaults, override them at a Site, or set a unique value for a single Endpoint – all through custom fields.
  • OS‑Aware Targeting: Servers and Workstations automatically use their respective threshold fields (_Svr / _Wks).
  • Configuration / Monitoring Decoupling: Threshold changes take effect on the next daily (or manual) run of the configuration writer, without modifying the monitor itself.

Important Caveats & Behavior

  • Daily Configuration Update: The configuration writer task runs once per day. If you change a custom field, the new thresholds will only be picked up after the next scheduled run. You can manually run the task on an endpoint to apply changes immediately.
  • Monitor Interval: The monitor checks CPU usage every 15 minutes against the stored configuration file.
  • Auto‑Resolution: Tickets generated by this solution will be closed automatically when the CPU usage drops below the low threshold – no manual intervention required.

Associated Content

Group

NamePurpose
CPU Threshold Violation MonitoringDynamic group that targets Windows endpoints based on the CTVM_Enable custom fields, automatically pulling in devices authorized for monitoring.

Task

NamePurpose
CPU Threshold Violation Monitoring Configuration WriterRuns daily to resolve hierarchical thresholds from custom fields and writes the JSON configuration file for the monitor.

Monitor

NamePurpose
CPU Threshold Violation MonitoringExecutes every 15 minutes, reading the local JSON configuration file. Checks CPU usage and generates or resolves tickets based on the two‑threshold logic.

Custom Fields: Enablement

These fields act as the “on/off switch” for the solution. They use a Dropdown (Enable or Disable) to dynamically target devices.

NameLevelTypePurpose
CTVM_Enable_SvrCompanyDropdownEnables or disables CPU monitoring for servers at the Company level.
CTVM_Enable_WksCompanyDropdownEnables or disables CPU monitoring for workstations at the Company level.
CTVM_Enable_Svr_SiteSiteDropdownSite‑level override for server enablement.
CTVM_Enable_Wks_SiteSiteDropdownSite‑level override for workstation enablement.
CTVM_EnableEndpointDropdownEndpoint‑level override to explicitly enable/disable specific machines.

Custom Fields: High Threshold

Enter the CPU percentage that starts the sustained‑usage timer. Must be higher than the low threshold.

NameLevelTypePurpose
CTVM_HighThreshold_SvrCompanyText BoxCompany baseline for servers (Default: 95).
CTVM_HighThreshold_WksCompanyText BoxCompany baseline for workstations (Default: 90).
CTVM_HighThreshold_Svr_SiteSiteText BoxSite‑level override for servers.
CTVM_HighThreshold_Wks_SiteSiteText BoxSite‑level override for workstations.
CTVM_HighThresholdEndpointText BoxEndpoint‑level override (applies to both OS types).

Custom Fields: Low Threshold

Enter the CPU percentage that resets the timer and clears the alert. Must be lower than the high threshold.

NameLevelTypePurpose
CTVM_LowThreshold_SvrCompanyText BoxCompany baseline for servers (Default: 90).
CTVM_LowThreshold_WksCompanyText BoxCompany baseline for workstations (Default: 85).
CTVM_LowThreshold_Svr_SiteSiteText BoxSite‑level override for servers.
CTVM_LowThreshold_Wks_SiteSiteText BoxSite‑level override for workstations.
CTVM_LowThresholdEndpointText BoxEndpoint‑level override (applies to both OS types).

Custom Fields: Sustained Minutes

Enter the number of minutes the CPU must remain above the low threshold (after spiking above the high threshold) before an alert is generated.

NameLevelTypePurpose
CTVM_UsageMins_SvrCompanyText BoxCompany baseline for servers (Default: 30).
CTVM_UsageMins_WksCompanyText BoxCompany baseline for workstations (Default: 30).
CTVM_UsageMins_Svr_SiteSiteText BoxSite‑level override for servers.
CTVM_UsageMins_Wks_SiteSiteText BoxSite‑level override for workstations.
CTVM_UsageMinsEndpointText BoxEndpoint‑level override (applies to both OS types).

Implementation

Follow these steps in order to successfully deploy the CPU Threshold Violation Monitoring solution in your environment.

Step 1: Create the Following Custom Fields

Create all 20 custom fields listed below in ConnectWise RMM. These are required for the solution to function correctly.

Step 2: Create the Group

Create the dynamic group that will automatically target the enabled machines.

Step 3: Create the Task

Set up the configuration writer script that will run on the targeted endpoints.

Step 4: Create the Monitor

Set up the monitor that will evaluate CPU usage against the configuration file.

Step 5: Schedule the Task

Schedule the CPU Threshold Violation Monitoring Configuration Writer task to run once per day against the CPU Threshold Violation Monitoring group, as described in the Schedule Task section of the task's document.

The monitor is already configured to run every 15 minutes against the same group and requires no additional scheduling.

Step 6: Review and Set Threshold Custom Fields

Review the default threshold values and set the threshold custom fields as required for your environments. You can set broad Company‑level baselines, and then configure specific Site‑level or Endpoint‑level overrides where tighter rules or exceptions are needed.

Step 7: Review and Set Enablement Custom Fields

Set the enablement custom fields to Enable for the client, location, or specific endpoint to turn the solution and monitoring on for them. Machines will not be monitored until they are explicitly enabled via these dropdown fields.

FAQ

Q: How does the CPU Threshold Violation monitor work?

A local configuration file (JSON) is written daily by the configuration writer task. The monitor reads this file every 15 minutes, samples the CPU over 10 seconds, and applies a two‑threshold logic:

  • When CPU first exceeds the high threshold, a marker is created and the timer starts.
  • As long as CPU stays above the low threshold, the timer continues.
  • If the timer reaches the sustained minutes, an alert ticket is created.
  • If at any point CPU drops below the low threshold, the marker is deleted and the timer resets.

Q: What are the default thresholds if I don’t set any custom fields?

For servers: High = 95%, Low = 90%, Sustained Minutes = 30.
For workstations: High = 90%, Low = 85%, Sustained Minutes = 30.
These defaults are used when no Company, Site, or Endpoint field is populated.

Q: I changed a threshold custom field. When will the new values take effect?

The configuration writer task runs once per day (by default). The new thresholds will be applied on the next scheduled run. You can manually execute the CPU Threshold Violation Monitoring Configuration Writer task on an endpoint to update the configuration file immediately.

Q: How quickly will I be notified of a sustained CPU issue?

The monitor checks every 15 minutes. If the CPU has been above the low threshold (after spiking above the high threshold) for the configured number of minutes, a ticket will be created on the next monitor run. So the maximum delay from the moment the condition is met is 15 minutes.

Q: Will the ticket close automatically when the CPU usage drops?

Yes. The monitor runs the same script for resolution. When the CPU falls below the low threshold, the marker file is deleted and the script outputs nothing, which signals a healthy state. The monitor’s automatic resolution rule then closes the ticket.

Q: Why isn't a specific device being monitored?

The device must be explicitly enabled via the CTVM_Enable custom fields. Check that the Endpoint, its Site, or its Company has the appropriate CTVM_Enable* field set to Enable. Blank or Disable entries will exclude the device from the monitoring group.

Q: I want to monitor only my servers, not workstations. How do I do that?

At the Company level, set CTVM_Enable_Svr to Enable and leave CTVM_Enable_Wks blank or set to Disable. The dynamic group will then only pick up Windows Servers.

Q: Can I set different thresholds for a specific critical server?

Yes. Set the desired threshold values directly in the Endpoint‑level custom fields (e.g., CTVM_HighThreshold, CTVM_LowThreshold, CTVM_UsageMins) for that machine. Endpoint values override everything else.

Q: What happens if I only set the high threshold but not the low threshold or minutes?

The configuration writer will still apply defaults for the missing fields. For example, if you set CTVM_HighThreshold = 98 on a server but leave the others blank, the server will use Low = 90 (default) and Minutes = 30 (default).

Q: What does the monitor ticket contain?

The ticket includes the time the CPU spiked above the high threshold, the current CPU usage, a list of the top five CPU‑consuming processes, and if applicable, the command line of any PowerShell process that is consuming CPU.

Q: Can I disable monitoring for a single server temporarily without deleting custom fields?

Yes. Set CTVM_Enable = Disable at the Endpoint level for that machine. The device will be removed from the monitoring group and no further monitoring will occur until you re‑enable it.

Q: I see the configuration file under ProgramData. Can I modify it manually?

Manual changes to the JSON file will be overwritten the next time the configuration writer task runs. Always adjust thresholds through the custom fields to ensure consistency.

Q: The monitor output says “CPU monitoring configuration file not found.” What should I do?

This means the configuration writer task has not yet run on that endpoint. Run the CPU Threshold Violation Monitoring Configuration Writer task manually or wait for the next daily schedule.

Q: Will the monitor create a new ticket every time it detects high CPU usage?

No. The first time a sustained high‑CPU condition is detected, a ticket is created. On subsequent checks, if the same condition is still active and the original ticket is still open, the monitor will add a comment to the existing ticket instead of creating a duplicate. This prevents ticket clutter and keeps all related information in one place. A new ticket is not created until the issue is resolved (CPU drops below low threshold) and then re‑occurs.

Q: The monitor isn’t generating tickets, or the ticket status isn’t updating. How can I check if the configuration file is correct?

Verify that the configuration file exists at C:\ProgramData\_Automation\Script\Test-CPUUsage\Test-CPUUsage.json. If the file is missing, run the CPU Threshold Violation Monitoring Configuration Writer task manually on the endpoint. If the file exists but the thresholds seem wrong, check the custom fields at the Endpoint, Site, and Company levels; the task will use the first valid value it finds in that order. After updating fields, manually run the task again to refresh the file.

Q: How can I tell if the monitor is actually running and evaluating CPU usage?

Check the monitor’s run history in the ConnectWise RMM console. You can also look for the marker file C:\ProgramData\_Automation\Script\Test-CPUUsage\Test-CPUUsage.flag. If it exists, a high‑CPU event is currently being tracked. If it does not exist, either no spike has occurred or the CPU has dropped below the low threshold and the timer has reset.

Changelog

2026-07-03

  • Initial version of the document