Service is running but application is down
Documentation: Microsoft Learn
Work the problem
Running does not settle the incident
Fictional case: The service is Running and port 443 is open, but an application health request returns HTTP 503.
Reasoning notebook
Record the evidence that supports your answer and the check you would run next. Your notes stay in this browser — nothing is uploaded.
Why it happens
The service control manager tracks whether a process started, not whether the code inside it is doing anything. A worker that has deadlocked, exhausted a connection pool, or thrown after the process launched leaves the service in a Running state indefinitely. Anything watching only the service state will therefore never notice.
Check this first
What to look for
The service and TCP checks passed, but the application reported unavailable. Correlate its logs and dependencies before deciding on recovery.
Working through it
Check the expected application endpoint and collect the relevant application and event logs around the failure. Correlate dependency failures and resource pressure. A listening port and Running service state do not establish that a transaction succeeds.
If restarting is the approved recovery action, record evidence first and verify the health request afterward. A temporary recovery does not establish the underlying cause.
Avoiding it next time
Verify the repair: Repeat the application health request and, where possible, a representative transaction after the corrective action.
Primary documentation
Work through the incident
Check beyond service state
The service reports Running, but users cannot reach the application.
The sandbox is visible now. Sign in with Google only when you run or check a task; commands and temporary files are discarded when you leave.
Run a command to inspect its result.