A 200 OK Health Check Hid the Wrong Process Running Behind the Port

A developer spent 48 hours debugging an HTTP app that consistently returned a passing health check, only to discover the checker was hitting a stale, forgotten process rather than the intended server. The core issue was that 'localhost' resolved to an old listener left over from a previous session, which politely returned HTTP 200 responses while the real application was never actually reached. Because the smoke test only verified that something answered the port — not which process answered it — the green status code masked the underlying failure entirely. The problem was compounded by Python's HTTPServer enabling address reuse by default, meaning a successful port bind does not guarantee exclusive ownership. The fix required printing sys.executable, os.getpid(), and a controlled response header to confirm process identity, a step the author recommends running in the very first hour of debugging.