How to Create and Manage Virtual Machine Alarms in VMware vCenter Server

Learn how to create a vCenter Server alarm for a virtual machine, configure warning and critical CPU thresholds, send email notifications, and acknowledge or reset alarms.

A vCenter Server alarm is a monitoring definition applied to an inventory object. It watches for a configured event, condition, or state change and can change state or execute an automated response when that condition occurs.

Alarms differ from general performance monitoring. A performance chart shows measurements and trends; an alarm evaluates those measurements against rules that you define. For example, an alarm can change to warning when VM CPU usage exceeds 20% for 30 seconds and change to critical when it exceeds 30% for the same duration.

What vCenter Server alarms monitor

An inventory object is a resource managed by vCenter Server. Common alarm-capable objects include virtual machines, ESXi hosts, datastores, and networks.

Object type — Examples of monitored conditions — Typical operational use

Virtual machines — CPU usage, power state, VMware Tools state, or guest-related conditions — Detect workload pressure or guest availability problems.

ESXi hosts — Host health, connectivity, resource usage, or hardware events — Identify host failures and capacity issues.

Datastores — Free capacity, latency, or accessibility — Prevent storage exhaustion and detect storage performance problems.

Networks — Connectivity or network state changes — Identify network availability problems.

Create the alarm at the scope that matches the requirement. A VM-specific alarm is suitable when one workload needs a distinct policy. A broader alarm at a folder, cluster, or other supported scope may be more appropriate when the same rule should apply to many objects. Check the inheritance behavior of your vSphere version before assuming that a definition applies to child objects.

Prerequisites and planning

Confirm that you can access the vCenter Server managing the VM.
Confirm that your account has permission to create or modify alarm definitions. If needed, review vCenter permissions and the access control system.
Confirm that the target virtual machine is present in the vCenter inventory.
Review normal and peak workload behavior before choosing thresholds. A threshold that is too low creates noise; one that is too high may delay investigation.
Confirm that outbound email or SMTP notification is configured if email actions will be used.
Identify an actionable administrator, operations team, or monitoring distribution list as the recipient.

Decide in advance what warning and critical mean operationally. Warning should indicate that attention may be needed. Critical should represent a more serious or sustained condition that requires prompt investigation.

Alarm states and transitions

The alarm state describes the current result of the trigger evaluation:

Normal or green: The monitored condition is healthy or is not breaching a configured threshold.
Warning or yellow: A lower-severity condition has been detected and may require attention.
Critical or red: A high-severity condition requires prompt investigation or remediation.

A condition can move an alarm from normal to warning or critical. If the condition clears, the alarm can return to normal according to its recovery and reset behavior. A critical condition normally supersedes a warning condition because it represents the more serious evaluation result.

Alarm state — Example trigger — Recommended action — Notification frequency

Normal — VM CPU is below the warning threshold — No incident action; continue normal monitoring — None, or a recovery notification if your policy requires one.

Warning — CPU exceeds 20% for 30 seconds — Review workload and trend — Send one notification when the state is entered.

Critical — CPU exceeds 30% for 30 seconds — Investigate and escalate as needed — Notify on entry and repeat at a controlled interval while critical remains active.

Open alarm definitions for a virtual machine

Select the target VM in the vCenter inventory.
Open Manage for the selected VM.
Locate Alarm Definitions.
Use the add control to start a new alarm definition.

Names and labels can vary slightly between vSphere releases and management interfaces, but the workflow is generally the same. For background on alarm concepts and trigger categories, see alarms in vSphere and alarm trigger types.

Create a VM alarm definition

1. Name the alarm

Give the definition a name that explains its scope, metric, threshold intent, and severity. For example:

PROD-APP01 - VM CPU Usage Escalation

A useful name makes the alarm understandable in an alert list without opening its details. Where practical, include the object or scope, metric, threshold, and duration in the name or description.

2. Choose condition-based monitoring

Choose an alarm type that monitors a specific condition or state rather than relying only on event occurrence. Event alarms are useful for discrete actions or changes; a performance condition alarm is appropriate when a metric must remain above or below a threshold.

3. Add a trigger condition

A trigger condition is the rule that causes a state transition. Configure these elements:

Metric or state: Select VM CPU usage for this example.
Comparison operator: Select an operator such as greater than.
Threshold: Enter a warning value and a critical value.
Duration: Specify how long the condition must remain true.

The duration is a persistence requirement. It prevents a short-lived spike from immediately generating an alarm. Warning and critical values should reflect increasing seriousness; the critical threshold is normally higher for a metric where larger values are worse.

Example CPU policy

Setting — Warning configuration — Critical configuration

Metric — VM CPU usage — VM CPU usage

Threshold — Greater than 20% — Greater than 30%

Sustained duration — 30 seconds — 30 seconds

Email recipient — Designated administrator or operations recipient — Operations or escalation recipient

Initial notification — Send one email when warning begins — Send an email when critical begins

