Power failure IT checklist: the UPS, the shutdown, and the cold-start order

Power blips are the incident category every small team assumes is someone else's problem — until the Tuesday the lights flicker twice, the NAS dies mid-write, and the file that "saved" last night turns out to be the backup that never finished. A ten-person office does not need a generator. It needs a UPS on every critical device, an auto-shutdown script that has actually fired once, and a laminated cold-start card that says which box powers on first. This page is that checklist, in the order you should build it.

1. The UPS audit: every critical device, a number, a date

• Walk the room and assign every device a tier. Tier 1 is "dirty shutdown costs us data or hours" — NAS, file server, the router and modem that connect the office to the outside world, the one desktop that runs the payroll or the point-of-sale. Tier 2 is "annoying but recoverable" — workstations, the printer. Every Tier 1 device gets a UPS sized to run it for long enough to shut down cleanly, which for most small-office NAS boxes is ten to twenty minutes, not two hours. The asset inventory is where the tiers live once you've assigned them.
• Write the runtime number down, don't guess it. A UPS's printed "half load: 30 minutes" is a sales number measured with nothing else plugged in. The number that matters is your load: the NAS plus the switch plus the router, measured once with the UPS's own software or a cheap power meter. Write it on the UPS in marker: "runtime 14 min at actual load, tested 2026-03." An untested runtime estimate is a rumor with a battery attached.
• Batteries expire on a clock, and the clock is not yours. Small-office UPS batteries die at three to four years regardless of use, and they die silently — the unit shows a green light while holding ten minutes of charge instead of an hour. Put the install date on the unit and a battery-replacement reminder in the calendar next to the certificate expiry sweep, because both fail the same way: fine until the morning they aren't. Most units run a built-in self-test; run it quarterly and log the result.
• The router and modem get their own small UPS, deliberately separate. This is the cheapest high-leverage move in the whole page: when the power is out and everything else is dark, the office internet staying up for an hour means you can take the incident call, join the bridge, and check status pages from a laptop on battery. One $40 unit under the desk. If the vendor's own status page is how you'll find out the outage is theirs and not yours, keep that path alive — it is the same logic as the vendor outage runbook.

2. Auto-shutdown: configured, cabled, and fired once

