Skip to main content

Scheduled Patching

Automate patching during defined maintenance windows.

Benefits​

  • Consistency - Regular patching cadence
  • Reduced risk - Controlled maintenance windows
  • Less manual work - Automated execution
  • Compliance - Documented patch schedules

Schedule Components​

Targeting​

Define which servers to patch:

  • All servers
  • By environment (production, staging)
  • By tags (web, database)
  • By OS (Ubuntu, RHEL)
  • By hostname pattern

Timing​

When the schedule runs:

  • Specific time and timezone
  • Recurring pattern (daily, weekly, monthly)
  • Cron expression for complex schedules

Options​

How patching behaves:

  • Security updates only
  • Reboot policy
  • Stagger between servers
  • Failure threshold

Notifications​

Alert when schedules run:

  • Webhook (Slack, Teams)
  • Email notifications

Cron Expressions​

For advanced scheduling:

┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of month (1 - 31)
│ │ │ ┌───────────── month (1 - 12)
│ │ │ │ ┌───────────── day of week (0 - 6) (Sunday = 0)
│ │ │ │ │
* * * * *

Examples:

0 2 * * 0     # Every Sunday at 2 AM
0 3 1 * *     # First of each month at 3 AM
0 4 * * 1-5   # Weekdays at 4 AM

Best Practices​

  1. Test first - Run on staging before production
  2. Stagger production - Don't patch all at once
  3. Monitor after - Watch for issues post-patch
  4. Set notifications - Know when patches complete
  5. Review failures - Investigate and retry

Schedule Examples​

Weekly Production Patching​

  • Targets: environment = production
  • Schedule: Sunday 2 AM
  • Options: Security only, reboot if required
  • Stagger: 5 minutes between servers

Monthly Full Update​

  • Targets: All servers
  • Schedule: First Saturday 3 AM
  • Options: All updates, reboot always
  • Stagger: 10 minutes between servers

Daily Staging​

  • Targets: environment = staging
  • Schedule: Daily at midnight
  • Options: All updates, reboot always
  • Stagger: None (parallel)