Skip to main content

Issues and PRs > Resolved Issue first closed at

Tom Williams avatar
Written by Tom Williams
Updated this week

Dataset: Issues & Pull Requests

Entity: Pull Requests

Field ID: resolved_issue_first_closed_at

Type: Datetime

Description: The earliest closure date among all resolved issues (via auto-closing keywords).

Source: Calculated

Transformation logic:

  • Pull Requests: The earliest occurrence of all closed_at fields from resolved issues. The null values are ignored. A null value is returned only if all closed_at values are null. Resolved issues are issues that are referenced by a resolving pull request.

  • Issues: Not applicable. This field will always be null.

From:

Github (PRs, Issues)

Calculated

Gitlab (PRs, Issues)

Calculated

Bitbucket (PRs)

Calculated

Azure DevOps (PRs, Issues)

Calculated

JIRA (Issues)

N/A

ClickUp (Issues)

N/A

Trello (Issues)

N/A

Reporting Use Cases

The Resolved Issue First Closed At field is a specialized timestamp that captures the completion date of the earliest closed issue resolved by a pull request. It is particularly useful for auditing your workflow and analyzing the time lag between when work is considered complete in project management and when the corresponding code is actually merged.

  • Filtering for Historical Context: You can create reports that focus on pull requests that have resolved very old or long-running issues.

    • To identify recently merged work that cleared out old technical debt, you could use a filter like Resolved Issue First Closed At before 1 year ago, combined with a filter on the merge date.

  • Measuring the "Completion-to-Merge Gap": This field allows you to measure the time between an issue being marked as 'done' and the final code being integrated.

    • You can calculate this gap with the custom formula (merged_at - resolved_issue_first_closed_at) / DAY(). A high average for this metric might indicate that issues are being closed prematurely in your project management tool, or that there are significant delays in your deployment pipeline after the initial work is marked as complete.

  • Auditing Workflow Compliance: You can use this field to verify if your team is following the desired process for closing issues relative to merging code.

    • For example, if your process dictates that issues should only be closed after a PR is merged, you can identify non-compliant instances. A custom dimension with the formula IF(resolved_issue_first_closed_at < merged_at, "Issue Closed Before Merge", "OK") will flag every pull request where at least one issue was closed too early.

Did this answer your question?