You are here:

Issues Closed

Question: How many issues were closed during a certain period?


Issues are defined as in Issues New. Issues closed are those that changed to state closed during a certain period.

In some cases or some projects, there are other states or tags that could be considered as "closed". For example, in some projects they use the state or the tag "fixed" for stating that the issue is closed, even when it needs some action for formally closing it.

In most issue trackers, closed issues can be reopened after they are closed. Reopening an issue can be considered as opening a new issue, or making void the previous close (see parameters, below).

For example, in GitHub Issues or GitLab Issues, issues closed are issues that were closed during a certain period.


Volume of issues that are dealt with in a project. Closed issues are a proxy for the activity in a project. By counting closed issues related to code in the set of repositories corresponding to a project, you can have an idea of the overall activity in finishing work with issues in that project. Of course, this metric is not the only one that should be used to track volume of coding activity.



  • Count. Total number of closed issues during the period.
  • Ratio. Ratio of closed issues over total number of issues during that period.
  • Reactions. Number of "thumb-ups" or other reactions on issues.


  • Period of time. Start and finish date of the period during which issues are considered. Default: forever.

  • Criteria for source code. Algorithm. Default: all issues are related to source code.
    If we focus on source code, we need a criterion for deciding whether an issue is related to the source code or not. All issues could be included in the metric by altering the default.

  • Reopen as new. Boolean, defining whether reopened issues are considered as new issues. If false, it means the closing event previous to a reopen event should be considered as void. Note: if this parameter is false, the number of closed issues for any period could change in the future, if some of them are reopened.

  • Criteria for closed. Algorithm. Default: having a closing event during the period of interest.


  • By actors (submitter, commenter, closer). Requires merging identities corresponding to the same author.

  • By groups of actors (employer, gender... for each of the actors). Requires actor grouping, and likely, actor merging.


  • Count per time period over time
  • Ratio per time period over time

These could be grouped by applying the filters defined above. These could be represented as bar charts, with time running in the X axis.

Tools Providing the Metric

  • GrimoireLab provides data for computing this metric for GitHub Issues, GitLab issues, Jira, Bugzilla and Redmine. Current dashboards show information based on creation date, that means they show current status of the issues that were created during a time period (e.g. GitHub Issues dashboard, you can see it in action). Nevertheless, it is easy to build a visualization that shows issues based on closing date by following the next steps:

    • Add a sample visualization to any GrimoreLab Kibiter dashboard following these instructions:
    • Create a new Vertical Bar chart.
    • Select the github_issues index.
    • Filter: pull_request is false.
    • Filter: state is closed.
    • Metrics Y-axis: Count Aggregation, # Closed Issues Custom Label.
    • Buckets X-axis: Date Histogram Aggregation, closed_at Field, Weekly Interval (or whatever interval may fit your needs, depending on the whole time range you wish to visualize in the chart), Time Custom Label.
    • Example screenshot:

    GrimoireLab screenshot of metric issues_closed.

Data Collection Strategies

Specific description: GitHub

In the case of GitHub, closed issues are defined as "issues which are closed".

Specific description: GitLab

In the case of GitLab, closed issues are defined as "issues that are closed".

Specific description: Jira

In the case of Jira, closed issues are defined as "issues that change to the closed state".

Specific description: Bugzilla

In the case of Bugzilla, closed issues are defined as "bug reports that change to the closed state".


To edit this metric please submit a Change Request here:

To reference this metric in software or publications please use this stable URL:

The usage and dissemination of health metrics may lead to privacy violations. Organizations may be exposed to risks. These risks may flow from compliance with the GDPR in the EU, with state law in the US, or with other laws. There may also be contractual risks flowing from terms of service for data providers such as GitHub and GitLab. The usage of metrics must be examined for risk and potential data ethics problems. Please see CHAOSS Data Ethics document for additional guidance.

Was this article helpful?
Dislike 0