Canonical log lines are Stripe's solution to fragmented logging, emitting one structured record per request with all critical fields like route, user ID, build ID, and error slug. This unified approach replaces piecing together scattered logs, fundamentally changing production debugging. The pattern, detailed in Stripe's blog, structures a request summary row containing fields you always wish you had in one place: route, method, status, duration, user or account ID, request ID, trace ID, build or deploy ID, feature flags, downstream timings, and error code.

Raw examples show how this pre-joins data, allowing queries against complete rows instead of reconstructing requests from fragments. Stripe treats this as critical infrastructure, ensuring the line appears even on failures, and pushes these records into warehouses for deeper analysis beyond just debugging. The real power lies in correlation, enabling questions like 'Did the new build hurt only enterprise accounts?' that metrics alone can't answer due to lost context.

Teams often fail by logging only the happy path or raw paths instead of route templates, and by missing high-value fields like build_id (revealing deploy ownership of regressions) and error_slug (a stable identifier for exact failure sites). While high-cardinality fields like user_id or feature flags raise storage concerns, Stripe argues the cost is manageable within systems designed for filtering and grouping, like Splunk, Redshift, or modern warehouses. Implementation typically uses middleware emitting the event at request end, with OpenTelemetry root spans as a modern alternative.

The core takeaway is that canonical logging transforms logs from breadcrumbs into reliable, queryable records.