The UPS shuts nothing down — and that is deliberate

There is a UPS on my Raspberry Pi in Kapfenberg. If the power fails it keeps the Pi, the router and the link to the outside alive for about 67 minutes.

What it does not do: shut the Pi down cleanly before the battery runs out. Every guide recommends exactly that. I switched it on and switched it off again within the hour.

Here is why — and why the reasoning involves a property no UPS puts in its datasheet.

The catch

With shutdown enabled, this happens at five minutes of remaining runtime: the Pi shuts down cleanly. Filesystem closed, everything in order.

And then it stays off.

Because a UPS does not drop its outlets while the battery still has charge. If the power returns while charge remains, the Pi never sees a power-on moment. As far as it is concerned nothing changed at the socket — there was always voltage.

It would only come back when the battery drains completely. Or when somebody drives over and presses the button.

What that means in practice

A 90-minute outage where the power returns after 50:

	with shutdown	without
minute 0–45	running on battery	running on battery
minute 45	shuts down	keeps running
minute 50, power back	stays off	carries on
hour 2 until a visit	dead house	everything normal

In a house you live in that would be annoying. In one you do not live in, it is the difference between “it was dark for a bit” and “nothing has reported since Tuesday and nobody knows why”.

The lesser evil

A filesystem taking a hard loss is by comparison the cheaper case — especially as it has a journal and the system runs on an NVMe SSD, not on an SD card.

That is a trade-off, not a claim. Anyone running their system on an SD card does the maths differently — there a hard loss really is dangerous. Which is exactly why both belong in one decision: storage medium and shutdown strategy.

Verified, not claimed

That the setting really does what I assume is in the service log — the shutdown commands differ:

with shutdown     SHUTDOWNCMD: /usr/bin/shutdownhost
                  WARNING: UPS Shutdown will shutdown the host

without           SHUTDOWNCMD: /run/s6/basedir/bin/halt

halt only stops the service container. The Pi stays up.

That is the difference between “I unticked the box” and “I know what the box does”.

What remains when nothing shuts down

The threshold at five minutes of remaining runtime stays configured, although it no longer triggers anything. It makes the last warning predictable: the battery warning arrives reliably at five minutes rather than at some point.

And the two warning levels are, without orderly shutdown, more important than before, not less. There is no clean ending any more. The last message is all that remains.

Remaining runtime	Message	What for
15 min	“about 15 minutes left, then the Pi goes”	time to decide whether to act
5 min	“almost empty — this is the last message”	a marker in the log, not a call to action

The second is explicitly not a call to action. At five minutes nobody can do anything who is not already in the house. It is a timestamp for afterwards: it was running up to here.

Logbook first, phone second

Both messages write to the logbook first and push to the phone second.

The reason is mundane and still almost always done the other way: the logbook is on disk, the push has to go out. If the network fails along with the power, the push is gone and the logbook entry is there.

Persistent notification and logbook entry therefore stay in every automation — not because the router hangs off the UPS, but because an outage can last longer than 67 minutes of battery. Then everything that was only in flight as a push is lost.

What actually hangs off the UPS

I did not know at first, and I guessed it wrongly.

I had concluded from the load display: 0 to 1 per cent of 520 watts, the Pi draws 5 watts, so only the Pi is on it. The arithmetic was right, the conclusion was not.

Then somebody pulled the plug for 112 seconds:

20:45:37  on battery    charge 100 %   mains gone
20:46:28  on battery    charge  99 %   input 0.0 V   runtime 70 min
20:47:29  on mains      charge  98 %   input 232 V   charging

And the line that mattered: every single query from Vienna said “reachable”. The connection never dropped throughout the outage. Pi, router and the adapter to the outdoor unit all carried on entirely on battery.

The same UPS reported 0 per cent load during the outage — while carrying an estimated 20 watts at that very moment.

What hangs off a UPS is told to you by the plug, not by the load display. A plug-pull takes two minutes and answers the question for good. Any estimate from percentages is tea leaves.

That is why there is no watt sensor here any more. It would have shown zero while half the network depends on it. A reading that reliably shows zero where something exists is worse than none — because next time somebody will believe it.

Why runtime, not charge level

The second error, which almost every UPS dashboard repeats.

A dead lead battery shows 100 per cent. It accepts charge but does not hold it under load. Charge level is therefore the most useless value a UPS provides — and precisely the one everybody displays.

Three others do say something:

• Remaining runtime. It collapses first, long before the charge level says anything.
• Battery voltage. 13.5 volts is healthy; well below that under load means ageing.
• Age. Lead lasts three to five years whether you need it or not. This one is two and a half years old — in about eighteen months the monthly reminder will fire, and that is exactly the intention.

The part that gave me most to think about

The documentation for this package opens with the sentence:

A UPS without monitoring is a device that quietly does its job for years — and then quietly stops.

Two days later the monitoring itself quietly stopped.

While building a dashboard it emerged that every UPS entity had read “unavailable” for 43 hours. The log carried an error message once a second. The system’s device list no longer knew the UPS; the state was exactly the same as before the cable was plugged in.

For two days a power cut would have produced not a single message. None of the five automations can trigger when the entity they hang off is unavailable.

Monitoring that does not notice its own silence monitors nothing.

So there are now two more automations: one reports when the UPS status has been unavailable for two hours, the other clears the message when it returns and states the current values.

Two hours of grace, because every restart briefly sets entities to “unavailable”. And the message is deliberately persistent, not just a push — it should not be swipeable and then forgotten.

What is not tested

The hard failure itself. That would mean letting the battery drain for 67 minutes, and it has not happened yet.

Tested are: the 112-second power cut with the full notification chain, both warning levels triggered individually, and the difference between the shutdown commands in the log. What happens when the Pi really loses power mid-write is still outstanding.

So what?

1. Check whether your UPS ever drops the socket. That decides whether an orderly shutdown protects you or switches your house off until you drive over.
2. Decide storage medium and shutdown strategy together. On an SD card the maths is different from on an SSD.
3. Measure with the plug, not with the display. Two minutes answer the question of what really hangs off the UPS.
4. Show remaining runtime, not charge level. A hundred per cent says nothing about a battery that no longer carries load.
5. Monitor your monitoring. That is the point where I caught myself out, and it applies to every alert chain in the house — not just the UPS.

The real lesson is uncomfortable: the decision against shutting down was right, but it only became a decision at all because somebody asked what happens afterwards. The default setting would have switched the house off, and nobody would have noticed in advance.