Dataset: Issues & Pull Requests
Entity: Pull Requests, Issues
Field ID: review_last_approved_at
Type: Datetime
Description: The datetime at which the pull request last met its minimum approval quota from approving reviews. For issues, it is the newest approval timestamp from resolving pull requests.
Source: Calculated from pull request reviews
Transformation logic:
Pull requests: It is the submission datetime of the last review that allowed the pull request to meet its minimum number of approving reviews to be considered approved. This field will be equal to the Review Approved At field the first time the pull request is approved. If the pull request is then rejected and re-approved again, this field will be strictly newer than the Review Approved At field.
The minimum number of approving reviews is a configuration parameter that is usually available in each git project. If none were configured, Keypup considers that the minimum number of approving reviews is 1.
Note that pull requests will not be considered as “approved” while there is aCHANGES_REQUESTEDreview still active, even if the number of approving reviews reaches the minimum number of approving reviews. TheCHANGES_REQUESTEDreview must be discarded or re-requested for review first.Issues: It is the newest “last approved at” datetime across all resolving pull requests. Resolving pull requests are pull requests that reference the issue via auto-closing keywords.
From: |
|
Github (PRs, Issues) | Calculated |
Gitlab (PRs, Issues) | Calculated |
Bitbucket (PRs, Issues) | Calculated |
Azure DevOps (PRs, Issues) | Calculated |
JIRA (Issues) | Calculated |
ClickUp (Issues) | Calculated |
Trello (Issues) | Calculated |
Reporting Use Cases
The Review Last Approved At field is a specialized timestamp that captures the moment of the very last approving review on a pull request. This is distinct from when a PR first meets its minimum approval requirements, making it particularly useful for analyzing multi-stage or final-gate review processes.
Calculating "Final Sign-off Lag": This field's primary use is to measure the time gap between when a pull request meets its minimum approval requirements and when it receives its final, ultimate sign-off.
You can calculate this "final approval lag" with the custom formula
(review_last_approved_at - review_approved_at) / HOUR(). A long duration here often indicates a process with multiple layers of approval (e.g., team lead approval, followed by an architect's final sign-off).
Measuring a More Precise Merge Time: In a multi-tiered review process, this field can provide a more accurate start time for the final merge phase.
The formula
(merged_at - review_last_approved_at) / HOUR()calculates the time from the absolute final approval to the merge, which can help you pinpoint delays in your release pipeline more accurately than usingreview_approved_at.
Filtering for Process Analysis: You can create reports to find pull requests that received approvals long after they were technically ready to merge.
For example, you can identify items where a final sign-off happened much later than the initial approval by comparing review_last_approved_at and
review_approved_atin a list report, which can help you understand and optimize your formal sign-off procedures.