CyberPower UPS/ATS/PDU

The CyberPower UPS/ATS/PDU check monitors CyberPower uninterruptible power supplies, automatic transfer switches and rack PDUs over SNMP. Depending on the device type you select, it reports battery status, charge and remaining runtime, output load, input and output voltage, redundant supply status, and which source a transfer switch is currently running on — so a power problem raises an alert before it takes a device offline. One octoja agent on Windows, Linux, or macOS (each in x64 and Arm64 builds) on the same network does the querying; nothing is installed on the power hardware itself. The check runs every 5 minutes by default.

Prerequisites

The most common reason this check never produces a reading is that the CyberPower device has no SNMP interface for octoja to talk to. The check queries the device across the network, so you need:

• The Monitoring Check Management permission.
• A CyberPower device with a network management card (the RMCARD family) or a built-in management network port, reachable by IP address.
• SNMP enabled on that card (v2c or v3), with credentials octoja supports — see below.
• An octoja agent on any device that can reach the card on UDP port 161. It does not have to be a server the UPS powers.

A UPS connected to a server only by USB or serial cable has no SNMP endpoint at all. Installing an agent on that server does not change this — the agent is only the vantage point this check queries from, and no setting in it will make it read a locally attached UPS. Fit a management card if you want the readings listed above. If that is not an option, octoja's separate Power Status check reads the battery state Windows itself reports — on a USB-connected UPS whose HID battery driver is installed, that is the UPS, giving you power source, charge level and estimated runtime, but none of the SNMP detail.

octoja always queries UDP port 161. This check has no port field, so keep the card's SNMP service on the standard port.

Prepare the CyberPower device

Do this in the management card's own web interface, before you add the check. Menu names and layouts differ between card models and firmware versions, so look for the SNMP settings rather than following a fixed click path.

1. Give the card an IP address in a network your octoja agent can reach, and confirm the agent's host can open the card's web interface. That proves routing and the basic firewall path — SNMP still needs UDP 161 open on top of it.
2. Enable the SNMP service. octoja speaks SNMP v2c and SNMPv3. If the card lists v1 and v2c as separate services, make sure v2c is the one enabled — octoja's requests are v2c, and a card answering only v1 will ignore them.
3. Create the credential the check will use: a read community for v2c, or a user for v3 (see the table below). Read access is enough — the check never writes to the device, so there is no reason to hand it a write community.
4. If the card keeps an access list of permitted manager or NMS IP addresses, add the IP address of the octoja agent that will run the check. A missing entry looks exactly like a dead device: the card drops the query without answering and octoja reports a timeout.
5. There is nothing to import anywhere. octoja carries CyberPower's SNMP object identifiers internally, so you do not need to load a MIB file into octoja.

SNMPv3: the combinations octoja supports

If you go the v3 route, the user on the card has to be set up with one of these combinations. Anything else fails authentication even when the user name and passwords are typed correctly.

Some vendors offer two flavours of AES-192 and AES-256. octoja implements the common variant used by net-snmp. If your card labels its options AES-192-C / AES-256-C, that is the other (Cisco) flavour — choose AES-128 instead.

Steps

You can assign the check to a network device as well as to an agent device; pick one of the two ways.

Option A — register the CyberPower device as a network device

octoja can carry the power hardware as its own agentless device, probed by one of your agents. The check's Host field then disappears from the form: octoja uses the network device's current IP address every time the check runs, so a later IP change is picked up automatically instead of leaving a stale value behind.

1. Go to Devices and click Add network device.
2. Pick the Customer this device belongs to — the dialog keeps the save button disabled until you do — then enter a Name and the IP address or hostname of the management card, choose the agent that can reach it under Monitoring assets, and set Device type to UPS.
3. Save, open the new device, then go to the Checks tab → Add Check → CyberPower UPS/ATS/PDU.
4. Choose the matching Device type, fill in the SNMP fields and click Add Check. Host is not shown here — that is expected.