Repeat interval — No repeat — Every 5 minutes while critical remains active

Clear or reset behavior — Return to normal when the condition clears according to the alarm policy — Stop escalation after recovery or an appropriate reset

Name: VM CPU Usage Escalation
Object scope: Single virtual machine
Monitoring type: Specific condition or state
Metric: Virtual machine CPU usage
Warning: Greater than 20% for 30 seconds
Critical: Greater than 30% for 30 seconds
Warning action: One email to the designated recipient
Critical action: Email on entry, then repeat every 5 minutes while critical

Configure alarm actions and email notifications

An alarm action is an automated response performed when an alarm enters or remains in a specified state. Add one or more actions to the warning and critical states. For email, configure the recipient for each action and verify that vCenter Server can relay outbound mail.

Use a one-time warning notification for the initial indication. Configure a critical action to send an email when the alarm becomes critical and repeat it at a defined interval while the critical state remains active. Repetition normally stops when the alarm recovers or is reset, depending on the configured behavior.

Warning and critical actions do not have to be identical. Warning may notify the VM owner or primary administrator, while critical may notify an operations queue or escalation list. Repeated messages improve visibility for unresolved incidents but can cause alert fatigue. Use reasonable intervals and recipients who can act on the alert.

Acknowledge, reset, and clear an alarm

Acknowledgement records that an operator has seen the alarm and is handling it. It supports ownership and reduces uncertainty in an operational workflow, but it does not necessarily correct the underlying condition or change the actual health evaluation.

Recovery occurs when the monitored metric no longer breaches its threshold and the alarm behavior permits an automatic return to normal. A manual reset forces the alarm back to normal where that operation is supported. Resetting an alarm without resolving its cause is temporary; the alarm can immediately trigger again if the condition remains true.

Operation — What it means — Does it fix the condition? — Effect on state and notifications

Acknowledge — An operator has seen or taken ownership of the alarm — No — Records handling; the alarm can remain yellow or red and repeated actions may continue.

Automatic recovery — The triggering metric or state has cleared — Usually indicates the condition has improved — The alarm can return to green and recurring actions normally stop.

Manual reset — An authorized operator returns the alarm to normal manually — No, unless the cause was also resolved — State is reset, but the alarm can trigger again and action behavior may change according to policy.

For a critical CPU alarm, acknowledge it to show that investigation has started, then examine the guest workload, host resources, and recent changes. Do not treat acknowledgement as resolution. Reset or rely on automatic recovery only after the condition has been addressed or a deliberate operational decision has been made. See acknowledging an alarm for the operator workflow.

Verify the completed alarm

Review the alarm name and confirm that it is attached to the intended VM or scope.
Verify the selected metric, comparison operator, warning and critical thresholds, and duration.
Confirm that warning and critical actions are attached to the correct states.
Check recipients, one-time behavior, and the critical repeat interval.
Check the VM's current alarm status after saving the definition.
Where possible, use a controlled workload or test condition to validate state transitions and email delivery. Avoid creating unsafe production load just to test an alarm.
Confirm that the observed behavior matches the intended escalation policy, including recovery and repeat-notification handling.

Alarm design recommendations

Use performance baselines and business impact to choose thresholds instead of copying arbitrary values to every VM.
Use a persistence duration long enough to ignore harmless transient spikes.
Keep warning and critical thresholds far enough apart to make escalation meaningful.
Include metric, threshold, duration, and scope in the name or description where practical.
Use actionable recipients and avoid sending alerts to people who cannot investigate or remediate the issue.
Review alarm definitions, recipients, and notification cadence periodically.
Consider whether a single-VM alarm or a broader inherited scope is the better maintenance choice.

Troubleshooting alarm behavior

The alarm never changes to warning or critical

Confirm that the selected metric or state is the intended one.
Compare live or historical VM CPU data with the configured thresholds.
Confirm that the condition persists for the required duration; a brief spike is not sufficient.
Verify that the definition targets the correct VM and inventory scope.
Check whether performance data is unavailable or delayed.

The alarm triggers too frequently

Review whether the threshold is below normal operating levels.
Increase the duration when brief spikes are harmless.
Adjust the repeat interval if recurring messages are too aggressive.
Revisit the baseline, scheduled jobs, and escalation recipients.

Email notification does not arrive

Validate outbound mail settings and relay availability.
Check the recipient address.
Confirm that the email action is attached to the state that the alarm actually entered.
Review the alarm event and state transition in the vSphere interface.

Repeated critical notifications continue after acknowledgement

Acknowledgement indicates that an operator saw the alarm; it does not clear a still-active critical condition. Confirm whether CPU usage remains above the critical threshold, whether the alarm has been reset, and whether the repeat action is configured to continue while the alarm is red.

The alarm returns to critical immediately after reset

The triggering condition probably remains true. Investigate CPU demand inside the guest and resource contention at the host level, resolve the sustained utilization problem, and then allow recovery or perform the reset procedure.