# Metrics and ratings reference Understand the terminology used by GitHub to assess the quality of your repository's code. > \[!NOTE] > GitHub Code Quality is currently in public preview and subject to change. > During public preview, Code Quality will not be billed, although Code Quality scans will consume GitHub Actions minutes. This article provides definitions for the metrics and ratings used by Code Quality. You can see the rule-based results for your repository on your ** Security and quality** tab, in the **Standard findings** tab under " Code quality". ## Metric definitions The following table provides definitions for each metric that is reported for your repository. | Metric | Definition | Example findings | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------- | | **Reliability** | Assess whether the code performs its intended function correctly, predictably, and consistently. Reliable code is free from bugs, handles errors safely, and operates as expected under normal and edge-case conditions. | Issues with performance, concurrency, error handling, correctness, API design, accessibility, internationalization, or security | | **Maintainability** | Assess how easy it is to understand, modify, and extend the code over time. Maintainable code follows best practices, avoids unnecessary complexity, and is organized for ease of future changes and collaboration. | Not using best practices, unused/dead code, duplicate code, complexity, logical redundancies, inadequate documentation, dependency issues | ## Severity levels Severity levels are used to indicate the potential impact or urgency of a code quality finding. They help users prioritize remediation efforts and communicate risks to stakeholders. Severity is determined by the rule that detected the issue, following conventions from CodeQL and industry standards. | Severity | Definition | | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | **Error** | Indicates a high-severity issue that is likely to cause bugs, failures, or major maintainability risks. | | **Warning** | Indicates a moderate-severity issue that may impact code quality or reliability, but is not immediately critical. | | **Note** | Indicates a low-severity issue, minor improvement, or recommendation. These findings are useful for ongoing code health and maintainability. | ## Ratings definitions These ratings are used to summarize the overall reliability and maintainability of a repository based on the severity of rule-based results found by CodeQL scans of the full default branch: | Rating | Definition | Criteria (based on findings) | | --------------------- | ------------------------------------------------------------------------------------ | --------------------------------- | | **Excellent** | Codebase demonstrates best practices for reliability and maintainability. | No code quality findings detected | | **Good** | Codebase has low-severity issues or minor improvements are suggested. | ≥1 "Note" level finding | | **Fair** | Codebase has moderate-severity issues that may impact quality, but are not critical. | ≥1 "Warning" level finding | | **Needs Improvement** | Codebase has high-severity issues, including bugs or major maintainability risks. | ≥1 "Error" level finding | ## Further reading * [About GitHub Code Quality](/en/code-security/code-quality/concepts/about-code-quality) * [Interpreting the code quality results for your repository](/en/code-security/code-quality/how-tos/interpret-results)