VMware ESXi and vSphere Cluster Management

Alarms in VMware vSphere: Monitoring, Triggers, Actions, and Configuration

Learn how vSphere alarms monitor inventory objects, evaluate triggers, change severity, send notifications, and support safe operational remediation.

What are vSphere alarms?

A vSphere alarm is a rule managed by vCenter Server that monitors an inventory object for a specified event, state, or condition. When the rule matches, the alarm can change state and perform one or more configured actions.

For example, an alarm can detect that a datastore is running low on free space, that a virtual machine has sustained high CPU usage, or that an ESXi host has changed power or connection state.

Alarms provide proactive visibility. Without them, an administrator must repeatedly inspect performance charts, object health, events, and capacity information manually. An alarm instead highlights a condition when it deserves attention.

Why vCenter Server is required

Alarm functionality is provided by vCenter Server and its inventory management services. vCenter maintains the managed-object hierarchy and evaluates alarm definitions against supported objects.

If you connect directly to an individual ESXi host, you can manage that host and its local resources, but you cannot create and manage vCenter inventory alarms in the same way. Connect to the appropriate vCenter Server when configuring alarms.

Alarms can be associated with different inventory levels. Depending on the object and alarm definition, an alarm configured at a higher level can apply to child objects through the inventory hierarchy. Always confirm the effective scope before enabling notifications, especially when configuring an alarm at a datacenter, cluster, or folder level.

Inventory objects monitored by alarms

Supported alarm targets include virtual machines, ESXi hosts, datastores, networks, vCenter Server, and other inventory objects supported by the vSphere version and client interface in use. Available triggers differ by object type.

Virtual machine — CPU or memory utilization, power-state events, guest or VMware Tools-related conditions, and selected health states. A common use is notifying an application owner about sustained high CPU usage.

ESXi host — connection and availability changes, power-status events, resource conditions, and host health information. A host power-state change can require immediate investigation.

Datastore — free capacity, accessibility, connectivity, and storage-related states. A free-space alarm gives administrators time to expand storage, migrate workloads, or remove unnecessary data.

Network — supported network availability, connectivity, and operational conditions. The exact conditions depend on the network object and vSphere release.

vCenter Server and other supported objects — management, health, event, and state conditions exposed by vCenter. Review the available trigger list for the selected object rather than assuming that every trigger applies everywhere.

Alarm trigger categories

A trigger is the event, state change, or metric condition that causes an alarm to evaluate or change state. The most useful way to select a trigger is to start with the operational question: what should the team know, and when?

Condition- or metric-based — Monitors a measured value or resource condition. Examples include CPU utilization above a percentage, memory consumption above a limit, or datastore free space below a percentage.

Event-based — Reacts to an event reported by vCenter. Examples include a virtual machine power-state change or an ESXi host changing operational state.

State-based — Monitors an object state such as warning, unhealthy, disconnected, inaccessible, or another relevant status exposed by vSphere.

An alarm can contain more than one condition. Depending on the configuration, all conditions may need to be true, or one matching condition may be sufficient. This logic matters: combining conditions too restrictively can prevent an alarm from ever activating, while broad single-condition logic can produce excessive notifications.

Duration and persistence

For performance conditions, a sustained threshold is usually more useful than an alert for every short spike. For example, a virtual machine that briefly reaches high CPU usage may be normal, while usage that remains high for an agreed monitoring period may indicate contention or an application problem.

Alarm states, thresholds, and severity

Most alarm designs use three practical states:

Normal means the monitored object is within the expected range or no relevant event is active.
Warning means attention may be required, but immediate intervention may not yet be necessary.
Alert or alarm means the condition has reached a higher-severity level and requires prompt investigation or response.

For a metric alarm, define a boundary for entering warning and another for entering alert. A datastore alarm might enter warning when free capacity falls below an early planning threshold and enter alert when free capacity reaches a more urgent level.

Recovery criteria are equally important. A clear condition determines when the alarm returns to normal, such as free capacity rising above a recovery level or a disconnected host reconnecting. Without a sensible recovery rule, an alarm can remain active after the underlying problem has been corrected.

State transitions determine when actions execute. An email might be sent only when an object enters alert, while a monitoring integration may receive notifications when the object enters warning, enters alert, and returns to normal.

Normal to warning — The early threshold or state criterion is reached. Operational meaning: begin investigation or planned corrective work. Possible action: send a lower-priority email or create a monitoring event.

Warning to alert — The more serious threshold or state criterion is reached. Operational meaning: prompt response is required. Possible action: send an urgent notification, open a ticket, or send an SNMP trap.

Alert to normal — The recovery condition is met. Operational meaning: the monitored problem appears resolved. Possible action: send a recovery notification or close a related monitoring event.

Any relevant event transition — A significant event occurs, such as a host power-status change. Operational meaning: the event itself requires attention. Possible action: notify the operations team immediately.

