SUPPORT DIAGNOSTICS / PERSONAL LAB

Tracing a service fault.
Verifying the recovery.

A connection can pass while the application fails. Follow a controlled investigation from baseline to fault, then see the evidence of recovery.

PowerShell
Python
DNS → TCP → HTTP

Explore the investigation View source ↗

One endpoint. Three observed states.

Recorded evidence · not live

Baselinelocalhost : 56119

DNSResolved

TCPConnected

HTTP200 healthy

Establish a known baseline. The endpoint returns the expected service identity and healthy response.

HTTP responseRecorded

GET http://127.0.0.1:56119/health

HTTP/1.0 200 OK

{
  "service": "support-diagnostics-lab",
  "status": "ok"
}

10:03:27 UTCFull record ↗

Application faultlocalhost : 56119

DNSResolved

TCPConnected

HTTP503 unavailable

TCP connected. HTTP 503. The application is unavailable even though the port accepts connections.

HTTP responseRecorded

GET http://127.0.0.1:56119/health

HTTP/1.0 503 Service Unavailable

{
  "service": "support-diagnostics-lab",
  "status": "unavailable"
}

10:03:30 UTCFull record ↗

Recovery verifiedlocalhost : 56119

DNSResolved

TCPConnected

HTTP200 healthy

Verify the same endpoint again. HTTP 200, the expected service identity and the healthy payload confirm this recovery.

HTTP responseRecorded

GET http://127.0.0.1:56119/health

HTTP/1.0 200 OK

{
  "service": "support-diagnostics-lab",
  "status": "ok"
}

10:03:33 UTCFull record ↗

Switch stages to compare the evidence.Owned loopback fixture · no production systems

01 / The method

Investigation and decisions

Establish the baseline
Resolve localhost, test the selected TCP port, then inspect the HTTP status and response body. Preserve the result before injecting a fault.
Separate connectivity from application health
TCP still succeeds while the fixture returns 503. This identifies an application-level failure in this experiment; it does not establish a physical device or external network fault.
Remove the controlled fault and retest
Change the fixture from unavailable to healthy on the same port. Repeat the manual probes and the bounded checker; retain the recovery record.
Check alternative failure paths
Stop the owned service and test a reserved nonexistent name separately. Confirm failed prerequisites produce clear findings and skipped downstream checks.

02 / Inspect the evidence

Recorded commands and results

Expand a stage to inspect the commands, actual output and timestamped record. The manual probes and automated checker agree on the main outcome.

Recorded recovery report: successful DNS and TCP checks, HTTP 200 and verified service identity at 10:03:33 UTC on 30 September 2026. — FROM THE SAVED TEST RUN
The recorded recovery report
Successful connection checks, HTTP 200 and the expected service identity, preserved together in the local lab report.
30 Sep 2026 · 10:03:33 UTC
Open the full report ↗

01 / Baseline

The expected service identity and health response establish a baseline for this endpoint at this time.

2026-09-30T10:03:27.6131393Z · Run 8ad211c57849499e9d634471fe812c11

Executed command

Resolve-DnsName localhost -ErrorAction Stop | Select-Object Name,Type,IPAddress | ConvertTo-Json -Compress

Observed output · exit 0

[{"Name":"localhost","Type":28,"IPAddress":"::1"},{"Name":"localhost","Type":1,"IPAddress":"127.0.0.1"}]

Executed command

Test-NetConnection 127.0.0.1 -Port 56119 -InformationLevel Quiet -WarningAction SilentlyContinue

Observed output · exit 0

True

Executed command

curl.exe --noproxy "*" --connect-timeout 3 --max-time 5 -i http://127.0.0.1:56119/health

Observed output · exit 0

HTTP/1.0 200 OK
Server: BaseHTTP/0.6 Python/3.12.14
Date: Wed, 30 Sep 2026 10:03:26 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 54
Cache-Control: no-store

{"service": "support-diagnostics-lab", "status": "ok"}

Read the complete JSON record ↗

02 / Application fault

The port accepts connections, but the service returns HTTP 503. Investigate application health instead of declaring the service healthy from TCP alone.

2026-09-30T10:03:30.7149472Z · Run 94d22a8650bf443fa4629c8634e5d423

Executed command

Resolve-DnsName localhost -ErrorAction Stop | Select-Object Name,Type,IPAddress | ConvertTo-Json -Compress

Observed output · exit 0

[{"Name":"localhost","Type":28,"IPAddress":"::1"},{"Name":"localhost","Type":1,"IPAddress":"127.0.0.1"}]

Executed command

Test-NetConnection 127.0.0.1 -Port 56119 -InformationLevel Quiet -WarningAction SilentlyContinue

Observed output · exit 0

True

Executed command

curl.exe --noproxy "*" --connect-timeout 3 --max-time 5 -i http://127.0.0.1:56119/health

