The RMMmax Reboot Manager gives you full visibility and control over device reboots across your entire environment. From scanning reboot status to scheduling automated reboots by group, it eliminates the guesswork of knowing which devices need attention and ensures reboots happen on your schedule — not randomly.
It works across Windows, Mac, and Linux devices through your existing RMM platform or the RMMmax independent agent.
Reboot Status Scanning
Before any action is taken, the Reboot Manager scans each device and reports back with a current reboot status snapshot including:
- Whether a reboot is currently required on the device
- The reason a reboot is pending, categorized as: Windows Update, Component Servicing, Pending File Operations, BitLocker, Pending Package, or Other
- The device’s current uptime — how long it has been running since the last restart
- The date and time of the last reboot
- Whether a reboot is currently blocked (e.g., a blocking condition is preventing the restart from executing)
- Status scans run automatically on a background schedule to keep data current, and can also be triggered manually at any time from the console.
Reboot Status Categories
Each device is evaluated and given one of four reboot status states:
Status Meaning
None – No reboot needed — device is healthy
Required – The OS has flagged a pending reboot
Overdue – Device uptime has exceeded the client’s configured maximum uptime threshold
Blocked – A blocking condition is preventing the reboot from completing
These status flags are visible at the agent level and roll up to the client summary view so you can quickly identify which clients have devices sitting in a required or overdue state.
Three Reboot Action Types
When issuing a reboot — either manually or through automation — you choose how the reboot is delivered:
Immediate — Sends a standard restart command with a short delay (60 seconds on Windows, 1 minute on Linux/Mac), giving any open processes a brief moment before shutdown.
Graceful — Sends a warning notification to the logged-in user before the reboot executes. You configure the message text and the countdown duration in minutes. On Linux and Mac, the message is broadcast via wall. On Windows, the RMMmax management script handles the notification and countdown.
Forced — Sends an immediate hard reboot with no delay and no warning. Useful for unresponsive systems or when you need the device back online immediately after patching.
Manual Reboots
Reboots can be issued manually at any time from the console for individual devices or in bulk:
Single agent reboot — Trigger a reboot on one specific device, choosing the action type and notification parameters. Only online and enabled devices will accept the command.
Bulk reboot — Select multiple devices and send the same reboot action to all of them simultaneously. The system reports back how many were sent, how many were skipped (offline or disabled), and any errors.
All manual reboots are recorded with the initiating user’s account, the action type, and a timestamp.
One-Time Scheduled Reboots
For situations where you want a reboot to happen at a specific future time — such as after hours or during a maintenance window — you can schedule a one-time reboot for one or more devices:
- Set the exact date and time the reboot should fire
- Choose the action type (Immediate, Graceful, or Forced)
- For Graceful reboots, configure a custom warning message and countdown duration in minutes
- Optionally allow the user to delay the reboot
- Scheduled reboots are stored as Pending and executed automatically when their time arrives, checked every 5 minutes by the platform
- Pending scheduled reboots are visible on each device’s summary card so you always know what is queued.
Reboot Groups and Automated Schedules
Reboot Groups are the core of automated reboot management. A group is a named collection of devices under a client that share the same reboot schedule. You can create as many groups as needed, on different schedules, to give you precise control over when each set of devices restarts.
Schedule types available per group:
Schedule Type How it works
Daily Fires every day at the configured hour- Weekly Fires on a specific day of the week at the configured hour
- Monthly Fires on a specific day of the month at the configured hour
- Yearly Fires on a specific day and month at the configured hour
- Custom (Cron) Full cron expression support for advanced scheduling needs
- Uptime Threshold Fires only for devices whose uptime exceeds a configured number of days
- Pending Reboot Fires only for devices that have an active pending reboot flag, optionally requiring it to have been pending for a minimum number of days
The UptimeThreshold and PendingReboot types are particularly useful for MSPs — they let you build a “reboot if needed” policy that only acts on devices that actually require it, rather than rebooting everything on a fixed schedule.
When a group schedule fires, only online and enabled devices receive the reboot command. Offline devices are logged as skipped and will be caught on the next schedule run.
Client-Level Policy Configuration
At the client level, you configure the rules that govern reboot behavior across all devices for that client:
Maximum uptime days — devices exceeding this uptime are flagged as overdue
Maximum deferral count — how many times a user can postpone a graceful reboot
BitLocker check — whether BitLocker encryption state should be verified before a reboot is issued (prevents accidental data exposure on machines where BitLocker hasn’t fully encrypted)
Mandatory reboot window — a start and end hour defining the hours during which reboots are permitted, allowing you to restrict reboot activity to off-hours only
Reboot History
Every reboot — whether manual, scheduled, or group-triggered — is recorded in a per-device reboot history log retained for 90 days. Each history entry captures:
- The date and time the reboot was sent
- Whether it was Manual or Scheduled
- The action type used (Immediate, Graceful, or Forced)
- The user or system that initiated it
- Whether the reboot was successful
The history timeline is viewable per device directly from the console, giving you a clear audit trail for compliance or troubleshooting.
Activity Logging and Email Notifications
Every Reboot Manager action — scans, manual reboots, scheduled group runs, skipped agents, and errors — is written to the team’s Reboot Manager activity log. Email notifications can be enabled for:
Scheduled group runs completing
Background status sync completions
This keeps your team informed without requiring anyone to be logged into the console when automation runs.
Enabling Devices
Like all RMMmax tools, Reboot Manager management is opt-in at the device level. Each device must be explicitly enabled for Reboot Manager before it will participate in scans, group schedules, or receive automated reboots. This ensures you never accidentally reboot a device that should be excluded from management.