Built-in vCenter alarms

vCenter includes predefined alarms for common infrastructure conditions. Representative examples include host power-status changes, low datastore free space, and high virtual-machine CPU usage.

Review the built-in definitions before creating a new alarm. A predefined alarm may already monitor the required object and condition, reducing duplicate configuration and notification noise. Inspect its scope, trigger logic, thresholds, enabled state, and actions.

A built-in alarm may not fit local requirements. It could be too broad, use thresholds that do not match the workload baseline, or lack the email, SNMP, ticketing, or script action required by the operations policy. In those cases, adjust the definition where appropriate or create a carefully scoped custom alarm.

Scope — Built-in alarms provide common coverage; custom alarms can target a more specific inventory location or workload.

Trigger logic — Built-in definitions use predefined conditions; custom alarms allow local event, state, and metric logic where supported.

Thresholds — Built-in values may be generic; custom values can reflect historical baselines, capacity lead time, and service requirements.

Actions — Built-in alarms may not use the required recipients, receiver, ticketing workflow, or approved script.

Creating a custom alarm

Select the target. Choose the appropriate virtual machine, host, datastore, network, vCenter object, or inventory level. Confirm whether child objects inherit the alarm.
Use a clear name. Include the object or scope, condition, severity purpose, and possibly the owner. For example, “Production Datastores - Free Space Capacity” is more useful than “Storage Alarm 1.”
Document the purpose. Describe what is monitored, why the threshold matters, who owns the response, and what recovery means.
Choose the trigger type. Select an event, state, or measured condition that is supported for the selected object.
Define the logic. Decide whether one condition is sufficient or whether all conditions must be satisfied. Add a persistence or duration requirement when transient activity should not trigger an incident.
Set severity levels. Define normal, warning, and alert criteria, including recovery thresholds or clear conditions.
Assign actions. Select email, SNMP trap, command or script, or another supported response. Tie each action to the relevant transition.
Enable and test safely. Use a controlled test where possible. Confirm that the alarm changes state, the expected action runs, the notification arrives, and the alarm returns to normal correctly.

Do not copy generic thresholds without review. A CPU value that is normal for one workload may indicate a problem for another. Storage thresholds should leave enough time to expand a datastore, migrate workloads, or perform approved cleanup before capacity becomes critical.

Alarm actions

An alarm action is the configured response to an alarm state transition. Actions should be assigned to specific transitions rather than enabled indiscriminately.

Email notifications

Email is useful for notifying virtualization administrators, application owners, or an operations distribution list. Before email actions can succeed, configure the vCenter Server mail or SMTP settings with an approved mail server or relay.

Define a valid sender identity that recipients recognize.
Use an operational distribution list or clearly assigned recipient rather than an unattended personal mailbox.
Confirm that the recipient owns the response and understands the severity convention.
Test delivery and check mail-relay, spam-filter, and mail-system logs if the message is not received.
Verify that the email action is attached to the transition that actually occurred, such as entering warning or entering alert.

Exact fields and menus vary by vCenter version. Verify DNS resolution and network connectivity between vCenter Server and the mail service as part of the configuration test.

SNMP traps

An SNMP trap is an asynchronous Simple Network Management Protocol notification sent to an SNMP management platform. Traps allow vCenter alarm activity to enter centralized monitoring, dashboard, ticketing, escalation, and correlation workflows.

Configure vCenter Server with the designated SNMP receiver address.
Use the SNMP version, credentials, community settings where applicable, and security options approved by organizational policy.
Ensure that the network path and firewall rules permit the required traffic.
Confirm that the receiving platform accepts and interprets the trap.
Test a known alarm transition and check receiver-side logs.

Command and script actions

A command action can call an approved script or executable to initiate a controlled operational workflow. Appropriate examples include opening a ticket, collecting non-disruptive diagnostic data, notifying an orchestration system, or recording capacity details for reporting.

Before enabling a command action, validate the execution context, executable path, interpreter, permissions, environment variables, inputs, return codes, and audit logging. The script must handle repeated execution safely because an alarm can remain active or transition more than once.

Use safe input handling and avoid trusting object names or event data as shell commands.
Write logs that include the time, affected object, action, result, and error details.
Return meaningful success and failure codes.
Prefer idempotent operations, where repeating the action does not create additional damage.
Test outside production and use change control before enabling automation.
Avoid destructive remediation, such as deleting data or powering off workloads, unless it has been rigorously tested, approved, and protected by suitable safeguards.

Practical alarm designs

Datastore capacity warning

Target a datastore and monitor free capacity. Enter warning at an early threshold and alert at a more urgent threshold. The thresholds should provide enough time to expand storage, migrate workloads, or remove unnecessary data.

Warning action: email the virtualization operations team.
Alert action: send an SNMP trap to centralized monitoring and send an urgent email.
Optional command action: record the datastore name, free-space value, timestamp, and trend in a ticketing or reporting system.
Recovery action: notify the monitoring workflow when free space returns above the recovery threshold.

