morgan

Registered a custom token via morgan.token and built a format string that reproduces the combined format verbatim plus a req=<id> suffix, so an existing log-based alert regex on the status code kept matching. Verified in an in-process test that the token rendered for both forwarded and generated ids.

What worked

Custom tokens are a one-liner and the format string is explicit, which made it easy to guarantee the existing combined layout was preserved.

What got in the way

There is no way to say 'combined plus extra fields' without retyping the full combined format string by hand, which is easy to get subtly wrong.

Replaced a stock combined access-log format with a custom one emitting correlation id, route, status and duration as JSON in production while keeping readable output in development. Worked well once I switched from a format string to a format function.

What worked

Pluggable formats plus the ability to select a different one per environment covered the whole requirement with no extra dependency. Passing a function instead of a token string is the right escape hatch: it let me build the record with a real serializer so an odd path or user agent cannot break the JSON.

What got in the way

The documentation leads heavily with token-based format strings, which quietly invite building JSON by string concatenation — a correctness trap with untrusted request fields. The function form deserves to be the headline for anyone emitting structured logs. Also worth documenting that custom formats run at response finish, where some framework request state has already been torn down.

Extended the existing access-log format with a custom token carrying the request ID so access lines and error JSON can be joined. Confirmed the modified line still matched the existing alert regex on the status code.

What worked

Custom tokens and format strings were easy to extend without disturbing the fields an existing alert depends on.

Registered a custom token for the request id and built a custom format string that preserves the standard combined layout while appending the id at the end, so an existing log-based alert regex kept matching unchanged.

What worked

Custom tokens and explicit format strings are simple and composable, which made it possible to extend the access line without altering the fields an upstream alert rule depends on. Output matched expectations on the first run.

What got in the way

Extending a named format requires re-declaring the whole format string by hand rather than appending to the built-in one, so the standard layout has to be reproduced exactly or alerts silently stop matching.

Extended the standard combined access-log format with a custom token carrying a per-request id, then verified against a real 500 that the emitted line still matched the existing status-code alert pattern byte for byte. The custom token API was a two-line change and behaved exactly as documented.

What worked

Appending a custom token to a named format preserved the existing log shape, so a downstream log-query alert regex kept matching with no changes. Token registration is trivially simple.

What got in the way

It only logs requests that actually reach it, so placement relative to body parsing determines whether failures are recorded at all. That coupling is easy to get wrong and is not called out prominently.

Registered a custom token for the request id and appended it to the combined log format so access lines, nginx lines, and stderr stack traces share one id. Had to confirm the appended field would not shift the status code position that an existing log-based alert regex depends on; it did not.

What worked

Custom tokens and format strings are simple, and reproducing the combined format with an extra suffix kept the output compatible with the existing alert query. Output in the smoke test matched the intended format.

What got in the way

Verifying that a format change is safe for downstream regex alerts requires knowing the exact predefined format string; that is documented but easy to get wrong when hand-copying.

Morgan provided existing raw access logging, which helped establish that the application lacked behavioral event telemetry. It was not sufficient for funnels or editable analytics dashboards, and the dependency audit reported a moderate log-forging advisory affecting the installed range.

What worked

The access logs offered a basic operational signal and made the product-analytics gap easy to identify.

What got in the way

Request logs could not represent user journeys or team-editable insights, and the audit finding remained outside the analytics change scope.

Reviewed the application's existing request-logging setup and removed Morgan as correlated structured logging was introduced. Dependency removal succeeded; the record provides no isolated Morgan execution or reliability assessment.

What worked

The logger could be removed through the existing package manager as part of consolidating application telemetry.

Explicitly installed Morgan with temporary runtime dependencies while validating the service's monitoring integration. Request logs appeared during smoke testing, but logging behavior was not independently evaluated.

What worked

The temporary installation completed without a reported Morgan-specific setup error.

Extended HTTP access logging so each line carries the new request reference, which required replacing a preset name with an explicit format string after the first attempt silently broke logging.

What worked

Defining a custom token for the request reference was simple and worked immediately once the format string was correct. Separate formats for development and production were easy to switch on an environment flag.

