A Z-Wave network heal rebuilds your controller’s routing table by asking every device on the network to find its neighbors again and report back. It is not maintenance you run on a schedule. It is a specific fix for a specific problem: nodes that cannot see each other because the map the controller is using is out of date.
Why a new node is invisible until something heals the network
When you add the very first device to a Z-Wave network, the controller knows about it and it knows about the controller. That is the whole map. Add a second device, and the controller now knows about both, but the first device still only knows about the controller. It has no idea the second device exists, and the second device has no idea the first one does either, unless something tells them.
That something is a heal. It instructs every node to scan for other nodes within direct radio range and report what it finds back to the controller, which uses those reports to rebuild the routing table for the whole network. Until that happens, devices route messages using whatever map they last had, which may not include a device you added an hour ago.
This is also why adding several devices in one session and then never healing can leave a network that technically works, but only because messages happen to be reaching their destination through routes the controller assumes are still valid. Add a wall, move a piece of furniture, or lose one intermediate device, and a route that was never verified can fail with no obvious cause.
What a heal costs while it runs
This is the part most pages skip, and it is the reason “just heal it whenever” is bad advice.
A heal uses the network’s Z-Wave bandwidth for its own traffic while it runs, competing with the actual commands you’re trying to send devices: a light switch responding slowly mid-heal is not a coincidence. Depending on how many nodes are on the network, a full heal can take anywhere from a few minutes to a couple of hours, according to Hubitat’s own documentation on the process.
The cost that catches people off guard is battery drain. Every node gets woken and asked to respond, including battery-powered devices like door locks and sensors that normally sleep to save power. A heal that wakes a lock unnecessarily is a small, real cost against that lock’s battery life, repeated every time you run one.
None of this means a heal is dangerous. It means it is not free, and running it as a daily or weekly habit “just in case” spends battery life and bandwidth solving a problem that, most of the time, does not exist yet.
When it is worth running, and when it is not
The pattern that shows up across independent Z-Wave documentation and community troubleshooting threads is consistent: heal after a change to the physical network, not on a timer.
Worth running:
- After adding a new node, so existing devices learn it exists
- After removing a device, so nothing keeps trying to route through a node that is gone
- After moving the controller or a repeating device to a different room
- When a specific device has become unreliable and you suspect its route is stale
Not worth running:
- On a recurring schedule when nothing has changed
- As a first troubleshooting step before checking the obvious things (is the device actually powered, is it in range at all)
- Repeatedly in a short window, since a heal that already ran does not need to run again until the network changes further
If your network has been stable and nothing has been added, moved, or removed, a scheduled heal is solving a problem you don’t have at the cost of battery life you do.
Heal vs exclusion vs reset: three different buttons in the same app
It’s worth being precise about what a heal is not, because the three sit next to each other in most controller apps and get confused.
A heal does not remove or add anything. It only rebuilds the routing map for devices that are already part of the network.
Exclusion is a different operation entirely: it removes a device from the network so it can be added to a different one. Z-Wave exclusion when you no longer have the original controller covers that process, including what to do when the controller that originally paired the device is gone.
A factory reset on the device itself is more drastic still: it clears the device’s own memory of any network, independent of what the controller thinks. That is a device-side action, not a network-side one, and it does not appear on the controller’s heal or exclusion menu at all.
If your actual problem is a device that has dropped off the network entirely rather than one that’s slow or unreliable, work through the device, radio, router or cloud test before reaching for a heal. A heal only helps if the device is still part of the network and just poorly routed.
The wider version of that question, for a smart device that used to work and now doesn’t, is covered in why a smart device that was working starts dropping off.
FAQ
Do I need to heal after every single device change?
It’s the safer habit, but a heal after a batch of changes (adding three devices in one afternoon, for instance) is reasonable rather than healing after each individual one.
Will a heal fix a device that’s completely offline?
Not by itself. A heal rebuilds routes for devices the controller can already see. A device that isn’t responding at all is a different problem: check whether it’s powered and in range before assuming a routing issue.
How do I know if a heal is running or finished?
Most controller apps show a progress indicator or a completion notification. If yours doesn’t say clearly, avoid making other network changes until you’re confident enough time has passed for the process to complete, since interrupting one partway through can leave routes in an inconsistent state.
Does a heal affect Zigbee devices too?
No. A Z-Wave heal only touches Z-Wave nodes. Zigbee has its own, separate mesh-repair behavior.
Can healing make things worse?
It’s unlikely to break a working route, but the bandwidth and battery cost during the process are real, which is the actual argument for running it only when something has changed rather than routinely.
Sources referenced in this article
- Hubitat Documentation, Anatomy of a Z-Wave Repair.
https://docs2.hubitat.com/en/how-to/anatomy-of-zwave-repair(accessed 2026-08-06). Source of the routing-table rebuild mechanism, bandwidth usage during a repair, and the battery-device wake behavior. - DrZWave, Seven Habits of Highly Effective Z-Wave Networks for Consumers.
https://drzwave.blog/2017/01/20/seven-habits-of-highly-effective-z-wave-networks-for-consumers/(accessed 2026-08-06). Source of the guidance on when a heal is and is not worth running.
Review interval: 12 months (controller app behavior and terminology can shift).