Hub Load Increases Progressively Over Extended Uptime (62+ Days)

Get Help
1

I'm running a C8 Pro with firmware 2.4.3.172, and I've observed a persistent issue across multiple firmware versions over the past year.

The Problem

Hub load increases progressively over time, particularly after extended uptime periods. Typically, the pattern is:

  • Days 1-15: CPU usage remains around 5% or lower

  • Days 15-30: CPU usage begins increasing gradually

  • Days 30+: CPU usage continues climbing

Previously, I would update the hub before reaching critical levels (typically around 15% CPU usage at ~30 days). However, this time I decided to monitor the progression without rebooting to try to identify the root cause.

Current status: 62+ days of uptime with "Hub load is elevated" warning as of today.

Current Metrics

Apps and Devices loads are low:

  • Apps: 0.8%

  • Devices: 1.4%

CPU usage is approaching 40% according to the Hub Information Driver, which is significantly elevated despite low application-level activity.

Free memory has declined to approximately 800MB (compared to ~1.5GB at 10 days of uptime), suggesting a potential memory leak.

Analysis

Even accounting for the memory reduction, 800MB of free memory should not cause the observed CPU spike. The JVM would not typically trigger excessive stop-the-world garbage collection at this memory level unless explicitly configured to do so.

Since Apps, Devices, and GC are not showing abnormal activity in the logs, the high CPU usage appears to originate from the hub's core code. However, without thread dumps and heap dumps, it's difficult to pinpoint the exact cause.

System Configuration

For context, my setup includes:

  • Z-Wave antenna: disabled

  • Matter: disabled

  • Zigbee devices: ~100 (85+ are repeaters)

  • Other devices: LAN, Virtual, Parent devices

  • Apps: 6 installed and enabled (no Rule Machine or built-in dashboards)

  • Network: Ethernet connection

  • Logs: No warnings about long-running apps, problematic devices, or excessive debug logging

  • Overall stability: Excellent (apart from the CPU load issue)

Request

To help diagnose this issue, it would be valuable to:

  1. Enable heap dump collection for memory leak analysis

  2. Provide thread dump access for CPU usage investigation

  3. Identify any known memory leaks or CPU-intensive background processes in 2.4.3.172

While rebooting resolves the symptom, it doesn't address the underlying cause. I'd prefer to understand what's happening rather than simply reset the system periodically.

2

I'm thinking that you should update to the latest release and observe your results. There have been a lot of changes since 2.4.3.172.
Memory leaks were extensively chased and resolved.

3

As I said, I've been noticing this problem for over a year now, across multiple firmware versions. During this period I have installed some apps, uninstalled others, added several devices, removed and replaced several others, changed/updated apps and drivers, but mainly, removed everything I didn't actually need, and got rid of problematic software (at least the part I can control) and hardware, always with the focus on getting a very stable system.

A lot of changes, over a long period of time, and still, the one thing that didn't change was the CPU load issue, it was there all this time, and most likely before that too.

If you search for "memory" and "leak" on the 2.4.4,X release notes, you'll find nothing.
About CPU load there is one mention, but it is just about changing how it is reported, nothing related to high CPU load issues.

BTW: With the CPU load at 40%, it is normally VERY easy to spot the problem (or problems) with a few thread dumps.

4

The memory issues were all in the testing phase so you won't be able to search that.
The CPU reporting was also revamped to report, what I assume was, more accuracy.
I would do a full backup and try the latest release and monitor.
You might find things have changed for the better, or not, but at least that won't be an unknown.

5

The hub has rebooted by itself yesterday after ~63 days of uptime.
I'll will now update to the latest version and leave it running until it crashes again (or hopefully not), I'll let you know how it goes.

PS: There are no warnings or error messages on the logs around the time it rebooted, I'm not sure if it is a feature that triggered the reboot or if it really crashed.

6

Yeah, given memory leaks (not saying they are in the hub software or community apps/drivers), on my C8, anything north of 30 days of uptime was surprising - I have a reboot rule, setup for when free memory got below <180K

