I have a script that runs nightly via cron, it checks if a reboot is required through needrestart, logs the action and reboots the host if required (kernel update or glibc update): https://github.com/nodiscc/xsrv/blob/master/roles/monitoring_netdata/files/usr_local_bin_needrestart-autorestart

Nightly is a baseline, if requirements dictate that the host should not reboot without warning at 5am, I adjust the cron expression.

Once a month on patch Tuesday. May as well reboot everything.

Whenever I update the kernel or low level libraries practically everything uses like glibc.

Only when necessary and my monitoring system detects a need for it (kernel updates e.g.)

Depends on the situation - if it’s my own server, I’m happy rebooting them (almost) whenever.

If it’s a customer’s server, then it may be anything from monthly to annually …

I am running a laptop server. Currently reboot once every few weeks, but looking to potentially set up a nightly shutdown/reboot when I’m sleeping since it’s just for me.

Periodic reboots are useful for a hands-off approach to security patching.

For most use cases, all software should be restarted after it receives a security patch.

If your threat model allows a latency of, say, 14 days between patch release and patch applied, then the simplest solution is to just enable unattended updates to install patches as soon as they are released, and then impose a 14 day uptime limit to periodically restart the patched software.

You could always take a more hands-on approach and pay attention to which software is updated and only restart the specific services that are patched. But that’s expensive, and humans are fallible. Almost everyone, from hobbyists to enterprises, is better off with a dumb uptime limit instead.

Of course, if you’re just a hobbyists, then your threat model may be so lax that you don’t need to bother with any of this. Just reboot when you install kernel updates.