High virtual-machine CPU utilization

Target a virtual machine and monitor CPU usage above an agreed threshold for a defined duration. Use warning for sustained elevated usage and alert for severe or longer-duration saturation.

Compare the threshold with the workload’s normal baseline.
Notify the application or virtualization team.
Create a service ticket containing the VM name, timestamp, observed value, and alarm state.
Investigate contention, application behavior, sizing, and host capacity before changing resources.

ESXi host power-state change

Use an event-based alarm when a host changes power or connection state. This is appropriate when the event itself is operationally significant and should be reported immediately.

Send an immediate email to the operations team.
Send an SNMP trap for correlation with hardware, network, and facility monitoring.
Check recent vCenter events, host connectivity, hardware status, and any related maintenance activity.

Automated diagnostic collection

For a recurring health or resource condition, an alert transition can invoke an approved script that collects non-disruptive diagnostic information and forwards the output to an incident workflow.

Evidence collection is generally safer than automatic production changes. The action should be bounded, logged, permission-limited, and tested against repeated alarm transitions.

Alarm investigation: events, tasks, and logs

Alarm activity should be investigated together with vCenter events, tasks, and logs. An alarm tells you that a rule matched; the surrounding event and task history helps explain what happened and whether an action succeeded.

Common logging severity concepts include:

Informational — normal operations, state changes, or expected activity.
Warning — a condition that may become a problem or deserves attention.
Error — an operation or component did not behave as expected.
Critical — a severe condition requiring urgent response.

During an investigation, document the time, affected object, observed metric or event, alarm state, related vCenter events, action outcome, and recovery status. This record helps distinguish a genuine infrastructure issue from a configuration error or transient condition.

Troubleshooting alarms

Alarm never changes state — Check the target object, inventory scope, supported trigger type, current metric or state, warning and alert criteria, duration, enabled status, and whether multiple conditions are combined too restrictively.

Alarm changes state but no email arrives — Check vCenter SMTP settings, sender and recipient addresses, DNS and network connectivity, mail-relay logs, spam filtering, and the transition to which the email action is attached.

No SNMP trap is received — Check the receiver address, SNMP version and security settings, firewall rules, network reachability, receiver-side processing, and the action’s state-transition assignment.

Command action fails or behaves unexpectedly — Check the script path, interpreter, execution permissions, working context, input handling, return code, logs, and repeated-execution behavior. Test the script in a controlled environment.

Too many alarms are generated — Compare events with historical workload baselines. Raise thresholds where appropriate, add a persistence duration, remove duplicate alarms, and define one owner for each actionable notification.

Operational practices

Use actionable thresholds. An alarm should identify a condition that someone can investigate or act upon.
Use sustained conditions for workload metrics when short spikes are normal.
Assign an owner, escalation path, and expected response for important alarms.
Use consistent names, descriptions, categories, and severity conventions.
Review built-in alarms before creating duplicates.
Remove obsolete alarms after workload, capacity, or architecture changes.
Review alarm definitions periodically and after major vCenter, host, storage, or network changes.
Test email delivery, SNMP reception, and command actions after upgrades or related configuration changes.
Keep automated actions low-risk, permission-limited, observable, and subject to change control.
Document recovery behavior so operators know when an alarm should clear and whether a separate recovery notification is expected.

Configuration checklist

Connect to vCenter Server rather than directly to an ESXi host.
Identify the object and inventory scope that should be monitored.
Review applicable built-in alarms.
Define a clear name, description, owner, and escalation path.
Select a supported event, condition, or state trigger.
Set workload-appropriate warning, alert, and recovery criteria.
Choose actions for the required state transitions.
Configure and test SMTP before relying on email actions.
Configure and test the approved SNMP receiver before relying on traps.
Validate scripts for permissions, safe inputs, logging, return codes, and non-destructive behavior.
Perform a controlled state-change test and verify both activation and recovery.
Record the result and schedule periodic review.

Key exam and operations notes

vSphere alarms are a vCenter Server inventory feature; direct connection to only an ESXi host is not sufficient for creating vCenter alarms.
Alarm targets can include virtual machines, ESXi hosts, datastores, networks, vCenter Server, and other supported inventory objects.
Triggers may be metric-based, event-based, or state-based, and trigger availability varies by object type.
Warning and alert thresholds describe severity escalation; recovery criteria describe how the alarm returns to normal.
Actions execute on configured state transitions, not merely because an alarm definition exists.
Email requires working vCenter SMTP configuration, SNMP requires a reachable and compatible receiver, and command actions require secure execution design.
Logs, events, and tasks provide the context needed to determine whether an alarm reflects a real problem, a configuration issue, or a transient condition.

For a concise reference to the subject, see Alarms in vSphere.