Hugo server shutdown behavior for active preview connections

Short answer

Hugo's hugo server does not document a drain or graceful-shutdown mode. Treat an interrupt signal (SIGINT/Ctrl+C) as immediate termination: in-flight preview requests and long-lived live-reload connections are likely reset without waiting for them to finish. No documented Hugo flag or environment variable configures read, write, idle, or read-header timeouts. For production preview traffic, connection draining and timeout enforcement should be handled by an upstream reverse proxy or load balancer, not by Hugo itself.

Confirmed versus likely behavior

Documented behavior

• The hugo server flag set covers bind address, port, base URL, live reload, and build options.
• No graceful-shutdown, drain, or connection-timeout flag is listed in Hugo's documentation.
• No documented environment variable controls server timeouts.

Likely implementation (requires verification against your build)

• Hugo is expected to use Go's net/http server.
• If Hugo exits on interrupt without calling http.Server.Shutdown, the process teardown closes listener and active connections immediately.
• Even http.Server.Shutdown does not wait for hijacked connections, such as live-reload WebSocket-style sockets, so browser reload state can still be lost on stop.
• Go http.Server zero values mean no timeouts unless Hugo sets them internally; any internal values can change between Hugo releases and embedded Go versions.

Verification steps

1. Run hugo server --help and confirm no timeout, shutdown, or drain flags appear.
2. Run hugo version to record the Hugo release.
3. If Go is installed, run go version -m "$(command -v hugo)" to record the embedded Go build information.
4. Open a preview page, open browser developer tools to the Network or WebSocket panel, then stop Hugo with Ctrl+C and observe whether the live-reload socket closes immediately.

Recommended handling

Do not rely on hugo server to drain connections. Place a reverse proxy or load balancer in front of Hugo for any non-disposable preview traffic. The proxy should own the client connection, enforce request and idle timeouts, and maintain its own drain timeout while Hugo is stopped or restarted. A process manager can send signals and restart Hugo, but it cannot create draining behavior if Hugo exits immediately.

Missing diagnostic detail

Are you running hugo server only for local authoring, or as a public-facing production origin? This determines whether immediate connection termination is acceptable or whether an upstream proxy is required before deployment.