A service that dies once a week wakes nobody at 3 a.m. if Windows restarts it. Recovery actions are a documented service setting, and they work without a third-party monitor.
Read the current policy with **sc qfailure**, set restarts with **sc failure <name> reset= 86400 actions= restart/60000/...**, then confirm the service comes back after you kill its process.
**sc** works with the service name, not the display name. Get both from one query, and note whether the service can restart at all — services with a dependent chain restart their dependencies too.
Get-Service | Where-Object Status -eq 'Running' | Select-Object Name,DisplayName,StartType | Sort-Object Name -First 15
sc qc Spooler**sc qfailure** prints the current actions and the reset period. Most services ship with nothing configured, which is why a crash leaves them dead until someone notices.
sc qfailure Spooler
sc qfailureflag Spooler
Get-CimInstance Win32_Service -Filter "Name='Spooler'" | Select-Object Name,State,FailureActionsThe three action slots run in sequence for repeated failures within the reset window. A short first delay recovers a transient fault; later delays avoid a restart loop that hides the real problem.
sc failure Spooler reset= 86400 actions= restart/60000/restart/300000/restart/900000
sc qfailure SpoolerRecovery actions fire on a crash, not on a hung service. **failureflag** treats a non-responding service as a failure, which covers the more common case.
sc failureflag Spooler 1
sc qfailureflag Spooler
Get-Service Spooler | Select-Object Status,DependentServicesKilling the process simulates the failure without waiting a week. The service should return within the configured delay, and the event log records both the crash and the recovery.
$p = (Get-CimInstance Win32_Service -Filter "Name='Spooler'").ProcessId
Stop-Process -Id $p -Force
Start-Sleep -Seconds 90
Get-Service Spooler
Get-WinEvent -LogName System -MaxEvents 20 | Where-Object Id -in 7031,7034,7024 | Select-Object TimeCreated,Id,MessageA service that restarts hourly is not fixed, it is hidden. Set a failure threshold in your monitoring and treat repeated restarts as a ticket, not as stability.
Get-WinEvent -FilterHashtable @{LogName='System'; Id=7031; StartTime=(Get-Date).AddDays(-7)} |
Group-Object {$_.Properties[0].Value} | Sort-Object Count -Descending | Select-Object Count,NameEither the actions are empty or the service fails so early that the recovery action runs out. Check sc qfailure and the 7000/7009 entries.
Raise the delays and add a fourth action with an empty value to run a program instead, or investigate the root cause — a loop fills the log and hides everything else.
A management tool or an installer rewrites the service configuration. Reapply it after updates, or move the setting into the deployment package.
A restart does not fix a broken dependency or a missing path. Read the service's own event log channel before adding more retries.
The actions apply when the service is running. A service that is not started has nothing to recover, so set the start type correctly first.
Yes, under Recovery. The sc commands are the same settings, easier to script and to compare between machines.
Reset the policy with sc failure <name> reset= 0 actions= "" and sc failureflag <name> 0, then confirm with sc qfailure that no actions remain.
Free · no account needed · tracks your progress