Metrics for issues, pull requests, and discussions

Turning repository activity into measurable data

GitHub has released the Issue Metrics GitHub Action, a tool for tracking the health and progress of issues, pull requests, and discussions. The action computes metrics for a specified time period, including time to first response and time to close, and produces a report like the one below.

It is designed to fit into an existing GitHub Actions workflow or run as a standalone workflow on whatever cadence suits the team.

Who benefits from the metrics

Maintainers tracking workload and gaps

Maintainers can use the action to measure open and closed issues alongside open and merged pull requests. Those numbers offer a view of project workload across a week, month, or year, making it easier to spot requests that have been overlooked and adjust how time is assigned.

First responders staying responsive

For those responsible for timely user contact, the action can report on discussions awaiting replies, unresolved issues, and pull requests waiting on reviews. This supports building a to-do list or retrospectively reviewing how long users waited for a response during any chosen period.

OSPOs accelerating the release process

Open Source Program Offices can use the action to track the volume of employee requests and the open-to-closed ratio, along with the time required to move through the open-source process. Those insights can reveal bottlenecks in the pipeline and help streamline the workflow so employees are more likely to continue contributing projects on behalf of the organization.

Product teams improving review cycles

Teams that depend on code review can measure how long pull requests take to get reviewed and reflect on that data during retrospectives. Identifying where reviews stall allows teams to refine their review process and shorten development cycles.

Setup and customization

Configuration can be completed in minutes, versus manual calculation which takes hours, and only needs to be done once. The action then runs on a schedule chosen by the user using GitHub's search filter syntax to determine which items are included in the report.

Example workflows that have already been tested internally at GitHub are available in the repository. The following example runs monthly and reports on issues created during the previous month:

name: Monthly issue metrics
on:
  workflow_dispatch:
  schedule:
    - cron: '3 2 1 * *'

jobs:
  build:
    name: issue metrics
    runs-on: ubuntu-latest

    steps:

    - name: Get dates for last month
      shell: bash
      run: |
        # Get the current date
        current_date=$(date +'%Y-%m-%d')

        # Calculate the previous month
        previous_date=$(date -d "$current_date -1 month" +'%Y-%m-%d')

        # Extract the year and month from the previous date
        previous_year=$(date -d "$previous_date" +'%Y')
        previous_month=$(date -d "$previous_date" +'%m')

        # Calculate the first day of the previous month
        first_day=$(date -d "$previous_year-$previous_month-01" +'%Y-%m-%d')

        # Calculate the last day of the previous month
        last_day=$(date -d "$first_day +1 month -1 day" +'%Y-%m-%d')

        echo "$first_day..$last_day"
        echo "last_month=$first_day..$last_day" >> "$GITHUB_ENV"

    - name: Run issue-metrics tool
      uses: github/issue-metrics@v2
      env:
        GH_TOKEN: ${{ secrets.GH_TOKEN }}
        SEARCH_QUERY: 'repo:owner/repo is:issue created:${{ env.last_month }} -reason:"not planned"'

    - name: Create issue
      uses: peter-evans/create-issue-from-file@v4
      with:
        title: Monthly issue metrics report
        content-filepath: ./issue_metrics.md
        assignees: <YOUR_GITHUB_HANDLE_HERE>

For full documentation and setup instructions, see the Issue Metrics GitHub Action repository.