How often do you patch and restart your servers?

A monthly cycle is a reasonable starting point for Windows servers. Patch after the monthly updates arrive and reboot as part of the same maintenance job, rather than letting the two schedules drift apart.

Track whether the required updates are installed by your deadline. Uptime can still flag a missed reboot, but 35 days alone doesn't tell you whether a server is patched.

I'd split the schedule by exposure. Internet-facing servers and systems holding sensitive data can go a couple of days after release, with the rest in the next planned maintenance window.

A small test group first gives you a chance to catch trouble before rolling out broadly. The tradeoff is that waiting longer for confidence also leaves vulnerable systems exposed longer.

Check your actual security and compliance deadlines before picking a comfortable monthly date. Some teams work to a 14-day limit for security updates, while others have much shorter internal targets.

Have a documented reason when a server misses its deadline. A calendar window is useful, but it doesn't replace tracking the exceptions.

For Linux, patching and rebooting don't necessarily need the same cadence. One option is monthly updates and a reboot when the kernel or glibc changes, while checking which services need restarting for other updates.

That makes a blanket uptime alarm less useful. Track the update state and any pending restart instead.

Not every team waits for a monthly reboot. Another pattern is monthly Windows patching with weekly restarts, while Linux systems get a quarterly patch and reboot cycle or earlier maintenance when needed. Those choices depend on the environment and its deadlines.