With my C8P, I've made it to 40 days, but I rebooted due to a version upgrade. - Given the additional memory in the C8P, I would guess 60 days is about an outer limit, but I really do think that's driven by your specific mix of drivers & apps.

I also agree, that limited diagnostic tools that we have, that you really can't see any memory leaks happening at the OS level, or outside of the JVM. - And as system memory and resources are exhausted, then I can believe CPU usage would climb (swapping, GC, etc.) -

I totally agree with your diagnostic tool request, but I don't likely see that happening given the current hub security model - Not to say you can't hack your way in, given enough effort - but even if you find some offending process (ZwaveJS, mDNS (Avahi or Bonjour), Jetty Webserver, DropBear, H2 DB, etc.) leaking resources, I'm not really sure what you could do about it. The hub is running on a older version of Linux 4.9, so that's just a few revs behind current releases.

Bottom line, I think expecting anything more that 90 days of uptime on a C8P without a reboot is wishful thinking - I'm curious if others have extended (months/years) uptimes - And given the frequency of updates/releases, you likely going to get some new release in that time frame, that will likely trigger you to reboot anyways. - And to be fair, IMHO some of this is driven by your hub's driver/app mix - So I'm guess "less stuff" will get you more days of uptime without CPU issues.

That all said, I'm curious to see if your CPU rise over the long term is repeatable, given the latest release, so please update this thread 30-60 days out..

7

A follow-up on this. I updated to 2.4.4.135 (released 2026-02-25) and rebooted on 2026-02-26 10:14. The release notes for that build mention "likely fixed a steady memory leak on C8 Pro hubs", so I started a fresh long-uptime run with frequent samples to see if the trend was gone.

Result, after ~70 days of uptime: the leak is still there — same shape, similar slope. Manually rebooted today (2026-05-07 11:20) because the symptoms were getting in the way of automations.

Hubitat C8 Pro - 2.4.4.135 - memory and CPU vs uptime
Hubitat C8 Pro - 2.4.4.135 - memory and CPU vs uptime2083×1187 286 KB

What the chart shows

  • Free memory falls almost linearly from 1384 MB at boot down to 35 MB at ~62 days uptime. That's roughly −21 MB/day of free RAM, sustained, with no plateau.

  • CPU stays relatively flat (3–10% on the 15-min average) for the first ~60 days, then starts climbing as free memory gets squeezed. Clearly the memory parameters of the JVM were changed in this version.

  • At ~61 days I started noticing the first delays in Zigbee command execution. Same hub, same automations, same routines that were instant at day 5 — now several hundred ms to a couple of seconds.

  • At ~69 days delays became frequent and longer (single Zigbee instructions occasionally taking ~7 s, web UI taking several seconds to load a device page on the first interaction). At that point CPU jumped from its ~6% baseline to 22–27% and free memory bounced back from ~50 MB to ~628 MB — which to me looks like a classic stop-the-world full GC finally running because the heap was exhausted, and continuing to run frequently from that point on (which would explain the persistently high CPU and the visible UI/Zigbee stalls).

Setup (unchanged from the original post)

  • C8 Pro, ethernet
  • ~100 Zigbee devices (~85 repeaters), 6 apps
  • Z-Wave radio disabled, Matter disabled
  • No custom apps/drivers added or changed during the run

My read

The underlying memory behavior on the C8 Pro is still leaking at roughly the same rate I was seeing on 2.4.3.172. The hub eventually self-recovers via aggressive GC, at the cost of sustained high CPU and user-visible Zigbee/UI lag, until something forces a reboot.

I have the raw 70-day dataset (uptime / cpu15Pct / cpuPct / freeMem) if it would help the platform team — happy to share it.

On thread dumps and heap dumps

Earlier in the thread the idea of capturing thread/heap dumps from a long-uptime hub was set aside as not really feasible. I'd like to gently push back on that, because both of these are the diagnostic artifacts for this class of bug, and I think the obstacles are smaller than they look.

