How long should a UniFi firmware update take before I intervene?

Ubiquiti publishes no duration and no 'too long' threshold for any device class — any minute-count a forum gives you (the common '10 to 15 minutes at the extreme' included) is community invention. Judge by state instead: the LED pattern (Ubiquiti's LED reference distinguishes booting, upgrading, recovery and isolated patterns), whether the device answers at an address, and whether the console sees it. A device sitting in a steady, documented state is working; a device whose state never changes across a long observation, with the console unable to reach it, is a recovery candidate. Intervene by state, never by stopwatch.

How do I recover a UniFi access point with TFTP?

Per Ubiquiti's Recovery Mode documentation: hold the reset button until the LED flashes white-blue-off, putting the AP into TFTP recovery at 192.168.1.20. Set your computer to a static address in the same range (Ubiquiti's example: 192.168.1.25), then send the firmware .bin with a TFTP client in binary mode — Tftpd64 on Windows; on macOS/Linux the documented commands are 'connect 192.168.1.20', 'binary', 'rexmt 1', 'timeout 60', then 'put' the firmware file. The AP reboots automatically when finished — Ubiquiti's instruction is explicit: do not reboot it yourself. Do not rename the file to fwupdate.bin for this procedure; that renaming belongs to a different device's web-server method (Flex Mini / Switch Ultra).

Should I update the controller or the devices first?

Ubiquiti's current update documentation prescribes no universal order — 'controller first' is community doctrine, not an official rule. What is official: controller release notes publish minimum device-firmware requirements and warn that updates may cause devices to reprovision; Ubiquiti's instruction is to have an up-to-date backup before upgrading; and automated backups fire weekly and before each major update. The defensible practice is therefore: backups verified, release notes read for floors, one device updated as a canary, then the fleet — in whichever order respects the published minimums.

UniFi · Firmware recovery · Fix

Firmware update failed — device offline. Recover it the documented way

First published 20 October 2026 · Every procedure below is Ubiquiti's own, from its Recovery Mode, updating and backups documentation — read in full for this guide. Two popular beliefs are corrected on the record: no official update duration exists, and no official update order exists.

