Rails production logging limits for failed deployments

Rails routes post-boot controller, routing, and ActiveRecord events through Rails.logger and ActiveSupport log subscribers, but exceptions raised while initializers run can be printed by the boot process or app server to stderr and never reach the configured log destination. In production, the generated template typically sets config.log_level to :info, suppressing debug detail such as SQL statements, and request IDs appear in log lines only when config.log_tags includes :request_id. These defaults create a gap when a deployment fails before or during initialization: log/production.log can be incomplete, and the least verbose settings that reduce PII exposure can also remove the evidence needed to reconstruct it.

The unresolved decision is operational rather than a missing API: choose the least verbose production log level and tag set that still lets you diagnose a failed deploy, accepting the PII/volume tradeoff. Because generated defaults vary by Rails version and template, the effective values in a deployed application may differ from documentation examples.

Which documented configuration boundaries determine whether a failed deploy is observable in log/production.log versus only in server stderr? What is the expected behavior for config.log_level and config.log_tags when an initializer raises before the logger is fully configured? How can request IDs correlate across a failed deploy when tagged logging is enabled but the boot process may not emit Rails log lines?