In a previous post, you learned how to troubleshoot HTTP Error 500 – Internal server error. In this post, we will look into how to fix HTTP Error 503 – The service is unavailable.

Cause of HTTP Error 503

HTTP Error 503 is another very common error you might face with an IIS-hosted website in addition to the 500 – Internal server error.

HTTP Error 503. The service is unavailable

HTTP Error 503. The service is unavailable

The primary reason for this error is a stopped or disabled application pool. The application pool is the IIS component that initiates a worker process, which then allows the web server to process incoming requests for a website. When something is wrong with the application pool, the web server throws an HTTP Error 503.

Rapid-Fail Protection

There can be various reasons for an application pool failure, such as an unhandled exception in the code, an expired password for the application pool identity, or something else. By default, IIS is configured to disable a malfunctioning application pool if its worker process faces five consecutive crashes within a period of five minutes. This setting is known as Rapid-Fail Protection, which is available under the Advanced Settings of an application pool. This is shown in the following screenshot:

Viewing or modifying the rapid fail protection setting for an application pool

Viewing or modifying the rapid fail protection setting for an application pool

  • Enabled—The value True indicates that the rapid-fail protection feature is active, which is the default. Set the value to False to disable it.
  • Failure Interval (minutes)—The time interval to specify the number of minutes (by default, 5) to count the failures for a process.
  • Maximum Failures—The maximum number of failures that are allowed within the time interval mentioned above (by default, 5).

While troubleshooting an application pool-related problem, you can modify these parameters, if needed.

Debugging HTTP Error 503

To determine the exact reason why the application pool is disabled or stopped, open the Event Viewer, navigate to the System log, and look for error or warning events whose source is Windows Process Activation Service (WAS). WAS is responsible for starting/stopping the application pool and keeping track of worker processes in the IIS.

The following screenshot shows that the application pool is disabled because its identity is invalid:

Checking the system log to identify the cause of application pool failure

Checking the system log to identify the cause of application pool failure

If you couldn't find anything in the System log, take a look in the Application log since the ASP.Net-related exceptions are logged there. As discussed above, when a worker process experiences five fatal errors or exceptions within five minutes, rapid-fail protection kicks in and automatically disables the faulting application pool.

Based on event logs, if you conclude that the reason for application pool failure is a bug in the application code, but you still want to keep the application pool running until your developer fixes it, you could temporarily adjust the behavior of rapid-fail protection, either by increasing the Maximum Failures or the Failure Interval to a higher value. You could even disable this feature by using the following PowerShell command:

Set-WebConfigurationProperty '//*[@name=""]//failure' -Name rapidFailProtection -Value $False
Viewing and disabling the rapid fail protection for an application pool with PowerShell

Viewing and disabling the rapid fail protection for an application pool with PowerShell

Remember that the rapid-fail protection feature is there for the safety of the web server, so disabling it shouldn't be considered a solution to the problem. Instead, fixing the underlying cause (or bug causing the behavior) in the application code is really important. Anyway, disabling it sometimes comes in handy if developers are taking longer to fix the bug; meanwhile, you want to keep the web application up and running. Once rapid-fail protection is disabled, the web server won't disable the faulting application pool, and visitors will no longer see HTTP Error 503.

Fixing HTTP Error 503

A simple resolution for HTTP Error 503 is to start the application pool corresponding to your website. If you get an application pool identity-related error or warning, make sure the username and password for the identity are correct. If a custom username is used, make sure its password is not expired. If possible, set the password to never expire for that user.

If the application pool stops repeatedly but there is no application pool identity-related error in the system log, the issue is likely due to some fatal error or unhandled exception in the code. In that case, the application log can give you some useful insights. The following screenshot shows a typical error logged in the application log that occurred due to an unhandled exception:

Checking the application log to identify the cause of application pool failure

Checking the application log to identify the cause of application pool failure

If you see such errors or warnings, notify your application developers, and ask them to fix the exception. If needed, share the detailed error message recorded in the event log.

Common 503 substatus codes

The following table covers the common HTTP 503 substatus codes, along with their possible causes and troubleshooting advice:

Status CodePossible CauseTroubleshooting Advice
503.0The application pool is unavailableThe application pool is either stopped or disabled. To fix this error, start the application pool corresponding to your website. If it fails repeatedly, check the event log to understand why it is failing. We covered how to fix this error above.
503.2The concurrent request limit has exceededThe appConcurrentRequestLimit is a serverRuntime attribute that specifies the maximum concurrent requests (with a default value of 5000) that can be queued for application. The 503.2 error indicates that this limit has been exceeded. To resolve this error, you can increase the value using the following command:

%SystemRoot%\System32\inetsrv\appcmd.exe set config /section:serverRuntime /appConcurrentRequestLimit:100000

If you get ERROR ( message:Unknown attribute "appConcurrentRequestLimit". Replace with -? for help. ) while running this command, use the following command instead:

%SystemRoot%\System32\inetsrv\appcmd.exe set config /section:system.webserver/serverRuntime /appConcurrentRequestLimit:100000
503.3The ASP.NET queue is fullThe requestQueueLimit attribute specifies the maximum number of requests (with a default value of 1000) that can be queued by the ASP.NET process. When this queue is full, the 503.3 error is returned. To resolve this error, set the Queue Length attribute to a higher value in the application pool's advanced settings. See this image for reference. Usually, exceeded queue length is a sign of a server unable to keep up with the requests. Therefore, you could use performance counters to understand why the server is struggling.
503.4The FastCGI queue is fullThis error occurs when the FastCGI process queue is full. To fix this error, increase the value of the Queue Length attribute for your FastCGI process. To do so, open the IIS Manager, click the server name, and double-click FastCGI Settings. Now, double-click the FastCGI process for the particular PHP version that your application is using, and increase the value of Queue Length. See this image for reference.


Subscribe to 4sysops newsletter!


You can see that, like most IIS errors, HTTP Error 503 can be fixed with the help of detailed errors and failed request tracing. However, in the event of application pool-related errors, the HTTP.sys driver throws the 503.0 error because the application pool isn't available to handle the request. Thus, the detailed error or failed request tracing rule is not even triggered. In such situations, you can rely on Windows event logs to troubleshoot.

  1. Denis Galvez 9 months ago

    Very useful, thanks for this information.
    Quick question, when changing the Rapid-Fail Protection from True to False, do I need to restart the app pool? Or does it takes the change concurrently?
    Thank you!

    • Author

      Thank you for your comment. There is no need to manually restart the app pool after changing rapid-fail protection setting.

  2. Muhammad Ali 4 months ago

    I had developed web api in ASP.NET 6.0 CORE and it is working successfully in swagger and I also published at IIS. I had also develop an razor page from where I am access my web api and it is running properly. but after multiple approx 60-70 time accessing that web api it gives HTTP Error 503.0 – Server has been shutdown. Even event log also don’t log have any. After when I restart my Web API can you please help me?

  3. Krishna Kalpavriksha 2 months ago

    Hi Surendra,

    We have developed a web application (Angular + .Net core C#) , the application has been hosted on IIS. Randomly everyday the service goes down with error code 503 – service unavailable. We are struggling since a month to find the root cause. Could you pls help us to identify the issue.
    Krishna Kalpavriksha

Leave a reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account