Observed output · exit 0

HTTP/1.0 503 Service Unavailable
Server: BaseHTTP/0.6 Python/3.12.14
Date: Wed, 30 Sep 2026 10:03:30 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 63
Cache-Control: no-store

{"service": "support-diagnostics-lab", "status": "unavailable"}

Read the complete JSON record ↗

03 / Recovery verified

The same endpoint returns HTTP 200 and the expected healthy payload after the injected fault is removed. Repeat checks confirm this recovery.

2026-09-30T10:03:33.8085104Z · Run 253788dc8e2246549cd110d9d7157a60

Executed command

Resolve-DnsName localhost -ErrorAction Stop | Select-Object Name,Type,IPAddress | ConvertTo-Json -Compress

Observed output · exit 0

[{"Name":"localhost","Type":28,"IPAddress":"::1"},{"Name":"localhost","Type":1,"IPAddress":"127.0.0.1"}]

Executed command

Test-NetConnection 127.0.0.1 -Port 56119 -InformationLevel Quiet -WarningAction SilentlyContinue

Observed output · exit 0

True

Executed command

curl.exe --noproxy "*" --connect-timeout 3 --max-time 5 -i http://127.0.0.1:56119/health

Observed output · exit 0

HTTP/1.0 200 OK
Server: BaseHTTP/0.6 Python/3.12.14
Date: Wed, 30 Sep 2026 10:03:33 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 54
Cache-Control: no-store

{"service": "support-diagnostics-lab", "status": "ok"}

Read the complete JSON record ↗

Control / Service stopped

Localhost still resolves, but the TCP connection fails after this fixture is stopped. The automated HTTP stage is skipped; a separate curl probe also fails to connect.

2026-09-30T10:03:44.2730526Z · Run 60de089d7c364dea936e4526a00abbda

Executed command

Resolve-DnsName localhost -ErrorAction Stop | Select-Object Name,Type,IPAddress | ConvertTo-Json -Compress

Observed output · exit 0

[{"Name":"localhost","Type":28,"IPAddress":"::1"},{"Name":"localhost","Type":1,"IPAddress":"127.0.0.1"}]

Executed command

Test-NetConnection 127.0.0.1 -Port 56119 -InformationLevel Quiet -WarningAction SilentlyContinue

Observed output · exit 0

False

Executed command

curl.exe --noproxy "*" --connect-timeout 3 --max-time 5 -i http://127.0.0.1:56119/health

Observed output · exit 7

curl: (7) Failed to connect to 127.0.0.1:56119 after 2052 ms: Could not connect to server

Read the complete JSON record ↗

Control / Name resolution

The reserved test name is not found. The automated checker does not attempt dependent TCP or HTTP checks.

2026-09-30T10:03:45.2317969Z · Run 48cbc7224f65443dba67f4390664d0db

This control was run through the bounded PowerShell checker. Full stage evidence is preserved in the linked record.

Read the complete JSON record ↗

03 / Close the loop

Communication and technical handover

Example wording based on this lab evidence. These messages were not sent to customers or colleagues.

DURING THE INVESTIGATION

Customer update

“The test service is reachable, but its health endpoint is returning an unavailable response. We have isolated the difference between connectivity and application health. Next, we will restore the test service’s healthy mode and repeat the same checks before confirming recovery.”

FOR THE NEXT ENGINEER

Technical handover

Scope: the local fixture at 127.0.0.1:56119. Localhost resolution and TCP connectivity succeeded during HTTP 503. The controlled trigger was the unavailable fixture mode. Restoring healthy mode produced HTTP 200 with the expected service identity and status. Baseline, fault and recovery records are linked above.

Scope & next checks

Localhost resolution does not test an external DNS server. Loopback traffic does not validate a router, WAN, firewall path or physical device.
HTTP 503 alone does not explain the cause of a real incident. Outside this controlled fixture, review service logs, dependencies, configuration and the incident time window.
A failed TCP check narrows the investigation but does not by itself prove hardware failure. A listening port does not prove the correct application is healthy.
Recovery is scoped to the tested endpoint and time. A real service also needs its relevant user journey or transaction checked before closure.
Independent practice, Linux log investigation and applying this method to a real support case remain separate learning steps.

Microsoft: connection testing ↗RFC 9110: HTTP 503 ↗

Project authorship & independent practice

Project provenance. AI-assisted implementation and documentation. At Bilal’s request, the assistant executed and recorded these local experiments. The project is a personal learning artifact; independent hands-on completion by Bilal has not yet been recorded. No employer systems or customer data were used. The test fixture was stopped after capture.

Tracing a service fault.Verifying the recovery.

One endpoint. Three observed states.

Investigation and decisions

Recorded commands and results

The recorded recovery report

Communication and technical handover

Customer update

Technical handover

Tracing a service fault.
Verifying the recovery.