I have no issues at 183K and nearly 22 day uptime.
Is it just the number, or are you having slowdowns or other issues. The way the memory reports is different in the latest couple update versions, so it is hard to compare old memory numbers to current ones.
I guess my primary concern is that after reboot and the system settles, free memory is 450K. A week later, it is below 220K which is when I reboot. There may be a memory leak or perhaps that's just the normal system usage for internal bookkeeping. I have no idea. My lightly loaded second hub exhibits the same behavior, but takes much longer (~3 wks). Something is consuming memory. Allocs not being freed? Leak(s)? Normal consumption? Rebooting when it approaches 200K free seems prudent to me at least.
Some memory leakage is to be expected and seems to be a result of the mix of applications and drivers on the hub. From my observation, a hub with a mix of applications or drivers that do a lot of HTTP calls will tend to leak a little faster than a hub that only uses the native Z-Wave and Zigbee interfaces. In addition, if you are making a lot of code changes - new/updated drivers and apps - you will see a noticeable drop in free memory. Lastly, anything that does an export of data (for me primarily off hub backups and data for graphs) will cause a very small loss of free memory per export - really only noticeable for me because I am graphing and have over time been able to correlate.
In my opinion, you don't need to reboot unless you are seeing symptoms of slowdowns or missed events.
I wouldn't have known my hub was down to 183K in the above post if I wouldn't have looked.
So which criterea would you recommend to make an automatic reboot (or send a message to my smartphone)? 
BTW: The time when the system gives memory error warnings - IMHO that is already to late.
In my case I prefer to do it before those symptoms start happening just to keep the Family Approval Factor (FAF) / Partner Approval Factor (PAF) high..
I have some rules that monitor my hubs for a particular memory threshold and when it's crossed, reboots the out of bounds hub at a preset time (usually the next evening).
I use to auto reboot at 250k pre f/w 2.3 as the hub started slowing down and even accessing the main menu/devices/apps took a while to load.
With 2.3.1 the behaviour has been different, freeosmem plummets within a week to about 250k then starts to flatten out. So far everything is still responsive at 210k (almost 3 weeks).
Is there any risk to a weekly auto reboot. I set up a weekly Thursday 3:15 am reboot for my previous C-5 and have carried it forward to my C-7 that replaced it.
There isn't any harm as long as it's clean. The issue though exists and should be tracked down and rectified though. Reboots like that shouldn't be necessary.
Also note that with recent changes in the firmware the memory optimization and reporting has changed which means that your hubs should still be responsive at a lower free memory threshold than previous - down to about 180 seems to the be the consensus.
What happens if you don't reboot, have you tried that recently? There have been quite a few memory tweaks/changes in the last couple major releases.
Reboot runs as a post command via crontab on a pi. I set it up a few years ago so it took a while to figure out how to disable it. We'll see how it behaves over the next several weeks. As best I can tell there is no downside to doing a scheduled weekly reboot in the middle of the night. The pi's only jobs are the reboot and running pivpn and the associated dydns update every 15 minutes for pivpn.
My hub free memory drops daily at the "Database cleanup" time. I moved it from 2:15 am to 1:00 am just to check and the nightly memory drop follows. Usually a significant drop the first night after a reboot and then smaller noticeable daily drops at cleanup time until it dwindles to the point where hub actions seem to start slowing. Somewhere in the 200,000 vicinity. That takes about a week.
Download the Hubitat app
