How do I tell whether my UniFi AP is stuck provisioning or actually rebooting?

Watch the device Uptime counter in the controller. Provisioning pushes new configuration without restarting the access point, so the uptime keeps counting through a provisioning event. If the uptime resets to zero at each episode, the device is actually rebooting — a different disease, usually power (the controller's Power log events include 'AP Underpowered' and 'Insufficient PoE Output'). A third look-alike is the Isolated state, where the AP cannot reach its controller at all. Ubiquiti publishes no definition of the Provisioning state nor a time threshold for 'stuck'; the practical test is repetition without anyone making a change.

What causes a UniFi provisioning loop?

Provisioning is the controller pushing configuration to the device, so a loop means something keeps generating a push the device cannot settle. Documented anchors include: a configuration the device cannot commit — Ubiquiti's own config.gateway.json article uses the exact phrase 'provisioning loop' for invalid JSON producing commit errors; controller-side changes being made repeatedly, which the System Log's Admin Activity records as 'Admin Made Config Changes' (an automation or a second administrator can be the author); a controller application update, which Ubiquiti's release notes warn may cause adopted devices to reprovision, sometimes with minimum device-firmware requirements; and exceeding the per-band SSID limit (4 SSIDs per band, 8 with meshing disabled). Channel AI is a cleared suspect: Ubiquiti documents it as a manual tool applied non-disruptively.

What is the fix order for a provisioning loop?

First prove the disease with the Uptime counter. Then align the loop's episode times with the Admin Activity log to find the triggering change, and revert exactly that one change — single-change discipline from then on, so cause and effect stay readable. Confirm the controller and device firmware form a supported pair (release notes publish minimum device firmware for controller versions). Check the SSID count against the per-band limit. Only as the last resort use Forget and re-adopt. If the loop persists on a clean supported pair with no triggering change, generate a support file: in the well-known community case, that is precisely what Ubiquiti staff requested, and no root cause was ever published.

UniFi · Provisioning · Fix

UniFi AP stuck “Provisioning” — in a loop, dropping everyone each time

First published 20 October 2026 · An honesty note up front: Ubiquiti publishes no definition of the Provisioning state and no official trigger list. This guide is built from the anchored fragments that do exist — Ubiquiti's release-note language, its one article that uses the exact phrase “provisioning loop,” and its System Log taxonomy — with each claim's tier marked.

Do not fix the wrong thing first. Three different failures wear the Provisioning costume, and their cures don't overlap. Prove which one you have with the Uptime counter before changing a single setting: provisioning does not restart the AP (uptime keeps counting); a reboot resets it; an Isolated AP isn't talking to the controller at all (its LED flashes blue off every ~5 seconds, per Ubiquiti's LED table).

Look-alike	Uptime counter	Logs say	Disease
Provisioning loop	Keeps counting	“Admin Made Config Changes” near each episode	Something keeps pushing config that can't settle → this guide
Actual reboots	Resets each episode	Power events: “AP Underpowered” / “Insufficient PoE Output”	Power — our power discipline, not this page
Isolated	— (not reporting)	“Device Offline”	Uplink/controller reachability → adoption guide
Upgrading	Resets once	A firmware event, once	Not a disease — leave it alone for its few minutes

What provisioning is, and what legitimately triggers it

Provisioning is the controller pushing the device's configuration. Single provisions are normal and invisible. The documented trigger anchors:

Saved configuration changes — the definitional core. Every edit you (or anyone) save is a push.
Controller application updates — Ubiquiti's own release notes carry the standing line that Network updates “may cause your adopted devices to reprovision,” and publish minimum device-firmware requirements per release. An unsupported controller↔device pairing is a loop with a paper trail.
Force provision — a deliberate manual action exists (its path in the current UI is release-dependent).
config.gateway.json merging at every provision — on gateway devices with a custom JSON file, every provision re-applies it. This article is also the one place Ubiquiti uses your exact words: invalid JSON produces a commit error and a “provisioning loop.” (Legacy, USG-era documentation — flagged as such; the mechanism, a config that cannot commit, is the general lesson.)
Cleared suspect: Channel AI does not change your Wi-Fi at night — Ubiquiti documents it as a manual tool, applied non-disruptively. Stop blaming it and read the log instead.

The repair ladder

Rung 1 — Find the author. Open System Log → Admin Activity and line the “Admin Made Config Changes” timestamps up against your loop episodes. A match names the trigger: you, a second admin, a managed-service tool, or an automation with write access. Loops with an author end when the author stops.
Rung 2 — Revert exactly that change. One revert, then watch. Single-change discipline is not fussiness; it's how the next episode (or its absence) stays readable.
Rung 3 — One controller, current and singular. A controller that restarts (or two controllers taking turns managing the same devices) re-pushes on every reunion. Run one controller, as a stable service, on a supported version.
Rung 4 — Check the version pair. Compare your controller version's release notes for its minimum device firmware against what the AP runs; bring the lagging side up. (Do not chase specific “miracle firmware” folklore: in the famous community loop case, Ubiquiti staff requested a support file and never published a root cause or a fixing version.)
Rung 5 — Count SSIDs. The documented ceiling is 4 SSIDs per band (8 with meshing disabled). Creeping past it via years of “just one more network” is a real, countable cause — consolidate WLANs.
Rung 6 — Gateway readers: audit config.gateway.json. If it exists, validate it (a JSON syntax error is the documented commit-error trigger); rename it aside and watch the loop die — or not.
Rung 7 — Forget + re-adopt. The official last resort from the adoption flow. Note what it costs (device-level overrides) and that if the cause lives in the controller's config, the loop will politely resume on the fresh adoption.
Terminal rung — the support file. Loop persists on a clean, supported, single-controller setup with no triggering change in the log? Generate the support file and open the case. That is not surrender; it is literally where Ubiquiti's own staff start.

What this guide will NOT tell you

That mesh nodes re-provision whenever their uplink changes — a claim repeated everywhere, which our research could not find in Ubiquiti's meshing documentation (re-read in full for this guide). Uplink flapping is a fine hypothesis to test with your own logs; it is not a documented mechanism, and it is labelled community-attested wherever it appears. Likewise “wait N minutes before calling it stuck”: no such threshold exists — the test is repetition without a change, not a stopwatch.

Prevention

Habit	Why
Stage changes on one AP group first	A canary catches a can't-commit config before it loops the fleet
One change, one observation window	The log stays legible; so does your memory at 2 a.m.
Keep the controller↔firmware pair supported	Release notes publish the floors; read them before updating the controller
Audit who/what can write config	Admin accounts, API keys, automations — the loop's author is on that list
Back up before change windows	A revert you can actually perform beats a revert you can describe

FAQ

Provisioning drops my clients every time — is that normal?

A reprovision restarts the AP's radios in effect if not the device itself; brief client disruption during a provision is the known behaviour, which is exactly why a loop is intolerable and a single provision is not.

It only loops at night.

Then something scheduled is writing — the Admin Activity log keeps the author's name and time. “Night” is a clue about automation, not about RF.

Should I downgrade the AP firmware to the version forums swear by?

No documented basis exists for any specific “fix version,” and downgrading below the controller's published minimum manufactures the version-pair cause. Supported pair first; support file after.

Sources

Ubiquiti Help Center — System Log taxonomy (Admin Activity / Devices / Power event names), device LED reference, SSID limits (4/band, 8 meshing-off), Channel AI documentation (manual, non-disruptive) · Ubiquiti release notes — reprovision language + per-release minimum device firmware · Ubiquiti — config.gateway.json article (commit error / “provisioning loop”; legacy, via mirror — flagged) · Legacy Controller User Guide (Uptime field definition; flagged).

Verification note: log taxonomy, LED pattern, SSID limits and the cleared-suspect finding were confirmed from Ubiquiti's documentation on 20 October 2026. No official Provisioning-state definition or trigger list exists; where this guide synthesises, it says so, and the mesh-uplink claim is labelled community-attested throughout.

Did this fix work for you?

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