Speed Matters as Much as Quality
A technically perfect review that arrives three days late is a bad review. Slow reviews create context-switching costs (the author has moved on to something else), merge conflicts (the codebase has changed), and frustration (the author feels blocked and undervalued).
The Standard
Most high-performing engineering teams target a first response within one business day. This does not mean the review must be complete — it means the reviewer acknowledges the PR, gives an estimated timeline, or asks clarifying questions. Silence is the worst outcome.
Google's engineering guidelines explicitly state that reviewers should respond to review requests within one business day. Teams that adopt this norm see PR cycle times drop dramatically.
Batching Reviews
Rather than context-switching into code review every time a Slack notification arrives, experienced engineers batch their reviews. Two dedicated 30-minute review sessions per day (e.g., morning and after lunch) are more effective than ten 3-minute interruptions. This protects deep work time while still meeting the one-day response norm.
When You Are the Bottleneck
If you are the sole reviewer on a PR and you are going to be unavailable (vacation, incident response, deep project work), say so explicitly and suggest an alternative reviewer. Leaving a PR in limbo without communication is a team failure, not just a personal one.