Skip to main content

Issues and PRs > Merged at

Tom Williams avatar
Written by Tom Williams
Updated over a week ago

Dataset: Issues & Pull Requests

Entity: Pull Request

Field ID: merged_at

Type: Datetime

Description: The datetime at which the pull request was merged. The field will be null for issues and pull requests that have been closed without merge.

Source: App

Transformation logic: N/A

From:

Github (PRs, Issues)

merged_at

Gitlab (PRs, Issues)

merged_at

Bitbucket (PRs)

closed_at when PR state is merged (not closed).

Azure DevOps (PRs, Issues)

closedDate when PR state is merged (not abandoned).

JIRA (Issues)

N/A

ClickUp (Issues)

N/A

Trello (Issues)

N/A

Reporting Use Cases

The Merged At field is a critical timestamp that marks the successful completion and integration of a pull request. It is the definitive "end" point for the entire development lifecycle, making it essential for measuring deployment frequency, calculating lead times, and analyzing team throughput.

  • Filtering by Completion Status: The presence of this timestamp is the primary way to distinguish between work that has been successfully delivered and work that is still in progress or was closed without being merged.

    • Analyze Delivered Work: To measure performance on completed pull requests, create reports using a filter where Merged At is not null.

    • Scope by Time: Focus your analysis on a specific release cycle or time period with a filter like Merged At in the previous quarter.

  • Calculating Lead Time for Changes: merged_at serves as the final endpoint for measuring the overall speed of your development pipeline.

    • DORA Lead Time: The time from the first commit to deployment is a core DORA metric. You can calculate this with the custom formula (merged_at - first_commit_at) / DAY().

    • Merge Time: You can isolate the final step of your pipeline by measuring the time from the last review approval to the merge: (merged_at - review_approved_at) / HOUR(). A high value here can indicate a bottleneck in your CI/CD or release process.

  • Measuring Deployment Frequency: This field is the foundation for tracking your team's throughput.

    • PRs Merged per Month: A column chart with YEAR_MONTH(merged_at) as the dimension and COUNT() as the metric will show you the number of pull requests your team is shipping each month. This is a direct measure of your deployment frequency.

    • Volume of Code Merged: To understand the scale of work being delivered, you can use the same dimension with a metric like SUM(lines_changed) to visualize the total volume of code changes merged over time.

Did this answer your question?