[Feature]: Implement Recurring Patching Policies (Weekly, Monthly, Quarterly) with Pre-Patch Alerts

What is the installation method of your PatchMon server?

Proxmox-community script

What is the version of your PatchMon server?

2.0.2

Briefly describe the feature

Add support for scheduled patching policies with weekly/monthly/quarterly recurrences and pre-patch email notifications.

Detailed description

Currently, PatchMon supports scheduled patching where an admin can approve a patch run and schedule it for a specific future maintenance window. However, this still requires a manual approval step and does not support fully automated, recurring schedules.

This feature proposes the addition of Patching Policies – fully automated, time-based rules that would patch groups of systems on a defined recurrence (e.g., every 2nd Tuesday, first day of the quarter) without manual intervention, while sending a mandatory pre-patch email notification 24 hours in advance.

Problem Statement / User Story:
As a systems administrator responsible for 500+ Linux servers, I want to define a policy that automatically patches my development servers every Wednesday at 2 AM, and my production servers on the second Saturday of every month. I also need a mandatory 24-hour warning email sent to my team before the automated patching begins, so we can perform final checks or postpone the run if needed.

Proposed Solution:
Add a new "Patching Policies" section within the PatchMon UI, next to the existing "Hosts" and "Patch Management" areas.

Key Capabilities:

1. Policy Definition (CRUD)

   • Name: e.g., "Monthly Prod Patching"
   • Target Group: Select hosts or groups (Tags)
   • Package Selection: "All updates", "Security only", or "Specific packages"

2. Scheduling (Recurrence Rules)

   A flexible scheduler, similar to cron but user-friendly, should support:

   • Weekly: Every Monday, every 2 weeks on Tuesday
   • Monthly: Day 15 of every month, Second Tuesday of every month, First Monday of each quarter
   • Quarterly: January 1, April 1, July 1, October 1 (or first day of quarter)
   • Custom: Cron expression for advanced needs

3. Execution Window

   • Start time: "At 02:00 AM server time"
   • Max duration: "Stop patching after 4 hours"

4. Pre-Patch Email Notification (Mandatory)

   • Timing: Exactly 24 hours before the scheduled start time.
   • Recipients: Policy-assigned email list or all users with admin role.
   • Content: Policy name, affected hosts, list of pending updates (preview/dry-run result), direct link to "Postpone/Cancel this run" in UI.
   • Action Buttons in Email: Confirm & Proceed (default), Delay by 24h, Skip this occurrence.

UI/UX Example:
In the new "Patching Policies" tab:

• Create Policy
  Name: [ monthly-prod ]
  Target: [ Select Hosts/Groups ▼ ] Production_Servers
  Action: [ Security Updates Only ▼ ]
  Schedule:
  Frequency: [ Monthly ▼ ]
  Interval: [ Second Tuesday ]
  At: [ 02:00 AM UTC ]

Pre-Patch Notice:
Send [ 24 Hours ] before to: (Choose Destination from Reporting Destinations)
Require acknowledgement: [ ] Yes / [x] No (admin override)

Status: [ Enabled ] [ Save Policy ] [ Test Run Now ]

Email Mockup (24h prior):

Subject: [PatchMon] Pre-patch Alert: "monthly-prod" starts in 24h

Body:
The following patching policy will execute automatically on 2026-06-15 at 02:00 UTC.

Policy: monthly-prod
Hosts affected: prod-db-01, prod-web-02 (3 hosts)
Pending updates: 12 packages (8 security)

Benefits for PatchMon:

1. True automation – moves beyond manual approval steps.
2. Compliance readiness – satisfies change management requirements with advance notification and audit trails.
3. Risk reduction – 24-hour pre-notice gives teams time to postpone if anomalies are detected (e.g., high load, critical incident).

Additional Considerations:

• Audit Log: All policy-triggered runs must be logged with reason: "policy monthly-prod"
• Override: Manual run should still be possible. A policy run can be skipped via email link or UI.
• Safety: If a host was patched by another means within 48h of the policy, the agent should skip it to avoid unnecessary reboots.

Technical Notes:

• Use existing Redis/Asynq queue for scheduling
• Leverage existing email notification system
• Reuse existing dry-run and patch execution engine

Why is this useful?

1. Reduces manual work: Eliminates the need for an admin to manually approve every patch run, saving time on recurring maintenance tasks.
2. Enforces compliance: Many compliance frameworks (PCI, SOC2, ISO 27001) require patching within fixed timeframes. Automated policies ensure this happens consistently.
3. Prevents human error: No risk of forgetting to approve a critical patch window.
4. Provides predictable maintenance: Teams know exactly when patches will apply (e.g., "every second Tuesday at 2 AM").
5. Enables risk mitigation: The 24-hour pre-notification gives teams time to postpone patching if issues arise (e.g., incident, high load, business-critical period), balancing automation with safety.