Fast review and careful review are not opposites. Google's published guidance sets one business day as the maximum time to respond to a review request, says speed must never cost quality, and suggests faster reviews follow from better changes. Here is how to apply it when some of the changes are security sensitive.
What the guidance says
Google's page on review speed argues the team's overall speed matters more than an individual's coding speed. Slow reviews frustrate developers, which often shows up as complaints that a reviewer is strict, and pressure teams to accept weaker code.
Key rules from the page:
- Respond within one business day at most, ideally much sooner.
- Response time matters more than the time a full review takes.
- Do not break your own focus to review. Respond at a natural break.
- Speed should never come at the cost of review standards.
Quick does not mean shallow
A fast reply can be a timeline, a pointer to a quicker reviewer, or broad first comments. The page lists those as acceptable when you are too busy for a full review.
For security sensitive changes, answer fast with "I will review this properly by Thursday, it touches auth." That keeps the author unblocked on other work without a rubber stamp.
LGTM with comments
The guide allows approving while leaving unresolved comments when the author will reliably address them, the comments are optional, or they are minor, such as a typo. It says to state which applies. For security, use this only for minor items. A blocker means no approval.
Time zones
The guide says to respond while the author is still working, or finish the review before their next workday. For a distributed team, this is the difference between a one day and a three day cycle.
What speeds reviews up legitimately
- Small changes. See why small pull requests help.
- Automated checks in CI so humans do not repeat them.
- Owners assigned by path, so the right person is asked first.
- Clear descriptions. See what reviewers need in a description.
Large changes: the guide advises asking for a split, or giving design feedback first.
What to measure
Track time to first response, not time to merge. The first one is what the guide treats as important, and it is easy to improve with a rota.
A free scan of your dependencies is available at gold.safeguard.sh/scan.
A simple rota
If reviews pile up, try a daily rota. One person each day is first responder for new review requests and either reviews, redirects to the right owner, or gives a time. It spreads the load and makes the one business day target realistic.
Security owners can have their own rota for flagged pull requests, so a request does not wait for one busy specialist.
Quick check
Should security reviews have a longer deadline?
They can, as long as the first response is quick and states when the full review will happen. Silence is the problem, not depth.
Sources
Last reviewed: 19 October 2026.
