A Smart-UPS self-test runs on battery for about ten seconds every two weeks

Ten seconds of battery time proves two components work. The transfer relay closes and the inverter comes up ^[4]. Keep the test enabled; it is free. A shutdown consumes capacity, and ten seconds of battery time measures none of it. Charge is a percentage and capacity is minutes, and the front panel shows the percentage ^[7]. The dev.to write-up's argument is that a battery which has lost most of its useful capacity holds ten seconds without complaint, and holds two minutes for a while after that ^[5]. On that reading, the automatic test only begins to fail after the unit has already spent weeks running on a battery that would not have finished a shutdown ^[6].

Put the schedule on a calendar. Schneider's Smart-UPS documentation gives a self-test at power-on and every two weeks after, approximately ten seconds on battery each time ^[1]. That is 26 tests a year, 260 seconds, about four and a third minutes of measured battery time in twelve months ^[16]. The Back-UPS clock is seven days for the same ten seconds ^[2], so 52 tests and roughly eight and a half minutes ^[17]. Schneider frames the Back-UPS replace-battery alarm against a standard two-minute runtime limit ^[3]; one ten-second test is about 8 percent of that figure ^[18].

The test that covers the rest is a cord pull. Connect the load the unit actually protects, pull the input cord, watch the load at the moment of transfer, and time how long the battery holds before your configured shutdown fires ^[9]. That exercises the transfer, the inverter, the battery under its real load, and the shutdown chain, in the order they will happen for real ^[9]. A spec-sheet runtime figure skips your gear: forty minutes there is modelled, and forty minutes on your stopwatch is measured ^[15].

If pulling a cord on live equipment is not on, NUT will start a deep battery test on hardware that exposes one: `upscmd -u <user> <upsname> test.battery.start.deep` ^[10]. The quick, deep and stop variants are standard instant commands, and `upscmd -l <upsname>` lists what your specific unit supports ^[10]. You need that listing command because your firmware may implement less than the protocol calls standard.

There is a second reason to force a transfer while you are standing next to the rack. The unit sits in series with everything it protects, and it can fail in a way that takes the load down with it ^[11]. CyberPower describes how one version of that happens. Its PFC Sinewave page says a simulated sine wave produces a zero-output state during the phase change, a gap in the waveform, and that this gap can interrupt equipment running an active-PFC power supply when the unit switches from mains to battery ^[12]. The same page dates the move to active PFC in PC and server supplies to the last fifteen years ^[13]. That gap arrives at the transfer, the one event the box was bought to handle ^[12].

A cord pull costs a scheduled outage and no hardware. A network management card is a separate accessory purchased on top of the unit ^[14].

The write-up does not give a failure rate for simulated-sine transfers into active-PFC supplies, so treat CyberPower's description as a mechanism to design against and not as a measured probability. In my view the ten-second self-test still belongs on the schedule, because a relay that has welded itself shut is worth knowing about within a fortnight. Get the number for your runbook from the cord pull.