Hi PRTG Community & Paessler Team,

With the evolution of the new PRTG Web GUI and API v2, managing maintenance windows needs a modern overhaul. In the classic interface, users had basic scheduled downtime settings ("from... to..."). Currently, the new Web GUI only allows immediate pausing (either manually indefinitely or with pre-set durations like 5m, 30m, 1h), lacking future scheduling capabilities altogether.

We would like to propose a comprehensive expansion for scheduled maintenance, turning it into a full-featured Downtime Management Framework inside the new Web GUI.

1. Scheduling Future Downtimes (From... To...)
   • Current Gap: You can only pause objects right now for a set duration.
   • Proposed Enhancement: Bring back and enhance the ability to schedule future maintenance windows by defining precise start and end dates/times (From: YYYY-MM-DD HH:MM to To: YYYY-MM-DD HH:MM).

2. Centralized Downtime Manager / Interactive Planner
   Following the great design direction of the new GUI (such as centralized Device Template / Auto-Discovery management and Dependency management), Downtimes should also be managed from a unified view.
   • Dedicated Calendar / Matrix View: A central dashboard listing all upcoming, active, and past scheduled maintenance windows across all objects (Sensors, Devices, Groups, Probes).
   • Multi-Object Scheduling: Ability to select multiple objects (or apply tag/group filters) and attach them to a single maintenance schedule/job.
   • Recurring Maintenance: Support for recurring schedules (e.g., Every 2nd Sunday of the month from 02:00 to 04:00 AM).

3. Granular Control: "Full Pause" vs. "Trigger-Only Pause"
   Currently, pausing an object halts all sensor checks completely. In many enterprise scenarios, engineers still want PRTG to gather performance data and display status checks during maintenance, but suppress active alerting/notifications.
   • Default Behavior: Full Object Pause (Standard behavior: stops polling and data collection).
   • New Option (Checkbox): "Pause Notifications / Triggers Only"

   • When checked, sensors continue polling, updating status, and recording performance data.
   • All associated Notification Triggers (state, threshold, speed triggers) attached to the object/group/probe are suppressed for the duration of the downtime.
   • Benefit: Full data continuity during maintenance windows while completely preventing alarm fatigue for operations teams.

This feature set would bridge a major functional gap in the new Web GUI, significantly boost efficiency for larger infrastructure monitoring, and provide modern, flexible maintenance management without compromising metric collection.