Go deployment ends at log.Fatal without cleanup or stack trace

A Go service that terminates through log.Fatal exits with status 1, skips deferred functions, and produces no automatic stack trace. In a deployment that captures only the exit status and stderr, the final log line can therefore be the last available evidence, while cleanup hooks and any buffered log output may be abandoned.

The goal is to define one termination contract that preserves diagnostic context and cleanup across fatal errors, unrecovered panics, signals, and normal HTTP server shutdown. This assumes maintained Go 1.x releases using the standard log and net/http packages; deployment-specific log capture and logger configuration require confirmation.

Normal shutdown also needs careful classification: http.ErrServerClosed can be returned by Server.Serve after a graceful shutdown and is not itself an operational failure.

• Should cleanup and exit-status mapping be centralized outside log.Fatal, and where should that responsibility live?
• Which stderr fields and exit codes should distinguish a fatal error, panic, signal, and graceful shutdown?
• What local verification should compare exit status, stderr content, deferred cleanup, and stack-trace presence across those paths?