About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
Most business applications on a Windows server run at least one Windows service: a database engine, a licence server, an integration or scheduling service, or the application server itself. Each service has recovery settings that tell Windows what to do if the service fails: do nothing, restart it, run a program, or restart the whole computer. Set well, these settings bring a service back within seconds after a rare crash. Set carelessly, they restart a service every few minutes for weeks while nobody notices that something is wrong.
The short version: restart the service on the first and second failure, choose a reset period that matches how often a real failure would be acceptable, make sure every restart is visible to someone, and never use Restart the Computer as a routine action on a shared application server.
Why it matters
A service that stops unexpectedly at 2 am will stay stopped until someone notices, unless recovery actions are set. For a business application, that can mean users arriving to an error message, overnight imports that never ran, or a licence service that is down while everyone tries to sign in.
The opposite failure is quieter. A service that crashes and is restarted automatically looks healthy from the outside. If the cause is a memory leak, a corrupt input file or a failing dependency, the restarts can go on for weeks, each one losing whatever the service was doing at the time. The recovery settings are a safety net, not a fix. They need monitoring alongside them.
How it works
The failure count and the reset period
The service control manager is the part of Windows that starts, stops and supervises services. Microsoft's documentation explains how it decides which recovery action to take: The service control manager counts the number of times each service has failed since the system booted. The count is reset to 0 if the service has not failed for dwResetPeriod seconds.
The recovery actions are a list. When a service fails for the first time, Windows takes the first action; on the second failure, the second action, and so on. The documentation adds: If N is greater than cActions, the service controller repeats the last action in the array. The Recovery tab in the Services console shows this list as First failure, Second failure and Subsequent failures, each with an action such as Restart the Service, plus a Reset fail count after value in days and a Restart service after delay in minutes.
This has three practical consequences:
- If Subsequent failures is set to Restart the Service, the restarts never run out. Every failure after the second gets the same action, for as long as the service keeps crashing after it has started.
- A queued restart can still leave a service stopped. In Microsoft's BizTalk host-instance example, if SQL Server is unavailable when the restart is attempted and the host instance fails to start, no further attempt is made. That is an application-specific example, not a universal Windows retry rule. For another service, behaviour depends on how its process fails or reports a stopped state, its error code and the non-crash failure flag. Check vendor guidance and validate the actual startup and dependency-failure paths in an isolated test; do not assume either unlimited retries or no retries.
- The reset period decides what counts as "first". With a reset period of one day, a service that fails once a day is always on its first failure. With a long reset period, a few failures spread over a fortnight can move the service on to the last action.
Each action also has a delay. The documentation describes the delay as The time to wait before performing the specified action, in milliseconds. The Services console shows it in minutes.
Which failures trigger recovery
This is the setting most often misunderstood. By default, Windows treats a service as failed only if its process ends without telling Windows it has stopped. That is a crash. A service that shuts itself down cleanly but reports an error code is not treated as failed, unless a second option is set.
Microsoft describes that option, which the Recovery tab shows as a check box, Enable actions for stops with errors. When it is on, actions are taken if the service process terminates without reporting a status of SERVICE_STOPPED or if it enters the SERVICE_STOPPED state but the dwWin32ExitCode member of the SERVICE_STATUS structure is not ERROR_SUCCESS (0). When it is off, failure actions are queued only if the service terminates without reporting a status of SERVICE_STOPPED.
In plain terms, many application services stop themselves deliberately when they hit a problem they cannot handle, such as a lost database connection or a missing licence file, and report an error as they stop. Without that check box, those services just stay stopped, even though the Recovery tab says Restart the Service. Microsoft notes the flag can be useful to set this flag if your service has common failure paths where is it possible that the service could recover (wording as published). It also notes that The change takes effect the next time the system is started. Plan to set it in a maintenance window, not during an incident.
A queued restart cannot be cancelled
When a service fails and its action is a restart after a delay of, say, five minutes, Windows schedules that restart. Microsoft's documentation is direct about what happens next: A queued restart action cannot be canceled. If the service is manually restarted and then stopped before the queued restart action occurs, the service will restart unexpectedly when the time delay elapses. It adds that The service must be explicitly disabled to prevent it from restarting.
This catches administrators during maintenance. Someone stops a failing service to repair a configuration file, and the service starts again by itself in the middle of the repair. If you need a service to stay stopped after a failure, set its startup type to Disabled first, do the work, then set it back.
Run a Program and Restart the Computer
The other two actions need care:
- Run a Program runs a command line when the service fails. Microsoft notes that This process runs under the same account as the service. A script that sends an alert or collects logs is useful. Remember that it runs with the service's permissions, which for many services is LocalSystem.
- Restart the Computer restarts the whole server, optionally after broadcasting a message. On a server that runs one appliance-style service, that may be reasonable. On a shared application server or a Remote Desktop server, it ends every user's session because one service failed. Use it only when someone has decided that a full restart is the correct response to that service's failure.
Some services cannot have their recovery options changed at all. The legacy sc.exe failure reference notes that Not all services allow changes to their failure options. Some run as part of a service set.
Setting recovery options from the command line
The Services console is the easiest way to see and change recovery options. For repeatable configuration, Microsoft's archived reference documents sc.exe failure, whose syntax includes reset= (the error-free period in seconds) and actions= (actions with delays in milliseconds). Use an elevated Command Prompt or PowerShell session when configuring an authorised test service, and spell out sc.exe: in Windows PowerShell 5.1, sc is an alias for Set-Content.
The following is a historical syntax illustration for the Microsoft FTP service, msftpsvc, not a recommended policy or an instruction to change that service. It resets the failure count after 30 error-free seconds and schedules a restart after 5,000 milliseconds (five seconds), unlike the one-day reset and one-minute delay suggested below. It has not been run or lab tested for this article:
sc.exe failure msftpsvc reset= 30 actions= restart/5000
Each option name includes its equal sign, and a space must follow it before the value, as in actions= restart. Microsoft warns: If the space is omitted, the operation will fail. It also says the reset= and actions= parameters each require the other. The reference page is from the Windows Server 2012 R2 documentation set; check sc.exe failure /? on your exact server version before relying on it, and test on a non-production server.
What to choose and why
A sensible starting point for a business application service
| Setting | Starting value | Reason |
|---|---|---|
| First failure | Restart the Service | Most single crashes are transient |
| Second failure | Restart the Service | Gives one more chance |
| Subsequent failures | Take No Action, or Run a Program that alerts | Stops an endless restart loop and makes a repeat failure visible |
| Restart service after | 1 minute | Gives dependencies such as a database time to settle; adjust to the application |
| Reset fail count after | 1 day | Two crashes in a day are noticed; one crash a week resets cleanly |
| Enable actions for stops with errors | On, if the vendor confirms the service reports errors on stop | Otherwise a clean error exit is never restarted |
These are starting values, not rules. Check the application vendor's guidance first. Some vendors document their own recovery settings, and some services must not be restarted without another service being restarted first.
Make every restart visible
An automatic restart that nobody sees hides the fault. At least one of these should be in place:
- monitoring that alerts when the service stops or restarts;
- a regular review of the System event log for Service Control Manager entries about that service;
- a Run a Program action on the last failure that sends an alert.
If a service is being restarted more than occasionally, treat it as a fault to be diagnosed: look at the application's own log and the Windows Application log around each failure.
Check dependencies, not just the service
A recovery restart only helps if the service can start. If the service depends on a database, a network share or another service, the restart may fail repeatedly for a reason the recovery settings cannot fix. The Dependencies tab in the service properties shows what Windows knows about, but many applications also depend on things Windows does not track, such as a database on another server. A restart delay of a minute or more often helps when the dependency is briefly unavailable.
Risks and limits
- Recovery settings are not monitoring. They make a service come back. They do not tell anyone it failed.
- Endless restarts can cause harm. A service that processes a queue and crashes on a bad item may repeat that item on every restart.
- Enable actions for stops with errors changes behaviour after the next restart of the server, according to Microsoft. Test it in a planned window.
- Do not edit recovery options on services that are part of Windows unless Microsoft or the vendor tells you to. Many core services ship with their own settings.
- The historical command is adapted from Microsoft's documentation using the explicit
sc.exeexecutable name; it was not run for this article. Its FTP service and short timings are not recommended settings. Checksc.exe failure /?on your exact version before any authorised isolated test.
Sources
Opened 14 November 2026.
- Microsoft Learn: SERVICE_FAILURE_ACTIONSA structure (winsvc.h), updated 2024-11-20.
- Microsoft Learn: SERVICE_FAILURE_ACTIONS_FLAG structure (winsvc.h), updated 2024-02-22.
- Microsoft Learn: SC_ACTION structure (winsvc.h), updated 2024-02-22.
- Microsoft Learn: ChangeServiceConfig2A function (winsvc.h), updated 2025-07-01.
- Microsoft Learn (previous versions): Sc failure, Windows Server 2012 R2 documentation, updated 2021-11-12.
- Microsoft Learn: Host Instance Service Properties in Services - BizTalk Server, updated 2026-03-25 (Recovery tab settings and the BizTalk-specific failed-start example).
- Microsoft Learn: Set-Content, Windows PowerShell 5.1, the
scalias; no displayed date, metadata updated 2025-07-24. - Microsoft Learn: sc.exe config, updated 2026-02-16 (start types, including delayed-auto).
Related service: Managed support.
Related future topics
- Delayed automatic start and service start order on business application servers.
- Monitoring Windows services: what to alert on and what to ignore.
- Diagnosing a service that crashes on a schedule.
Learning notes
- Windows counts failures per service since boot and resets the count after a quiet period you choose.
- The last action in the list repeats, so Restart the Service on subsequent failures means restarts never run out while the service keeps crashing.
- A recovery attempt may leave the service stopped, as in Microsoft's BizTalk example. Verify the actual service's error and retry paths rather than assuming a universal rule.
- By default only a crash triggers recovery; a clean stop with an error code needs the Enable actions for stops with errors check box.
- A restart Windows has already scheduled cannot be cancelled; disable the service if it must stay stopped.
- Automatic restarts keep users working but hide faults unless someone is alerted.
This article was originally published on .