When providing feedback in a code review, classify the feedback in three levels:
blocker: The change should not be integrated due to severe defects, such as data loss and interruption of service. A change with too-low test coverage is also a good reason for a blocker, as is a change that would incur too much tech debt.
recommendation: The change contains a problem that should not block integration, but would best be addressed soon after. Recommendations are typically refactorings.
nitpick: The change contains a small problem (based on the reviewer’s opinion) that should not block integration, and might not be worth addressing.
This is still relevant during outages, though the definition of a “blocker” could be relaxed, e.g. by removing the test coverage requirement.