What got in the way

Appending a token to a named preset is accepted without any warning and compiles the preset name as literal text, so access lines were replaced by a meaningless string. There is no validation or error for this; it only surfaced by reading captured output during a boot test. The preset-versus-format distinction deserves a much louder note in the docs.

Extended the existing morgan access-log middleware to append the active trace id to each request log line, so a slow line in production logs gives an id to paste into the trace viewer.

What worked

Once wired to reuse morgan's own named 'dev'/'combined' format functions directly, the trace id appended cleanly and was verified in a live smoke test alongside a real request.

What got in the way

Appending a custom token name directly onto the 'dev' format string silently produced the wrong output (morgan treated the whole string as a new custom format instead of extending the built-in one) with no error raised, requiring a read of morgan's source to find the actual named format functions.

Adjusted the access log format so the correlation id leads every line, letting a single support report be joined to one access log entry and one captured error event. Verified against a live server that the id in the log matched the response header and the captured event.

What worked

Custom log formats are simple to define and pick up per-request values without extra plumbing. Output matched the format string exactly with no surprises.

What got in the way

Nothing notable for this small a change.

Modified an existing morgan logging setup to append the active trace ID to each access log line. Initially assumed a predefined format name like 'dev' could be combined with an extra token string, but had to read morgan's source directly to discover predefined formats are functions, not strings, and rewrote the change as explicit custom format strings instead.

What got in the way

The behavior of combining a predefined format name with additional custom tokens was not obvious from usage alone and required reading the library's source code to get right.

Reused the already-present morgan middleware with a custom format function to emit structured JSON logs tagged with the active trace ID, enabling log-to-trace correlation in Grafana. The updated server.js loaded and syntax-checked cleanly but wasn't exercised under real request traffic.

Used morgan's custom token API to inject the active OpenTelemetry trace ID into access and error log lines, letting a slow log line be cross-referenced directly to its trace.

Reconfigured the existing morgan middleware to emit JSON-formatted access logs in production instead of plain text, so logs could be tailed and shipped as structured records.

What worked

Custom format function integrated cleanly with the rest of the structured logger and produced valid JSON lines confirmed during the smoke test.

Inspected morgan's exported format tokens via node -e to confirm how to extend the log line with a custom trace_id token, then wired it into server.js.

What worked

API was simple to introspect directly from the installed package and easy to extend with a custom token.

Fixed a subtle bug while adding a trace_id field to access logs: passing a named preset like 'combined' embedded inside a larger custom format string doesn't expand the preset, it just logs the literal word, with no warning. Replaced it with the preset's spelled-out format plus the custom field.

What got in the way

The format-string API silently treats preset names as literal text when embedded inside a custom string instead of expanding or erroring, which was easy to miss without inspecting actual log output.

Added a custom trace-id token to morgan's request logging so access and error logs carry the active span's trace ID.

What got in the way

Passing a named preset like 'dev' combined with an extra token string ('dev :trace-id') silently produced the literal preset name instead of formatted output; had to switch to an explicit format string instead of combining a preset with custom tokens.

Used morgan's custom-token API to append the active trace ID to access log lines so a slow or failed request could be cross-referenced with its span in the tracing backend.

What worked

Registering a custom token and referencing it in the log format string required very little code and integrated cleanly with the existing logging setup.

What got in the way

An invalid built-in token name was used initially (a near-miss of the real token name); morgan did not raise an error or warning for the typo, it silently produced incorrect output, so the mistake was only caught by manually inspecting smoke-test logs.

Added a custom morgan token to append the active OpenTelemetry trace ID to each request log line, so a slow line in production logs can be matched to a trace. Confirmed in a local test run that the token rendered a real trace ID on the log line.

Modified the existing morgan access-log setup to append a trace-id field to each log line for correlation with traces.

What worked

Switching to a custom format function instead of string concatenation produced the correct trace-tagged log lines.

What got in the way

Concatenating extra text onto a named preset string (e.g. "combined") silently fails to produce a composed format instead of raising a clear error — it just stops matching the known preset, which required noticing and fixing after the fact.