Troubleshoot: Device Monitoring and Alerting Issues

I created a software addition/removal rule but I don’t see any alerts.

Cause:

The Value field in Software Addition or Removal rules only supports letters (a-z, A-Z), numbers (0-9), spaces, underscores (_), hyphens (-), or periods (.). If you have added any invalid characters in the Value field, the rule might become invalid and not work.

Solution:

We have added a validation to prevent users from saving a rule if an invalid character is present in the Value field. For rules containing invalid characters created prior to January 17th, 2025, no alerts will be triggered. You can either update the existing rule or create a new one instead.

Cause:

For rules that are associated with a large number of devices (exceeding 1000), when Existing Conditions are enabled, there may be a delay of up to 15 minutes in alert generation. This typically occurs when the total number of existing conditions (for which alerts need to be generated) exceeds 1,000.

Solution: You can create multiple rules with different conditions and associate different device groups to help keep the total number of alerts for existing conditions below 1,000.

The option to enable/disable rules from the Rules dashboard is currently not functioning as expected for the following rules:

• Command Execution Failure
• Managed Software Installation Failure
• Policy Application Failure

Cause:

If a command, policy, or software being used in the conditions section of a rule is removed from the system, you will be unable to enable or disable the rule from the Rules dashboard. 

Solution: Go to the rule details page, and use the Enable/Disable toggle button.

Admin setup a Server Offline rule to monitor the server status, and is seeing several duplicate alerts on the Alerts dashboard.

Cause:

A technical issue with the Device Offline Monitoring rule has caused a high volume of duplicate alerts for users who had this rule enabled prior to November 29th, 2024.

Solution:

The issue is now resolved as follows:

• Admins will no longer receive several duplicate alerts for devices that are offline. Instead, the rule will generate one alert per offline device as expected.
• All previously generated duplicate alerts will be automatically deleted.
• Auto-resolution will work as expected and alerts will be auto-resolved when the device comes online.

Users who had this rule enabled before November 29th may still see duplicate alerts (one extra alert per device) for certain offline devices that had already generated an alert. If you see duplicate alerts, delete them by following these steps:

1. Go to the Alerts dashboard. See Get Started: Device Monitoring and Alerting to learn more.
2. On the Alerts dashboard, apply a search filter using the exact name of the rule that triggered the alerts ( such as Server Offline 14 Days).
3. Select all duplicate alerts.
4. Click the Actions dropdown and select Delete.

Problem:

I am seeing false alerts in the JumpCloud Admin Portal, where software updates on Windows devices are reported as separate software_remove and software_add events instead of a single software_update event.

Cause:

JumpCloud System Insights uses osquery to track software changes on Windows devices by collecting data periodically and comparing snapshots. False alerts occur because:

• Windows apps lack a unique identifier, making it hard to track updates.
• Application names may include version or architecture details (for example, "TestApp v1.32.0" or "TestApp v4.2.3"), causing mismatches.
• Installation locations may change or be missing during updates.
• Multiple apps may share similar names (such as different .NET runtime versions), leading to incorrect event logging.

Previously, updates were logged as software_remove (old version) and software_add (new version) events, which could be misinterpreted as separate actions.

Solution:

JumpCloud has improved software update detection on Windows to reduce false alerts:

1. Install Location Matching: We prioritize the install_location field (like C:\Program Files\TestApp) to identify the same app across snapshots, even if names vary due to version or architecture.
2. Name Fallback: If install_location is unavailable or changes, we use the name field, carefully handling versioned names to avoid mismatches.
3. Multi-Version Handling: For apps with identical names (such as .NET runtimes), we track versions to log accurate changes and avoid redundant alerts.
4. Fallback Behavior: If neither field confirms an update, we log software_remove and software_add events to ensure changes are reported.

Benefits:

• Fewer False Alerts: Updates are more accurately logged as software_update events.
• Reliable Tracking: Handles versioned names and multi-version apps better.

Limitations:

Updates may still be logged as separate events if install_location or name changes significantly.

• Non-MSI or UWP apps may have inconsistent metadata, affecting detection.
• Complex name variations can pose challenges.