A UPS is easy to trust and surprisingly easy to misunderstand. The display says 100 percent, the NAS says the USB cable is connected, and the whole setup looks finished. Then the first real outage arrives and the battery drops immediately, the server never receives the shutdown event, or the UPS turns off before the machines finish writing data.
I do not wait for a storm to find those problems. I test the UPS in small, controlled steps. This is the companion to my guide to choosing a UPS for a NAS and home server, but the focus here is operational: how to prove that the battery, load, USB link, and automatic shutdown path work together.
Start with the inventory
Before touching the power cord, write down what the UPS protects. My critical load is the NAS, the virtualization host that runs important services, the network switch, and the router. Monitors, gaming PCs, laser printers, and anything with a large heater or motor stay off the battery-backed outlets unless there is a specific reason to include them.
I record the UPS model, battery installation date, firmware if available, rated watt capacity, and the devices connected to each outlet group. I also note which machine owns the USB connection. That machine is the NUT server or the platform’s equivalent, and it must remain available long enough to tell the rest of the network to shut down.
The outlet map matters because a UPS may have surge-only outlets beside battery-backed ones. A NAS plugged into the wrong group can lose power instantly while the display continues to report a healthy battery. I label the cable ends and take a photo after the layout is correct.
Check the easy signals first
I begin with the UPS’s built-in self-test and status page. I want to see battery charge, estimated runtime, load percentage, input voltage, output voltage, and whether the unit reports an internal fault. I take a screenshot or write the values down because a number without a date is not a useful trend.
A self-test is a health hint, not a proof of runtime. It can catch a disconnected battery or an obvious electrical fault, but it does not prove that a real load will remain stable for several minutes. It also does not prove that NUT, TrueNAS, Synology, Unraid, or the server operating system will react to an on-battery event.
I compare the displayed load with a physical meter when the numbers look suspicious. A Kill A Watt meter at the UPS input will include conversion losses, so it will not exactly match the UPS’s output reading. That is fine. I am looking for a believable range and a load that is comfortably below the unit’s continuous watt rating.
If the UPS reports a very small load, I do not assume the battery will last forever. Batteries age, runtime estimates change with load, and a NAS can draw more during disk spin-up than it does at idle. The test should use the real equipment, not an empty UPS.
Confirm the USB and NUT path
Next I verify the software path. The UPS should show an on-battery state when its input is removed, and the host should record the event. On a NUT setup, I check that the server can read the UPS name, battery charge, load, runtime, and status. I then confirm that clients can reach the NUT server over the network.
The important test is not whether the dashboard has a green USB icon. It is whether the event travels all the way to the action. A client that can read status but has a wrong shutdown policy is still unsafe. I check the low-battery threshold, minimum runtime rule, and shutdown delay. I make sure the server will not power off for a one-second flicker, but also will not wait until the battery is already empty.
I use a notification path that is independent enough to be useful. A phone alert is good, but I also keep a local log because a push service may be unavailable during an internet outage. The message should identify the UPS, the battery percentage, the estimated runtime, and the action being taken.
For multiple machines, I test the order. The NAS may need to stop services before the host powers down. A virtualization host may need to shut down guests before itself. The router and switch should remain alive long enough for the clients to receive their commands. A single USB cable can coordinate the sequence, but only if the dependencies are intentional.
Run the controlled battery test
I schedule the real battery test when I am home, the NAS is not doing a scrub or backup, and I have a second way to reach the equipment. I start with a fully charged battery and close anything that could create an unusual load. I do not test during a thunderstorm or when the house is unattended.
I unplug the UPS input from the wall. I do not pull power from the equipment and I do not switch the load to a surge-only outlet. The UPS should continue powering the battery-backed outlets. I record the start time, charge, runtime estimate, load, and the exact time the software changes to on-battery.
For the first test after installation, I run long enough to prove that the load is stable and the shutdown event is delivered. I stop well before the configured low-battery threshold. There is no prize for draining a sealed lead-acid battery to zero in the name of a more precise number. The safe result is a clean event, a believable decline, and enough reserve to shut down.
During the test I watch for buzzing, repeated transfer events, sudden runtime collapse, overheating, or a load that resets. Any of those is a stop condition. I reconnect the UPS to the wall, wait for line power to return, and confirm that charging begins normally.
Prove graceful shutdown without gambling the data
The cleanest test of shutdown is a planned maintenance event with the UPS still above its low-battery threshold. I temporarily use the platform’s test controls or a documented short outage policy, then confirm that the NAS stops services, flushes writes, and powers down. I do not simulate a complete battery drain just to prove that the command exists.
I check the logs afterward. I want to see an on-battery event, the warning notification, the shutdown decision, and a clean operating-system halt. If the NAS says it lost power unexpectedly, the test failed even if the machine booted afterward.
On a networked NUT setup, I verify each client separately. One client may have an old hostname, a blocked port, or a local policy that overrides the server. Test the client that owns the most important data first, then the less critical machines. Keep the test window short and make sure the UPS has recovered charge before testing the next group.
Automatic restart is a separate behavior. Some NAS units can power on when utility power returns, while others require a button press or a BIOS setting. I document what mine does instead of assuming that shutdown and restart are one feature. A graceful shutdown that leaves a remote server off for days is still an operational problem.
Add monitoring in Home Assistant
Home Assistant makes the UPS easier to remember. The native NUT integration can expose battery percentage, load, runtime, input status, and an on-battery binary sensor. I put those entities on a small reliability dashboard rather than hiding them inside a general energy view.
My useful alerts are simple. Notify when the UPS goes on battery, notify again if it remains on battery for several minutes, and alert when the battery falls below the shutdown reserve. I also notify when the battery has not returned to a high charge after a reasonable recovery period. A battery that never fully charges may be more important than a single short outage.
I do not make every sensor a high-priority alarm. A brief transfer event can be logged without waking the house. The alert should tell me whether I need to investigate now, shut down manually, or simply check the event later. Too many false alarms train people to ignore the one that matters.
Know when to replace the battery
Lead-acid UPS batteries are consumables. A self-test can pass while runtime has become too short for the shutdown policy. I look for a steep drop in estimated runtime, a battery that never reaches full charge, swelling, heat, corrosion, or a unit that repeatedly reports a fault. Physical damage is a replace-now condition, not a wait-and-see condition.
I buy the replacement by exact UPS model and battery specification, not just by voltage. A UPS replacement battery that fits the compartment may still have the wrong connector, capacity, or discharge behavior. I compare the manufacturer’s part number and dimensions, then dispose of the old battery through a proper recycling channel.
After replacement, I reset the battery date or calibration only according to the UPS documentation. I let it charge fully, run the self-test, and repeat the controlled battery test. The first test after replacement is when I discover whether the replacement is actually compatible, so I do not put it off for another year.
A test record that takes two minutes
My test note has eight fields: date, UPS model, battery age, load watts, battery percentage at start, runtime at stop, shutdown event received, and follow-up action. I add a sentence about anything unusual. This is enough to spot a battery that is degrading gradually and enough to reconstruct what happened after an outage.
I keep the note with the home lab documentation and link it from the Home Assistant dashboard. When I change the NAS, add a server, or move the network switch, I update the load and repeat the test. UPS reliability is not a permanent property. It depends on the battery, the load, the software, and the wiring still being the same system I tested.
The Bottom Line
A UPS is trustworthy only after it has passed a controlled test with the real load. Check the outlet map, run the built-in self-test, verify the USB and NUT path, unplug the UPS input while you are present, and confirm that the software sees the event. Stop before the low-battery threshold and inspect the logs afterward.
Test twice a year and after every battery or load change. Monitor it in Home Assistant, replace batteries based on evidence rather than the display alone, and keep a short record. The point is not to run a home server through a long outage. The point is to turn a power failure into a clean, documented shutdown instead of a surprise data-recovery exercise.