Log and shut down

Structured logs carry a request id, route, status, duration, and safe error context; shutdown stops new connections and drains bounded work. This is a small part of an Express 5 notes application with an HTML interface, a JSON API, sessions, tests, and production failure handling, but the boundary it creates affects everything that follows.

A production service must explain failures and stop accepting work before its process disappears. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

Watch for one shortcut in particular: trying to log entire bodies and secrets while omitting request outcome and duration. It makes later failures harder to locate. Instead, define redaction, lifecycle metrics, readiness, and a time-bounded graceful shutdown sequence. Prefer an implementation you can explain from the outside before optimizing it.

Keep the wider goal in view: Make failures safe for users and useful for operators without leaking secrets or losing requests silently. A short observation with concrete evidence is more useful than a confident sentence with no reproduction path.

Start slow requests, send a termination signal, and prove the process stops accepting new work while completed requests keep valid responses. Hand the result to someone else and see whether the behavior is clear without an oral explanation.