How to schedule automatic reboots on Windows Server VPS

Windows servers running long-lived applications — IIS hosting APIs, .NET services, SQL Server instances, integration gateways — degrade gradually without reboots. Memory fragments, kernel handles accumulate, and pending updates remain in an intermediate state that only a reboot resolves. In production, the stable practice is to schedule periodic reboots during a low-traffic window.

This tutorial covers how to configure automatic reboots on a Windows Server VPS via Task Scheduler (graphical interface and command line) and via PowerShell. It also shows how to add warnings for active RDP sessions, abort conditions based on load, and auditable logs to confirm that each window executed. Estimated time: 25 minutes.

The audience is a Windows sysadmin who already has the server configured and wants to automate the maintenance cycle without depending on a manual connection at 4 AM on a Sunday.

Prerequisites

Before starting, confirm the basic session data. These values are referenced in the commands below:

Decision: Task Scheduler or PowerShell

There are two paths to schedule a reboot on Windows. Each one fits a scenario:

For a single server, Task Scheduler via GUI is enough. For a fleet of 5+ servers or if you use configuration as code, PowerShell is the way. We will cover all three methods — pick the one that fits.

Method 1: Task Scheduler via the graphical interface

The graphical interface is the fastest way for an isolated server. The steps below create a task that reboots the server every Sunday at 4 AM.

Method 2: Creation via schtasks

To script the same schedule in a single line — useful in provisioning or to document configuration — use schtasks.

schtasks /create `
  /tn "Weekly Maintenance Reboot" `
  /tr "shutdown.exe /r /t 600 /c 'Automatic weekly maintenance' /f" `
  /sc weekly /d SUN /st 04:00 `
  /ru "SYSTEM" /rl HIGHEST /f

schtasks /query /tn "Weekly Maintenance Reboot" /v /fo LIST

Method 3: PowerShell with conditional logic

When you need more complex conditions — abort the reboot if CPU is above 80%, or if a critical service is in a transaction — wrap the logic in a script and schedule it via Register-ScheduledTask.

$LogPath = "C:\Scripts\weekly-reboot.log"
$Stamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"

# Check average CPU load over the last 60s
$cpu = (Get-Counter '\Processor(_Total)\% Processor Time' `
  -SampleInterval 5 -MaxSamples 12).CounterSamples |
  Measure-Object -Property CookedValue -Average

if ($cpu.Average -gt 80) {
    Add-Content $LogPath "$Stamp ABORT cpu=$([math]::Round($cpu.Average,1))%"
    exit 1
}

# Check critical service (adjust the name)
$svc = Get-Service -Name "MyCriticalService" -ErrorAction SilentlyContinue
if ($svc -and $svc.Status -eq 'Running') {
    # Application health-check logic here
    Add-Content $LogPath "$Stamp OK service active, proceeding"
}

Add-Content $LogPath "$Stamp REBOOT starting shutdown /r /t 600"
Start-Process -FilePath "shutdown.exe" `
  -ArgumentList "/r","/t","600","/c","Weekly maintenance","/f"

$Action = New-ScheduledTaskAction `
  -Execute "PowerShell.exe" `
  -Argument "-ExecutionPolicy Bypass -File C:\Scripts\weekly-reboot.ps1"

$Trigger = New-ScheduledTaskTrigger `
  -Weekly -DaysOfWeek Sunday -At 04:00

$Principal = New-ScheduledTaskPrincipal `
  -UserId "SYSTEM" -LogonType ServiceAccount -RunLevel Highest

$Settings = New-ScheduledTaskSettingsSet `
  -StartWhenAvailable -DontStopOnIdleEnd `
  -RestartCount 3 -RestartInterval (New-TimeSpan -Minutes 1)

Register-ScheduledTask `
  -TaskName "Weekly Maintenance Reboot" `
  -Action $Action -Trigger $Trigger `
  -Principal $Principal -Settings $Settings -Force

Verification

Confirm that the task is active and the next run time is correct:

Get-ScheduledTask -TaskName "Weekly Maintenance Reboot" |
  Select-Object TaskName, State, @{N='Next';E={
    (Get-ScheduledTaskInfo $_).NextRunTime
  }}

Expected output:

TaskName                    State    Next
--------                    -----    -------
Weekly Maintenance Reboot   Ready    6/1/2026 4:00:00 AM

To confirm that the task ran after the first Sunday, query the history:

Get-ScheduledTaskInfo -TaskName "Weekly Maintenance Reboot"

The LastRunTime field shows when it ran and LastTaskResult should be 0 (success). Any different value indicates failure — investigate via Task Scheduler → History or via Get-WinEvent on the “Microsoft-Windows-TaskScheduler/Operational” log.

Troubleshooting

Task does not run, no error message

Check whether Task Scheduler history is enabled. By default, on some Windows Server installations it comes disabled, which prevents you from seeing what happened. In the right panel of Task Scheduler, click “Enable All Tasks History”.

After that, open the task and check the History tab. If the event is “Task did not start because the account is not logged on” — you forgot to check “Run whether user is logged on or not” during creation.

Reboot fires but the server does not come back up

Check whether any service with automatic startup is failing on boot. Run after reconnecting:

Get-EventLog -LogName System -EntryType Error -Newest 20 |
  Where-Object {$_.Source -like "*Service*"}

A service stuck in “Starting” indefinitely is the most common cause. It is usually a network or database dependency that has not stabilized yet — add a delay to the startup of the problematic service.

Reboot warning does not appear to RDP users

The /c "message" parameter only works if the user has an active session at the moment shutdown /t 600 runs. If they connect after the trigger, nothing is shown. For proactive notification, add before the shutdown:

msg * /TIME:60 "Scheduled reboot in 10 minutes - save your work"

msg.exe broadcasts to all active sessions — combined with the visual warning from shutdown, it covers both cases.

Next steps

With the reboot cycle automated, it is worth evolving in complementary directions:

• Configure a post-reboot health check via PowerShell that validates critical services and sends an alert if something did not come up in 5 minutes.
• Add event log writes (Write-EventLog) in the wrapper script to centralize via syslog or SIEM.
• Document the maintenance window on an internal status page so the application team knows when to expect downtime.
• Combine with automatic pre-reboot snapshots via your provider’s API for quick rollback if something breaks.
• Consider scheduling Windows Update to run before the reboot, ensuring the cycle covers pending updates.

If you are putting this in production, a Hostini VPS running Windows Server already includes an out-of-band console in the panel — useful for recovering access if a scheduled reboot breaks the network and RDP becomes unavailable, avoiding having to rely on support to reset the machine.