Hub & Bridge Problems

Hubitat “No Connection” Error: Local-First Hub Diagnostics

When Hubitat shows a no connection error, the problem is local in three out of four cases. Walk through these checks before assuming the cloud or hardware failed.

By Aniket Solanki Jul 22, 2026 5 min read
Hubitat “No Connection” Error: Local-First Hub Diagnostics
Difficulty Intermediate
Estimated time 30 minutes
Last tested April 2026
Verified on Zigbee, Z-Wave, Matter

Hubitat’s appeal is its local-first design. Most automations run on the hub itself with no cloud dependency. So when you open the Hubitat web interface and see a no connection error, your instinct is to blame the cloud. In about three quarters of cases, the cloud is fine and the problem is on your local network.

Confirm where the failure is

Hubitat has two distinct ways of failing that both produce a no connection message in the app or browser:

  • The hub itself is unreachable on your local network.
  • The hub is reachable locally but cannot reach Hubitat’s cloud, which the dashboards and remote access rely on.

The first check is to find the hub’s local IP. Open http://findmyhub.hubitat.com in a browser on the same network. This page queries your local network for any Hubitat hub and reports its IP. If it finds the hub, your local network is healthy and the issue is cloud-side. If it does not find the hub, the issue is local.

If findmyhub does not see your hub

This is the more common case. Walk through these in order.

  1. Check the LED on the front of the hub. Solid green means everything is healthy and the hub is running. Slow blink green means booting. Solid blue means waiting for Wi-Fi (only on hubs with Wi-Fi). Red means hardware fault. Off means power issue.
  2. If the LED is green, check your router’s DHCP client list. The hub should appear with a hostname starting with Hubitat. If it does not, the hub did not get an IP. Try a different ethernet cable and port.
  3. If the hub has an IP but findmyhub does not see it, your router has client isolation enabled. This blocks local discovery. Disable client isolation or guest mode on the SSID the hub uses.
  4. If you find the hub’s IP, open http://<hub-ip> directly. If the web interface loads, your problem was discovery, not the hub itself. Set a static DHCP lease for the hub so its IP does not change.

If the hub is reachable locally but cloud features are broken

Hubitat’s cloud is used for the mobile app’s remote access, cloud dashboards, and the Maker API endpoint. If those are broken but the hub responds on its local IP, the issue is between the hub and Hubitat’s cloud.

First, check Hubitat’s status page. If they are showing a cloud incident, you have to wait. If they are not, the hub itself is failing to reach the cloud, usually because:

  • The hub cannot resolve DNS. Try setting custom DNS in the hub’s Network Settings to 1.1.1.1 or 8.8.8.8.
  • The hub is on an isolated VLAN that blocks outbound HTTPS. Hubitat needs port 443 open to cloud.hubitat.com.
  • The hub’s cloud token has expired after a long offline period. The fix is to log into the hub locally and re-link it to your Hubitat account through Settings, Hub Details, Re-register.

The fix for the most common case

The single most common cause of a Hubitat no connection error is a router that changed the hub’s IP address after a reboot. Hubitat caches the IP locally and the app caches it too. When the IP changes, the cached value points to whatever new device picked up that IP, which is usually not the hub.

The permanent fix is a DHCP reservation. In your router’s admin interface, find the hub’s MAC address (printed on the bottom of the hub) and assign it a permanent IP. Pick something memorable like 192.168.1.50. Reboot the hub once after setting the reservation. From now on, the hub will always have the same IP regardless of router or power events, and the app will find it consistently.

Recovering from a corrupted database

If the hub LED is red, or if the LED is green but the web interface is unresponsive after the IP is correct, you may have a corrupted database. Hubitat has a built-in recovery mode that runs at http://<hub-ip>:8081/ instead of the normal port. From recovery mode you can:

  • Reboot the hub (use this first)
  • Restore from a database backup (Hubitat takes nightly backups automatically)
  • Run a database integrity check
  • Soft reset, which clears settings but not device pairings
  • Full reset, which clears everything including device pairings

If you have to restore from backup, the most recent backup before the failure is usually the best choice. If your latest backup also shows corruption, work backward day by day until you find one that restores cleanly. Hubitat keeps about a week of automatic backups.

What to do if recovery mode also fails

If you cannot reach recovery mode (port 8081 also does not respond) and the LED is red, the hub has a hardware fault. Hubitat’s RMA process is straightforward but takes a couple of weeks. In the meantime, you can spin up a temporary HE backup on a Raspberry Pi using the unofficial community tools, restore your backup to it, and keep running until the replacement arrives. This is not officially supported, but it works for the most common automations.

Avoiding this in the future

Set a DHCP reservation the day you set up your hub. Enable automatic cloud backups in Hub Settings. Check the LED color every few months as a habit, especially after firmware updates. The number of users who have lost weeks of automation work to a corrupted database that they had no backup of is unfortunately not small.

The static-IP habit pays off here

Half the no-connection errors disappear once a Hubitat hub has a DHCP reservation. The app caches the hub’s last known IP and silently fails when the IP drifts after a router reboot. Setting the reservation once at install time prevents the most common version of this error for the life of the hub.

While you are in the router admin, set reservations for any other critical smart home gear too: your primary HomeKit hub, your Zigbee coordinator, your security camera bridge. The pattern of cache-vs-reality drift behind no-connection errors is the same one we cover in our device status cache guide for app-side state issues.

Related reading: conditional automation guide.

Works with
ZigbeeZ-WaveMatter

Frequently asked questions

Will a DHCP reservation break anything?

No. It just tells the router to always assign the same IP to that specific MAC address. Other devices on the network are unaffected.

Why does the LED go solid red briefly during normal boot?

Hubitat boots through multiple stages, and brief red during stage transition is normal. Sustained solid red for more than thirty seconds is a fault.

Can I run two Hubitat hubs on the same network?

Yes, and many users do for redundancy or for separating critical safety automations from convenience ones. They will not interfere with each other.

Does Hubitat work entirely without internet?

Local automations, scenes, and direct Z-Wave or Zigbee control all work without internet. You lose dashboards (cloud-rendered), the mobile app's remote features, and any cloud integrations like IFTTT.

How long do automatic backups go back?

Hubitat keeps the seven most recent automatic backups. You can also create manual backups, which are kept until you delete them.

Is the Maker API affected by cloud outages?

Local Maker API endpoints work without the cloud. Cloud-relay Maker API endpoints require the cloud and will fail during incidents.

More from this category