UPS Alarm Design: Make Email, SNMP and Local Signals Actionable

For IT operations, NOC and facilities teams, the first project decision is this: Which events should be prioritized? Prioritize states that require a defined operational response, such as source loss, low reserve or equipment trouble. Distinguish information from urgent action. A long list of messages is not useful unless recipients understand the affected service and intended response. The practical output is event table: state / service impact / priority / action, supported by UPS event interfaces, alarm recipients and communication dependencies.

Alarm value depends on the path remaining available during an outage, events being distinguishable, and someone being assigned to respond.

Start by naming the events that change what a person should do next. Source loss, low reserve, and equipment trouble all require a response. A self-test pass or a routine log entry usually does not. The test is whether the recipient knows the affected service and the intended action.

The P1 rows share one property: they change the time available or the power delivered to protected equipment. The P2 rows affect confidence in protection without changing immediate service, and P3 is information only. Keeping the list short lets each message name the service it affects.

Email fails during the same outage for a simple reason. The UPS card, the switch, the mail service, and the external link each draw power from somewhere, and that somewhere is often the same circuit that just failed. The power path and the notification path are separate systems, and they must be traced separately.

A configured address proves only that the card can attempt delivery. To confirm the alert survives, walk each hop and mark which ones share the failed circuit. In the illustrative scenario the mail relay is not on the UPS, so the SMTP path dies with the utility feed. The design keeps a local log and an SNMP path to a manager that is on battery.

A trap and a poll are different observations, and they fail in different ways. A trap is the UPS pushing an event to the manager when a condition changes. A poll is the manager asking for current status on a schedule. If the manager stops receiving replies, the cause could be a dead UPS, an unreachable card, or a broken link between them. None of those confirms battery exhaustion.

Define these interpretations in the monitoring system before the first real outage. Treat a missing poll reply as a connectivity alarm and keep it separate from on-battery and low-battery states. A manager should not page for battery exhaustion because it has not heard from the card for two minutes.

An alert with no owner is noise. Assign each event to the person who can perform the required action, and give that person a named escalation path for when the action does not happen.

Facilities and IT both belong on the list where their dependencies overlap, because the battery and the network are usually owned by different teams. Avoid a single generic mailbox. If no one is named for a P1 event, the alert has no operational owner and the design is incomplete.

Repeats and recovery messages need a policy, or a two-hour outage turns into two hundred pages. The goal is to preserve state changes and drop the noise between them.

The timestamps are illustrative. Suppression should only merge or delay messages that repeat the same state. It must never hide a worsening condition, and a recovery message should report the conditions that changed instead of a bare "cleared." Closing the incident requires a check that the service is actually back.

The supplier can only quote what the design specifies. Email, SMS, and trap support vary by card and configuration, so write them into the request instead of assuming every UPS in a family offers the same interfaces.

This list is a project input for a supply discussion. NexPro-Link can take these fields and discuss which equipment and management options fit. On its catalog, the rack-mounted online series NX-UP-RM-001 shows how a series, a configuration, and a rating line up: configuration C2KR(S) is rated 2,000 VA and 1,800 W with internal VRLA batteries. That line is a catalog example. The scenario's own interfaces and delivery paths determine the fitting.