• A UPS without a USB cable is a battery, not a system. The whole point of the unit is the grace period, and the grace period only converts to safety if the NAS or server knows the power died. Connect the USB or network cable, install the vendor's agent or nut/apcupsd, and set the policy: "on battery for 60 seconds or below 40% charge → begin graceful shutdown." Sixty seconds filters out the two-second blips that used to page nobody and now page everybody.
• Decide what shuts down and what stays up, and write it in the config. Not everything should power off: the router and modem on their little UPS stay up precisely so you can see what's happening; the NAS and the file server shut down gracefully; workstations are human decisions. The one-liner in the shutdown policy is the same discipline as the maintenance window policy — scope written down before the event, not improvised during it.
• Test the script like you test backups: by firing it. A shutdown script that has never run is a hypothesis. During a scheduled window (a thirty-second unplug of the UPS's input cord does it), verify the agent saw the event, the shutdown began, the NAS came back clean, and nothing downstream choked on the sudden absence. The drill schedule is where this slot lives — once a quarter, fifteen minutes.
• Mind the mail and the alert path. The UPS agent can email or webhook you when it goes on battery — wire that to the same channel the rest of your alerts use, so a power event at 2 a.m. surfaces with the same one-glance triage as everything else. Alert fatigue is managed the same way as everywhere else in the estate: a power blip is informational; a power blip plus "shutdown initiated" is actionable. The cron and job monitoring checklist covers the same "did the thing that should have happened, happen" question.

3. The cold-start order: one page, taped to the wall

• Power-on order is a dependency graph, not a scrum. Modem and router first, wait for sync lights; switch second; NAS and servers third, and let them finish their boot checks before the layer that mounts shares comes up; workstations and printers last. Booting the order wrong doesn't usually break things permanently — it breaks them confusingly, and confusing is expensive at 8:05 a.m. when four people are standing behind you. The card converts the graph into six numbered lines anyone can follow.
• The card names the "wait" signals, not just the steps. "Router: all status lights solid, about 2 minutes." "NAS: status beep stops, then web UI answers at its known address — then start the app server." A step without a done-signal is a step people skip. This is the same spec discipline as the runbook template: one line per step, observable, no tribal knowledge required.
• Include the "do NOT power up" line. After a sustained outage or a storm with visible surges, some devices should wait: the UPS that logged a battery fault, the machine that smells warm, the wall outlet the electrician hasn't looked at. One line on the card — "if anything smells hot or logs a battery fault, stop and call the electrician, not the vendor" — prevents the heroic second failure. The lost laptop runbook taught the same lesson for people: the incident response is defined before the incident.
• Laminate it, photograph it, and put it in the shared drive. The card that lives in the drawer behind the NAS is a card that isn't there when the drawer is the thing that's dark. One copy taped to the rack, one photo in the team channel's pinned messages, one PDF in the shared drive next to the first-week runbook so the next admin inherits it in week one.

4. After dirty power: the data-integrity sweep

• Read the UPS event log before you trust the room. The log tells you what actually happened: one sag, or six sags over four hours, or a full outage your "clean shutdown" politely declined to perform because the agent had crashed in June. The event log line goes into your incident notes verbatim — it is the difference between "power flickered" and "power sagged 4× between 14:02 and 14:31, battery fault on unit 2."
• Check the disks, not just the services. Dirty power shows up as SMART errors, RAID resync flags, and filesystem messages days later. Run the vendor's health check or a short SMART self-test on every Tier 1 disk the same day, and eyeball the RAID status page. A volume that mounts and reads is not a volume that's healthy; the server monitoring checklist is what turns "seems fine" into numbers.
• Distrust any backup that was mid-flight when the lights went. A backup job killed at 60% is worse than none if you restore from it without checking: partial archives, unverified files, a chain with a broken link. Find the jobs whose window overlaps the outage, run a verification pass on each, and re-run the ones that died. The restore-you-can-prove habit from the first-week runbook applies doubly after dirty power; the encryption and escrow habits in the backup encryption checklist and backup key escrow pages assume the backup is intact — this sweep is how you know it still is.
• Watch for the brownout's delayed invoice. Undervoltage events damage power supplies and disk electronics in ways that surface as "random" reboots a week later. If a machine starts misbehaving after a sag event, put the power event in its ticket history — the pattern is only visible when someone connects week-two weirdness to week-one flicker. One-line log, same discipline as every other change and incident.

5. The quarterly test and the evidence it produces

• One thirty-second unplug drill, quarterly, in a window. Pull the UPS input cord for thirty seconds during a declared window, watch the agent fire, watch the shutdown policy decide (or deliberately not decide), plug back in, verify clean boot, log two lines. Fifteen minutes per quarter is the entire cost of never finding out during a real blackout that the agent crashed in June. The freeze policy tells you which quarters the drill must move — never test into a freeze.
• The log line is the deliverable. "Q3 power drill: 30s unplug, NAS agent fired at 8s, shutdown began, clean reboot, battery OK, runtime 14 min." That line, multiplied by four quarters, is what "we take continuity seriously" looks like as evidence on the cyber insurance questionnaire, the customer security questionnaire, and the annual review — all three ask about business continuity, and none of them accept "we have UPSes" as an answer. They accept "we test them quarterly; here are the logs."
• Combine the drill with the battery test and the runtime re-measure. Same window: UPS self-test, battery date check, runtime re-estimate at actual load, USB cable seated. One window, five checks, one log line. Every individual check is trivial; the compound habit is what fails silently when they're separated.
• Escalate the findings, not the anxiety. The drill will find things: a battery two years past date, a server someone moved off the UPS "temporarily" in March, an agent that never got installed after the NAS firmware update. Each finding gets an owner and a date, the same treatment findings get in the access review — because a finding without an owner is a finding you'll re-read next quarter, unchanged.

Small-team honesty note: you do not need a generator, a transfer switch, or a fuel contract — those are for the warehouse with a 24-hour SLA. What a ten-person office needs is four Tier 1 devices on UPS, a shutdown script that has fired once on purpose, a cold-start card on the wall, and a quarterly unplug drill logged in one line. The trap this page exists to prevent is green-light complacency: three years of green lights on a battery that died in year two, and an auto-shutdown script that has been "configured" since 2024 and has never once actually run. Green lights are not evidence. The unplug drill is.the generator transfer checklist covers the hour-long-and-longer outages, where the machine that must carry the shop is a standby generator — and the monthly test that proves it transfers;

Related: vendor contract checklist · DNS outage runbook · vendor outage runbook · disk full incident runbook · runbook template · maintenance window policy · change freeze policy · incident drill schedule · server monitoring checklist · cron job monitoring · certificate expiry checklist · backup encryption · backup key escrow · asset inventory · new admin's first week · office Wi-Fi security · annual security review · server room environment monitoringUPS runtime checklist buys the clean shutdown when the power dies first · the cold chain failure checklist covers the stock side — the fridge that warms up while the power is fine.