Thread dumps are tiny — a few hundred KB even for a busy JVM — and they reveal stuck threads, lock contention, and runaway timers that no metric can show. The privacy / IP concern is solvable with a well-known pattern: a built-in take-thread-dump command that encrypts the output with a Hubitat-owned public key. The user uploads an opaque blob; only the Hubitat platform team can decrypt it. No app source, no tokens, no user state ever leaves the hub in plaintext.

Heap dumps are harder — they're large (likely 1–2 GB on a C8 Pro) and asking an already memory-starved JVM to allocate enough headroom to write and encrypt one may genuinely fail. But "may fail" isn't the same as "will fail", and we won't know unless we try. Two angles that mitigate the risk:

  1. Take the dump before the hub is critical. The leaky objects are already in the heap at day 20 (when free memory is still ~700 MB) — you don't need to wait for day 60 to see the signature. An earlier snapshot is smaller, safer to write, and just as useful for diff'ing against a freshly rebooted heap.

  2. If it aborts on a starved hub, that's also a data point. It tells the platform team exactly which subsystem can't make the allocation, which is itself useful.

A product perspective

I want to be clear this isn't a complaint about the team or the platform — Hubitat is by a wide margin the most reliable home-automation hub I've used, and that's why I keep investing time in writing these reports up. But, speaking as someone who has shipped and operated long-running services for many years: a product that needs to be rebooted every ~60 days to stay responsive is treating a symptom, not a cause. This class of bug is findable. It just needs the right diagnostic data captured from a hub that is actively exhibiting the symptom — which is exactly the hub I'm sitting in front of.

So a concrete offer: if the platform team has a debug build, a dev branch with extra instrumentation, an enable-tracing flag, or a script you'd like me to run on the next long-uptime cycle before I reboot — I'll run it. I have the time, the data is reproducible on my hub, and I'd much rather help find the root cause than reboot every two months indefinitely.

8

Appreciate your detailed data collection and debug offer.. Hopefully, after the V2.5 Beta ends (lots of work on Ring integration and built in graphing), your offer gets some traction with the HE staff. Time will tell.

9

Sort of a contrarian point of view. C8 Pro as my primary hub, a few hundred devices, a mix of ZigBee, z-wave, some local WiFi, Hue and Lutron integrations, many many Community apps. I participate in the beta and update within a day or two of each new release. Hubitat is an active hobby that my wife tolerates. I've been doing this for five or six years and I have never had to recover from a beta update. At this point the C8 Pro free memory seems to stabilize at about 1 GB. YMMV. On my previous C8 I had an auto reboot rule when free memory got to 200K which would occasionally be triggered. The rule is still there but I've not seen free memory below 950k on the C8 Pro.

10

But like you said, hub reboots when new beta is installed. It never gets a chance to get low. My C8Pro on beta hasn't been rebooted since April 9, so almost a month. It is currently sitting at 851272 and dropping daily.

Edit: Forgot to mention it has no devices, no apps, no automations, and no integrations. It is a spare hub.

11

I'm the opposite, hundreds of devices (every protocol possible), rules, integrations. No issues, a meshed C7 with a few bad children. Wish Hubitat had an apps/ device in use summary available.

12

You can currently see if a driver is being used by a device or not. A device or app might not ever be used until it is. How would the hub know?

13

Hmm, I can make a "take a heap snapshot and upload the compressed file" endpoint. But it would have to be enabled on case-by-case, one hub at a time basis. The impact of running the endpoint for the hub is non-trivial, it will slow things down dramatically.

Having a heap from an actual slowed down hub to analyze, well, that would be a real insight we don't normally have :slight_smile:

14

Happy to use it and help track down the issue. Want to move to DMs to avoid flooding the thread? We can post back here whatever ends up being relevant to others.

15

@gopher.ny I've sent you a DM ~3 days ago. Maybe you didn't see it :thinking: