Capture enough context to reproduce the failure
Record time and timezone, hostname, request path, method and frequency. Match the request to IIS status, substatus and Win32 status fields. Keep passwords, cookies and private query values out of shared diagnostic output.
On a multi-site server, confirm that you are reading the affected site’s log. Another working site may show that the entire network is not down; it does not validate the failing application’s pool, runtime or certificate.
Choose the first investigation by error family
| Symptom | First investigation | Avoid assuming |
|---|---|---|
| 500.19 | Configuration details, module and error code | It is always an ACL problem |
| 500.30 | ASP.NET Core startup and event logs | A full IIS restart is the remedy |
| 502 / 502.5 | Proxy backend or application process | DNS must be broken |
| 503 | Pool state, service and capacity | Application files must be missing |
Narrow the failure by layer
- Compare external and local access while retaining the intended hostname and valid TLS verification.
- Test a static asset separately from a dynamic route. If only dynamic requests fail, investigate their runtime.
- For a reverse proxy, check the backend at its local port and compare direct and proxied results.
- Correlate pool state and the reason it stopped with Windows events. Do not disable crash protection just to hide repeated failures.
Make a reversible, evidence-based correction
Save the current configuration and change one relevant setting at a time. Restarting every pool can interrupt other customers and remove useful evidence about the original failure.
For example, a 500.19 detail naming an unrecognized configuration section points toward the component owning that section. An access-denied detail calls for checking the effective identity and resource ACL. The same top-level status can require very different corrections.
Define what resolved means
Repeat the previously failing request under the same conditions. Then exercise login, a data operation and any upload flow. Confirm that new matching errors have stopped and neighboring sites remain healthy.
Keep a short incident record with the finding, correction, acceptance result and rollback route. If the issue returns, compare its signature to the previous incident instead of starting with another indiscriminate restart.
If the application provides a request identifier, correlate it with the logs. This avoids treating unrelated failures at similar times as one incident.
Frequently asked questions
Does HTTP 500 always mean an application code bug?
No. Invalid configuration, missing modules, startup failures and application exceptions can all produce server errors. Use detailed status and logs to distinguish them.
Is restarting IIS a permanent fix?
A restart may restore temporary availability without removing the cause. Capture evidence first and limit intervention to the affected site where possible.
What if a proxy returns 502 but the backend works locally?
Compare the destination, port, proxy configuration and timeout against the direct request. Reproduce the same operation through both paths.
Is a successful HTTP code enough to close the incident?
Verify expected content and critical user operations too. An error page accidentally served with HTTP 200 is not a successful application result.