A network device can carry SNMP settings of its own — stored under Enable SNMP in the same dialog, and used for octoja's reachability and inventory probe. When they are set, the check hides its own SNMP version and credential fields and queries the card with the network device's SNMP settings. A different SNMP port stored there is not carried over — the check always queries UDP 161.

Option B — add the check to a device that runs an agent

1. Go to Devices and open the device whose agent can reach the CyberPower hardware.
2. Click the Checks tab → Add Check → CyberPower UPS/ATS/PDU.
3. Enter the management card's hostname or IP address in Host.
4. Choose the matching Device type, fill in the SNMP fields and click Add Check.

octoja pre-fills all thresholds, so you can leave them alone on a first pass — but read the threshold notes below before you do, because the defaults assume a 230 V supply.

Settings

The form shows different fields depending on two of your answers. The SNMP version decides the credential fields: the community string for v2c, the user, protocol and password fields for v3. The device type decides the thresholds: the battery, runtime and load thresholds belong to a UPS, and the voltage thresholds apply to everything except a PDU.

Battery Thresholds — only shown when Device type is UPS

Voltage Thresholds — shown for every device type except PDU

Pick the right Device type

This is the one setting on the octoja side that fails loudly when it is wrong. Each option makes octoja read a different part of the CyberPower data model, and a UPS has nothing where the PDU values live.

If the type does not match the hardware, the check turns critical with "The device returned no data for the selected device type." Nothing else is broken — change the type and the next run recovers.

Threshold notes

• The voltage thresholds assume a 230 V supply: warning below 200 V, critical below 190 V. On a 100–120 V supply, lower both immediately, otherwise the check sits at critical permanently. In general, adjust them to your local grid standard (for example 230 V in Europe, 120 V in North America).
• The battery thresholds are deliberately tight (warning below 95 %, critical below 85 %). A UPS recharging after an outage does not merely pass through a warning: any outage that drained it past 85 % leaves the check critical until the charge climbs back over that mark, and a warning until it reaches 95 %. If you do not want recharge cycles to alert, lower Battery warning (%) and Battery critical (%) together — lowering the warning value alone leaves the critical alert exactly where it was. Keep the warning value above the critical one: if you enter a warning below the critical value, octoja silently swaps the two.
• If warning and critical thresholds are reversed (battery, runtime, load or voltage), the check swaps them automatically before evaluating.
• A PDU check has no thresholds at all. Its status comes from the supply readings — a supply reporting a failure raises critical — while the load current is reported for information only.

Results

The overall result is the worst severity among the conditions that apply. Two details are worth knowing about the voltage thresholds. A UPS running on battery reports an input voltage of 0 V, so the check only judges an input voltage above zero — the on-battery state is already critical on its own. On an ATS or ATS PDU there is no such exception: the voltage thresholds are applied to both sources, and a dead feed reads 0 V. That is intentional — losing one of two feeds raises a critical alert even though the connected load never noticed.

When the UPS reports that its battery needs replacing, the check turns critical and the detail view shows a banner at the top, so you can plan the swap before the next outage. The check also produces charts for battery charge, load, voltages and load current over time.

Collected metrics

The exact values depend on the device type. A UPS reports its power and battery state; an ATS reports which source is feeding the load and whether both inputs are healthy; a PDU reports its output load.

• Device model and firmware version
• UPS status — Online, On Battery, On Boost, On Buck, On ECO, On Bypass, Overload, Sleeping, Rebooting, Off or Unknown
• Battery status — Normal, Low, Not Present or Unknown — and whether the device reports that the battery must be replaced
• Battery capacity (%) and battery temperature (°C)
• Estimated runtime (minutes)
• Output load (%)
• Input voltage (V) and output voltage (V)
• Source 1 and source 2 voltage, which source is currently active, and the number of transfer events (ATS devices)
• Status of each redundant input, and load current (A) (PDU devices)
• Whether communication with the device was lost, and whether the device reports an active alarm

Troubleshooting

When an SNMP query fails, the check writes the reason straight into its result. Match the message to the cause:

Tips

• Configure one check per piece of hardware. If you monitor power hardware at many sites, roll the check out with a config package instead of adding it device by device.

See also: Assign checks with config packages