VMware vSphere Alarm Actions Explained
Learn how vSphere alarm actions work, which inventory objects support them, how state transitions control execution, and how to automate safely.
A VMware vSphere alarm action is an operation configured to occur when an alarm reaches a specified state transition. The operation may notify administrators, inform an external monitoring system, or perform scripted or infrastructure remediation.
Alarm actions do not define what vSphere monitors. The alarm trigger is the event, condition, threshold, or metric that causes alarm evaluation. The alarm definition combines the monitored condition, alarm states, and actions that respond when the state changes.
How alarm actions work
An alarm normally evaluates a managed inventory object such as a virtual machine, host, datastore, or cluster. When the monitored condition changes, the alarm may move from one state to another. vSphere then checks whether an action is assigned to that exact transition.
| Concept | Meaning |
|---|---|
| Alarm trigger | The monitored event or condition that causes an alarm evaluation and possible state change. |
| Alarm state | The current condition of the alarm: Normal, Warning, or Critical. |
| State transition | A change from one state to another, such as Warning to Critical. |
| Alarm action | The notification or operation configured for a particular state transition. |
This distinction is important: a condition can remain Critical without repeatedly invoking an action configured to run only when the alarm first enters Critical. Repeated execution requires the action behavior to be set to Repeat.
Inventory objects that can have alarm actions
Alarm definitions can be associated with the following vSphere inventory object types. The action list depends on the object being monitored. Common notification and command actions can be used across these scopes, while lifecycle and power operations are limited to the appropriate object type.
| Object type | Common actions available | Additional object-specific actions |
|---|---|---|
| Virtual Machines | Send email, send SNMP trap, run command | Power on, power off, suspend, reset, and migrate the VM |
| Hosts | Send email, send SNMP trap, run command | Enter or exit maintenance mode, enter or exit standby mode, reboot, and shut down |
| Clusters | Send email, send SNMP trap, run command | No host- or VM-specific operation is implied by the cluster scope |
| Datacenters | Send email, send SNMP trap, run command | No host- or VM-specific operation is implied by the datacenter scope |
| Datastores | Send email, send SNMP trap, run command | No host- or VM-specific operation is implied by the datastore scope |
| Distributed Switches | Send email, send SNMP trap, run command | No host- or VM-specific operation is implied by the switch scope |
| Distributed Port Groups | Send email, send SNMP trap, run command | No host- or VM-specific operation is implied by the port-group scope |
| Datastore Clusters | Send email, send SNMP trap, run command | No host- or VM-specific operation is implied by the datastore-cluster scope |
| vCenter Server | Send email, send SNMP trap, run command | No host- or VM-specific operation is implied by the vCenter Server scope |
Common alarm action types
Send an email notification
An email action informs administrators or an operations team that an alarm transition occurred. Email is useful for warnings, critical alerts, and recovery notifications. A one-time email is often appropriate when a message should be sent once rather than repeatedly while the condition persists.
Send an SNMP trap notification
An SNMP trap is a notification sent to an SNMP management system. It allows an external monitoring platform to receive, correlate, and escalate vSphere alarm events alongside alerts from other infrastructure.
Run a command or script
A command action starts a configured command or script for automated remediation or integration. Use a command designed for unattended execution. It should log its results and failures, handle missing dependencies, and be safe when executed more than once if the action uses Repeat.
| Action | Available for all listed object types | Host only | Virtual machine only | Operational purpose |
|---|---|---|---|---|
| Send email notification | Yes | No | No | Inform administrators |
| Send SNMP trap notification | Yes | No | No | Inform external monitoring systems |
| Run command | Yes | No | No | Perform controlled scripted remediation or integration |
| Enter maintenance mode | No | Yes | No | Prepare a host for maintenance and remove or evacuate workloads as applicable |
| Exit maintenance mode | No | Yes | No | Return a host to normal service |
| Enter standby mode | No | Yes | No | Place a host in a reduced-power state |
| Exit standby mode | No | Yes | No | Return a standby host to service |
| Reboot host | No | Yes | No | Restart the host |
| Shut down host | No | Yes | No | Power off the host |
| Power on VM | No | No | Yes | Restore a powered-off VM service |
| Power off VM | No | No | Yes | Stop a VM, potentially without guest operating system shutdown |
| Suspend VM | No | No | Yes | Pause VM execution and preserve its state |
| Reset VM | No | No | Yes | Restart a VM using a potentially disruptive reset |
| Migrate VM | No | No | Yes | Move a VM to another suitable placement |
Host-specific alarm actions
Host alarm definitions provide lifecycle actions in addition to common notifications and command actions:
- Enter maintenance mode: prepares the host for maintenance and may require workload removal or evacuation.
- Exit maintenance mode: returns the host to normal service.
- Enter standby mode: places the host in a reduced-power state.
- Exit standby mode: returns the host from standby to service.
- Reboot the host: restarts the ESXi host.
- Shut down the host: powers off the host.
Virtual machine-specific alarm actions
Virtual-machine alarm definitions provide these VM operations in addition to common actions:
- Power on: starts a powered-off VM.
- Power off: stops a VM and may not provide a graceful guest operating system shutdown.
- Suspend: pauses VM execution so it can later resume from its saved state.
- Reset: restarts the VM and can be disruptive to guest applications and unsaved data.
- Migrate: moves the VM to another suitable placement, subject to available resources and compatibility.
Choose the least disruptive action that satisfies the recovery objective. Power on may restore a stopped service, while reset may be appropriate only when a guest is unresponsive and a controlled restart is acceptable. Do not treat power off and reset as equivalent to graceful operating-system shutdown.
Alarm state transitions that invoke actions
Actions are assigned to state transitions, not merely to the current state. The commonly configured transitions are:
| From state | To state | Typical use | Available execution choices |
|---|---|---|---|
| Normal | Warning | Early notification, such as a datastore capacity warning | No action, Once, or Repeat |
| Warning | Critical | Escalation to administrators, monitoring systems, or remediation | No action, Once, or Repeat |
| Critical | Warning | Partial recovery or reduced severity notification | No action, Once, or Repeat |
| Warning | Normal | Recovery notification when the condition clears | No action, Once, or Repeat |
For example, an email assigned to Normal to Warning does not automatically run when the alarm later becomes Critical. If a critical notification is required, configure an action for Warning to Critical as well.
State indicators in the alarm action interface
The alarm action configuration uses visual indicators for the three alarm states:
- Normal: a green circle, representing a healthy condition.
- Warning: a yellow triangle, representing an intermediate problem state.
- Critical: a red diamond, representing a severe problem state.
These icons identify the endpoints of transition choices. A transition from the green Normal circle to the yellow Warning triangle is Normal to Warning. A transition from the yellow Warning triangle to the red Critical diamond is Warning to Critical. Recovery paths include Critical to Warning and Warning to Normal.
Action execution frequency
| Choice | Behavior | Repeat timing | Best-use consideration |
|---|---|---|---|
| No action | No action is taken for that transition. | Not applicable | Use when the transition should be recorded but not notify or remediate. |
| Once | Runs the selected action one time when the transition occurs. | Not applicable | Good for one-time emails, SNMP traps, and controlled recovery operations. |
| Repeat | Continues to run the selected action until the alarm undergoes another state change. | Default interval is five minutes | Use only when repeated notification or remediation is necessary and safe. |
If an alarm remains in the same state, a Once action does not run again merely because the condition is still present. A Repeat action continues at its configured interval until a subsequent state change.
Configuring an alarm action
- Select the inventory object type to monitor.
- Create or edit the alarm definition.
- Configure the alarm trigger conditions and thresholds.
- Open the Actions configuration area.
- Choose the state transition, such as Warning to Critical or Warning to Normal.
- Add the applicable email, SNMP, command, host, or VM action.
- Set the execution behavior to Once or Repeat, or leave the transition with No action.
- If using Repeat, review the default five-minute interval and confirm that the frequency is appropriate.
- Test the alarm behavior and confirm that notifications arrive or scripts execute as intended.
Command action requirements
- Design the script or command for unattended execution.
- Make repeated execution safe and idempotent when Repeat is configured. An idempotent operation produces the intended result without harmful duplicate work.
- Log command start, completion, output, and failures.
- Handle network failures, missing credentials, unavailable dependencies, and partial completion.
- Test command-based remediation outside production before attaching it to critical alarms.
Practical configuration examples
Datastore warning email
For a datastore alarm, assign Send email notification to the Normal to Warning transition and select Once. This provides an early warning without generating repeated messages while the datastore remains in Warning.
Critical VM issue sent to SNMP monitoring
For a virtual machine alarm, assign Send SNMP trap notification to Warning to Critical and select Once. The external monitoring platform can correlate the critical event with other infrastructure alerts.
Repeated remediation for a cluster or datastore
For a cluster or datastore alarm, assign Run command to Warning to Critical and select Repeat. The default repeat interval is five minutes. The script must be idempotent, log its results, and include safeguards against duplicate work or worsening the incident.
Host maintenance response
For a host alarm, assign Enter maintenance mode to Warning to Critical and select Once. Before using this design, verify workload evacuation behavior, available cluster capacity, admission-control effects, storage and network dependencies, and the possibility of an alarm caused by a false positive.
VM service recovery
For a VM alarm that indicates a service needs recovery, choose Power on or Reset as appropriate and run it Once on Warning to Critical. Power on is suitable for a powered-off VM; reset is more disruptive and should be reserved for a defined recovery case.
Recovery notification
For any supported alarm object, assign Send email notification to Warning to Normal and select Once. This closes the incident loop by confirming that the condition cleared.
Safe alarm action design
- Use notification actions for visibility and command actions for controlled remediation.
- Prefer Once for informational notifications unless repeated escalation is explicitly required.
- Use Repeat carefully to avoid repeated emails, SNMP traps, or script executions.
- Validate email recipients, SNMP destinations, network reachability, and command dependencies before production use.
- Test scripts with non-disruptive conditions and verify their execution context and permissions.
- Treat host shutdown, host reboot, VM power operations, and VM reset as high-impact automated responses.
- Document the business and technical reason for every disruptive action.
- Use change control and approval for production remediation that can affect availability.
Troubleshooting alarm actions
An expected action does not run
- Confirm that the alarm actually changed through the transition associated with the action.
- Verify that an action is configured for that exact transition.
- Check that the action behavior is not set to No action.
- Confirm that the selected action is valid for the alarm object type.
The action ran once but does not keep running
- Check whether the action is configured as Once instead of Repeat.
- Confirm that the alarm remains in the relevant state and has not transitioned again.
- Review the repeat interval, which defaults to five minutes.
Repeated alerts or scripts create excessive noise
- Determine whether Repeat is necessary for the transition.
- Use Once for informational notifications when repeated escalation is not required.
- Make remediation scripts idempotent and add safeguards against duplicate work.
A host or VM action is unavailable
- Verify that the alarm is attached to the correct inventory object type.
- Host lifecycle actions are specific to host alarms.
- VM power, suspend, reset, and migration actions are specific to virtual-machine alarms.
Email, SNMP, or command actions fail
- Validate the relevant email, SNMP, or integration configuration.
- Confirm network reachability to mail, SNMP, or script dependencies.
- Review permissions and the execution context for command-based actions.
- Perform a controlled test using a non-disruptive alarm transition.
Exam-relevant summary
- An alarm trigger detects or evaluates a condition; an alarm action responds to a state transition.
- Normal is shown as a green circle, Warning as a yellow triangle, and Critical as a red diamond.
- Actions can be assigned independently to Normal to Warning, Warning to Critical, Critical to Warning, and Warning to Normal.
- No action means nothing runs, Once runs one time, and Repeat continues until another state change.
- The default Repeat interval is five minutes.
- Email and SNMP actions provide notification; command actions provide scripted automation.
- Host maintenance, standby, reboot, and shutdown actions are host-specific.
- VM power, suspend, reset, and migration actions are virtual-machine-specific.
For a concise reference while configuring alarms, see vSphere alarm actions.