The Scorecard plugin collects metrics from third-party data sources using metric providers.

The Scorecard node plugin provides the scorecardMetricsExtensionPoint extension point that is used to connect your backend plugin module that exports custom metrics via metric providers to the Scorecard backend plugin.

The following metric providers are available:

You must manually install and enable the plugin in your Red Hat Developer Hub instance.

As an administrator, you can secure the connection to your metric providers by managing user access to the Scorecards using the Role-Based Access Control (RBAC) permissions. For users to view the Scorecard metrics, you must grant users with read access to the Scorecard metrics. You can configure these permissions either by modifying your RBAC CSV file directly or by using the RBAC Web UI.

To achieve enhanced visibility and control over your software components, you must configure the GitHub Scorecards plugin to integrate GitHub metrics directly into your RHDH catalog. This allows engineering teams to centralize development data, quickly identify risks, and accelerate decision-making related to component health and security.

To enable the GitHub metrics integration, you must create and configure a GitHub App to grant RHDH access to the GitHub API.

To bring critical project tracking and workflow data from Atlassian Jira directly into your RHDH instance, you must configure the Jira Scorecards plugin. This integration provides engineering teams with a centralized view of development status and reduces context switching, enabling faster assessment of component readiness and delivery velocity.

The following Jira versions are supported:

For more information about how to customize the threshold values, see Thresholds in Scorecard plugins.

A threshold defines a condition or an expression that determines which visual category a metric value belongs to.

Threshold expressions are highly flexible and support standard mathematical and logical operators based on the data type of the metric.

Thresholds are merged based on a strict priority order, allowing you to set defaults while granting specific entities the ability to override rules.

To override the default thresholds set by a metric provider, you must update your RHDH app-config.yaml file under the configuration path of the specific metric.

The custom configuration completely replaces the provider’s defaults. If you omit a threshold category (such as success), that category is not assigned.

The following configuration defines a success threshold as 10 or fewer issues, which applies to all components using the jira.open_issues metric unless explicitly overridden by an entity annotation.

scorecard:
  plugins:
    jira:
      open_issues:
        thresholds:
          rules:
            - key: success
              expression: '<10'    # fewer than 10 open issues is Success
            - key: warning
              expression: '10-50'    # Between 10 and 50 is a Warning
            - key: error
              expression: '>50'      # More than 50 open issues is an Error

You can override individual threshold rules for a specific component by using annotations in its catalog-info.yaml file. These annotations are merged with the existing global rules defined in your RHDH app-config.yaml file.

# catalog-info.yaml
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: critical-production-service
  annotations:
    # Overrides the global 'warning' rule (e.g., changing '11-50' to '10-15')
    scorecard.io/jira.open_issues.thresholds.rules.warning: '10-15'
    # Overrides the global 'error' rule (e.g., changing '>50' to '>15')
    scorecard.io/jira.open_issues.thresholds.rules.error: '>15'
    # The 'success' rule (<10) remains defined by the global app-config
spec:
  type: service

Threshold rule evaluation is order-dependent. You must follow logical ordering to avoid unintended category assignments, as the system stops evaluation once a value matches the first rule.

# Correct Example: Order from most restrictive (Success) to least restrictive (Error)
rules:
  - key: success
    expression: '<10'     # Only values below 10
  - key: warning
    expression: '10-50'   # Only values between 10 and 50
  - key: error
    expression: '>50'     # All remaining values above 50