System Metrics Rules

Define resource and performance thresholds that expose endpoint health and suspicious abuse.

XDRShield System Metrics Rules help teams monitor CPU, memory, disk, and related endpoint-resource signals so operational stress, suspicious resource abuse, and unhealthy endpoints can be surfaced with policy-driven rules.

Resource thresholdsHealth and abuse signalsPolicy-driven monitoring
Why it matters

Resource anomalies often explain both outages and suspicious activity.

High CPU, memory pressure, disk usage, or abnormal resource behavior can indicate operational problems, misconfiguration, or malware-like activity. Metrics rules make those signals visible and reviewable.

01

Spot resource stressMonitor endpoint resource conditions that affect reliability or may indicate abuse.
02

Standardize thresholdsUse reusable rules for consistent monitoring across endpoint groups.
03

Connect to investigationUse metrics signals alongside process activity, alerts, and cases.
04

Support operationsHelp IT and MSP teams identify unhealthy endpoints before users or customers escalate.
Operating model

Create metrics thresholds and distribute them through endpoint policies.

System Metrics Rules define what endpoint resource conditions should be watched and how they should be surfaced. Rules are attached to policies for compatible agents, then metrics findings can support health review, alert triage, and investigation.

  • Define thresholds for supported CPU, memory, disk, and system-resource signals.
  • Use duration or repeated condition logic where supported to reduce noise.
  • Attach metrics rules through policies for compatible endpoints.
  • Review metrics with process, endpoint health, alerts, and case context.
XDRShield architecture connecting endpoint visibility, investigation, response, and operations
Feature capabilities

What XDRShield System Metrics Rules helps teams do.

Each capability supports the operating workflow for system metrics rules, from configuration and validation to investigation, governance, and follow-up.

Operating workflow

From threshold design to actionable metrics signal.

A repeatable system metrics rules workflow keeps configuration deliberate, validated, and traceable.

Choose metric

Select the endpoint resource signal that needs monitoring.

Set threshold

Define value, duration, and severity expectations.

Attach to policy

Map the rule to the correct endpoint policy and tenant scope.

Validate signal

Review reported metrics and alert behavior after rollout.

Correlate context

Check process activity, agent health, and endpoint workload.

Tune noise

Adjust thresholds or scope based on normal environment behavior.

Common use cases

Where System Metrics Rules helps most.

Use system metrics rules where endpoint security outcomes depend on consistent configuration and evidence-backed review.

Endpoint health monitoring

Detect endpoints under resource stress.

Resource abuse detection

Surface suspicious CPU, memory, or disk spikes.

Process investigation

Correlate metrics spikes with process activity.

Capacity trend review

Use repeated threshold signals for operational planning.

Policy standardization

Apply consistent metrics monitoring across endpoint sets.

MSP operations

Monitor customer endpoint health without mixing tenant scope.

System metrics rule reference

Tune thresholds to environment behavior.

This table helps teams avoid noisy metrics rules.

Area What it means How teams use it
Metric type CPU, memory, disk, or supported system-resource signal. Choose based on the operational or security condition being monitored.
Threshold The value that triggers a finding or alert. Set high enough to avoid normal workload noise.
Duration How long or how often the condition must persist. Use sustained conditions where supported to reduce false positives.
Scope The endpoint group or tenant receiving the rule. Apply different thresholds for servers, desktops, and customer environments.
Operational use

System Metrics Rules for security, IT, and MSP teams.

System Metrics Rules supports day-to-day operations while keeping tenant scope, evidence, and accountable change control clear.

For security and IT teams

Use this feature to keep endpoint protection, detection evidence, and operational decisions aligned with the current environment.

  • Validate configuration before broad rollout.
  • Review evidence before changing rules or policies.
  • Use related alerts, events, cases, and activity logs for context.

Explore endpoint detection →

For MSP and service-provider teams

Use tenant-scoped operation so customer environments stay separated while common workflows remain repeatable.

  • Confirm customer or tenant scope before bulk changes.
  • Standardize configuration patterns across customers.
  • Preserve customer-specific audit and review evidence.

Explore multi-tenant operations →

Questions buyers ask

System Metrics Rules FAQs.

What are System Metrics Rules in XDRShield?

System Metrics Rules define endpoint resource thresholds such as CPU, memory, disk, and related system signals for monitoring and alerting.

How do metrics rules reduce noise?

Teams can tune thresholds, duration expectations, severity, and scope based on normal workload behavior and endpoint type.

How do metrics connect to investigation?

Metrics findings can be correlated with process activity, agent health, alerts, cases, and endpoint context.

How are metrics rules deployed?

Metrics rules are attached to policies and distributed to compatible agents within selected tenant scope.

How can MSP teams use metrics rules?

MSP teams can apply customer-specific metrics monitoring policies and review endpoint health signals by tenant.

Use governed configuration with confidence

Monitor resource signals with context

Use metrics rules to find unhealthy or suspicious endpoints.