Not all patches carry the same risk
"Patch regularly" is easy advice to give and hard to act on, because not every update deserves the same response. A kernel security fix for a remotely exploitable vulnerability is not the same category as a minor version bump to a text editor nobody uses interactively. Treating them identically is how patch cadences fail: either everything gets applied immediately, including changes that could break something on a Friday afternoon, or everything gets deferred, including the fix that actually mattered.
The useful split is by exposure and severity. A package that's reachable from the internet (your web server, SSH daemon, database if it's publicly bound) with a known critical CVE should be patched within a day, sometimes hours. Internal tooling with no direct exposure can usually wait for a scheduled window.
A cadence that holds up in practice
For most servers running production workloads, this pattern works well:
- Security patches for internet-facing services: applied within 24 to 48 hours of release
- Kernel and core system updates: batched into a weekly or biweekly maintenance window, reboot included
- Non-security package updates: monthly, or bundled with a planned release
- Major version upgrades (a new Ubuntu LTS, a new PostgreSQL major version): planned separately, tested on staging first
Why 'set it and forget it' doesn't work
Unattended upgrades tools exist for a reason, and they're useful for low-risk packages. But applying every update automatically, including kernel and service restarts, on a server nobody's watching is how a routine patch turns into an unplanned outage. The fix isn't to avoid automation, it's to scope it: automate the safe, well-tested categories, and keep a human in the loop for anything that touches a running service.
The other failure mode is the opposite: patching gets deferred indefinitely because nobody owns it, and six months later a server is carrying a dozen known vulnerabilities. This is the more common failure, and it's the one that shows up in breach post-mortems.
Where this fits into ongoing admin work
A tracked patch cadence is part of what we do under Linux server administration: provisioning, ongoing maintenance, and the day-to-day care that keeps a server from becoming a liability nobody wants to touch. If you're not sure what's currently patched and what isn't across your servers, that's usually the first thing worth finding out.