PowerShell Script: Monitor and Auto-Restart Windows Services

Monitoring a critical Windows service with PowerShell helps you detect downtime fast and recover automatically before users notice.

Use case

• Track a business-critical service (IIS, SQL, custom app service)
• Restart service automatically if stopped
• Write logs for troubleshooting and audit

PowerShell monitoring script

$ServiceName = "Spooler"          # replace with your service
$LogFile = "C:\Logs\service-monitor.log"

if (!(Test-Path (Split-Path $LogFile))) {
    New-Item -ItemType Directory -Path (Split-Path $LogFile) -Force | Out-Null
}

$svc = Get-Service -Name $ServiceName -ErrorAction SilentlyContinue
$time = Get-Date -Format "yyyy-MM-dd HH:mm:ss"

if (-not $svc) {
    "$time | ERROR | Service '$ServiceName' not found" | Out-File -FilePath $LogFile -Append
    exit 1
}

if ($svc.Status -ne 'Running') {
    "$time | WARN  | Service '$ServiceName' is $($svc.Status). Restarting..." | Out-File -FilePath $LogFile -Append
    try {
        Restart-Service -Name $ServiceName -Force -ErrorAction Stop
        Start-Sleep -Seconds 3
        $newState = (Get-Service -Name $ServiceName).Status
        "$time | INFO  | Service '$ServiceName' state after restart: $newState" | Out-File -FilePath $LogFile -Append
    }
    catch {
        "$time | ERROR | Restart failed for '$ServiceName' :: $($_.Exception.Message)" | Out-File -FilePath $LogFile -Append
        exit 2
    }
}
else {
    "$time | OK    | Service '$ServiceName' is running" | Out-File -FilePath $LogFile -Append
}

Schedule it

• Create a Task Scheduler task to run every 5 minutes
• Run with highest privileges
• Use service account if required by policy

Hardening tips

• Monitor only approved service names
• Rotate or archive logs periodically
• Add alerting (email/Teams/webhook) for repeated failures

This gives you lightweight service resilience without deploying a full monitoring stack.

Operational Checklist (Production-Safe)

• Confirm prerequisites and permissions before changes.
• Apply the change in staging or a low-risk window first.
• Validate client/server logs (PolicyAgent, WUAHandler, Event Viewer) after each action.
• Document rollback steps and owner responsibility.
• Re-verify service health and security controls after completion.

Validation and Success Criteria

• The target workflow completes without errors and without introducing service interruption.
• Expected security/availability behavior is confirmed through logs and direct functional tests.
• No unintended access, policy drift, or performance regression is observed after deployment.

Common Pitfalls to Avoid

• Applying changes without confirming exact environment prerequisites.
• Skipping post-change verification and relying only on command success output.
• Not defining rollback steps before touching production assets.

References

• Microsoft Learn
• CISA
• NIST