- kube-scheduler: The Kubernetes scheduler - Fri, Sep 29 2023
- Kubernetes logs: Pod logs, container logs, Docker logs, kubelet logs, and master node logs - Mon, Sep 25 2023
- Kubernetes DaemonSets - Wed, Sep 6 2023
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.
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:
- 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:
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:
(Get-IISAppPool awesomewebsite.com).failure.rapidFailProtection Set-WebConfigurationProperty '//*[@name="awesomewebsite.com"]//failure' -Name rapidFailProtection -Value $False
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:
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 Code | Possible Cause | Troubleshooting Advice |
503.0 | The application pool is unavailable | The 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.2 | The concurrent request limit has exceeded | The 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.3 | The ASP.NET queue is full | The 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.4 | The FastCGI queue is full | This 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!
Conclusion
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.
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!
Thank you for your comment. There is no need to manually restart the app pool after changing rapid-fail protection setting.
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?
If your webapp works for some time and then stops with a 503 error, it is most likely due to crashes in your code. The Rapid-Fail Protection feature disables a faulting application pool automatically. Please read this section carefully: https://4sysops.com/archives/how-to-fix-http-error-503-the-service-is-unavailable/#rtoc-2.
You can check the errors in Application log from these sources:
.NET Runtime
IIS AspNetCore Module V2
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.
BR,
Krishna Kalpavriksha