Do not fix the wrong thing first. Split the problem before touching hardware: “Update failed” (the device is alive in the controller, the update didn't apply — a retry problem) is a different disease from “device gone” (offline, unreachable, or stuck mid-state — a device-state problem). And if every device went “offline” at once, your suspect is the console's update, not a fleet of innocent devices.

Triage by state (Ubiquiti publishes no stopwatch — states are the clock)

What you observe	Reading	Move
Device online, “update failed”, will retry	Alive; the push failed	The retry ladder below — incl. the documented Cache firmware retry
LED cycling through boot patterns	Still working/booting	Observe; do not unplug mid-write — power loss during the write is the one self-inflicted brick
Device answers at its normal/DHCP address; console shows offline	Management path broken (the inform path — TCP 8080 class), device itself up	Adoption/isolated ladder, not recovery
LED steady in a recovery/isolated documented pattern; nothing answers	Device-state failure	Recovery ladder, your device's class
Whole fleet “offline” after a console update	Console state, not devices	Console recovery (Class A) — and hands off the APs

The retry ladder (device alive)

Reboot the device once (Ubiquiti's gate order starts here: reboot → reset → recovery → RMA).
Retry the update; if it stalls again, use the controller's firmware Cache path (download once to the controller, then push from cache) — the documented remedy when direct downloads are the flaky part.
Check the pair: the controller release notes' minimum device firmware vs the device's current version (see the provisioning guide for the version-pair discipline).
Still failing on a live device → it's now a state problem: recovery ladder.

Recovery Mode — per device class (Ubiquiti's procedures)

Class A — consoles & gateways (UDM family, UCG-Ultra, Express, Dream Router/Wall, UNVR…)

Hold Reset through power-on for ~5 seconds until the recovery state shows.
Cable a computer to Port 1 (Dream Wall: port 18; EFG: port 2) and set it static in 192.168.1.0/24.
Open the recovery UI at http://192.168.1.30 (HTTP, not HTTPS) → Firmware Update → choose the .bin for your exact model → apply, then reboot when it completes.

Class B — access points (TFTP)

Hold Reset until the LED flashes white-blue-off: the AP now waits at 192.168.1.20.
Computer static at e.g. 192.168.1.25, cabled directly.
Send the firmware: Windows — Tftpd64; macOS/Linux terminal TFTP: connect 192.168.1.20 · binary · rexmt 1 · timeout 60 · put <firmware>.bin.
The AP reboots itself. “Do not reboot it yourself.” (Ubiquiti's sentence, not ours.) Then re-adopt if needed.

Class C — Cloud Key Gen2/G2+

Hold reset ~10 s until the LCD shows RECOVERY MODE and an IP (fallback .30). Run Check Filesystem when offered. Know before you start: on Cloud Key, the recovery firmware restore also factory-resets — and if it fails repeatedly, Ubiquiti's own verdict is to replace the storage disk.

Class D — cameras: recovery is a rollback

There is no camera TFTP in Ubiquiti's documentation. The documented recovery: hold reset ≥10 s through a PoE reconnect until the LED flashes 3× — the camera reboots onto its previous firmware. Forward updates afterwards happen through the console — or, exceptionally, a support-supplied .bin in the camera's web UI.

Class E — switches (two methods guides constantly blend)

Most switches: the recovery web UI at 192.168.1.20 after a 5 s reset hold (recovery idles out with an automatic restart after ~10 minutes). Flex Mini / Switch Ultra are different: a built-in web server at 192.168.1.99 serving a file you must rename fwupdate.bin. That rename rule belongs to this method only — it is the true origin of the internet's “always rename the firmware” advice, and it does not apply to AP TFTP or the console recovery UI.

Terminal line (official): a device that cannot be recovered by its class procedure is an RMA case. That is Ubiquiti's ladder end, not a failure of yours. Also unstated by Ubiquiti, so plan for it: whether settings survive Recovery Mode is documented only for Cloud Key (they don't — it resets) — for everything else, have the backup ready to restore and be pleasantly surprised if you don't need it.

Update practice — what's actually official

Belief	On the record
“Update the controller first, always”	Not an official rule. Ubiquiti's update docs prescribe no universal sequence. Official constraints are: per-release minimum device firmware floors, the reprovision warning, and backups-before-upgrading. (When restoring a backup to a new console, the new application must be up to date first — that one is documented, in the migration context.)
“Back up before big updates”	Official — and partially automatic: backups fire weekly and before each major update when enabled. Verify yours exist before relying on them.
“Just SSH the firmware in”	Ubiquiti documents the commands (`upgrade <url>`, `syswrapper.sh upgrade2 &` on APs; `ubnt-systool fwupdate` on consoles) and wraps them: SSH updating is “not an officially supported process… only do this at the request of UI Support.” Both halves or neither.
Canary + window	Practice, labelled: one device first, in a maintenance window, fleet after. No Ubiquiti citation — and none needed; it's your risk policy, not their instruction.

FAQ

It says offline but the Wi-Fi still works.

Data plane alive, management plane lost — the device passes traffic but can't report in. That's an inform/reachability fault (see the adoption ladder), not a brick and not a recovery candidate. Rebooting the console side or repairing the path is the usual resolution; TFTP would be vandalism.

Power died mid-update. Is it bricked?

Not necessarily — many devices resume or sit in a documented state. Triage by the table: if it lands in a recovery pattern, run its class procedure; the procedures exist precisely for interrupted writes.

The update “failed” instantly, three times.

Cache the firmware on the controller and push from cache (the documented branch), then check the version pair's floors. Instant-fail loops are usually a path or pairing problem, not a device problem.

Sources

Ubiquiti Help Center — Recovery Mode (per-class procedures, addresses, TFTP block, camera rollback, Cloud Key filesystem branch), Advanced Updating Techniques (cache flow, SSH commands with their support-only warning), UniFi Updates (failure checklist, reboot→reset→recovery→RMA order), LED reference, Backups and Migration (weekly + pre-update backups, restore preconditions).

Verification note: procedures and parameters were read from Ubiquiti's documentation on 20 October 2026. No official update duration, universal update order, or general “insufficient storage” failure cause exists in the current text — this guide flags all three absences rather than repeating the folklore that fills them.

Did this fix work for you?

Your reaction tells us whether this guide solved the problem it promised to solve.