> For the complete documentation index, see [llms.txt](https://docs.snyk.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.snyk.io/scan-fix-and-prevent/fix/snyk-pull-or-merge-requests/breakability-risk-levels.md). # Breakability risk levels {% hint style="info" %} **Feature availability** Breakability analysis is available only with Enterprise plans. For more information, see [plans and pricing](https://snyk.io/plans/). {% endhint %} Snyk analyzes dependency upgrades to predict if a proposed change will break your build or application. Breakability analysis assigns a risk level to each upgrade to help you decide whether to auto-merge a fix or review it manually. Snyk assesses the practical impact of a change rather than relying only on version numbers. For example, a major version update (v2.0) can appear risky based on the version number, even if the code change is trivial. To determine risk levels, Snyk uses official release notes, change logs, and ecosystem data. This page outlines the logic and definitions Snyk uses to classify upgrades. Snyk classifies risk based on two factors: * Evidence: what the maintainers of the system say has changed in the system. * Confidence: how certain Snyk is about that evidence. {% hint style="info" %} With breakability analysis, Snyk sends package information to a Large Language Model (LLM). This information includes the current and proposed upgrade versions. Snyk does not transmit application data. Future features involving application context require you to enable them separately. Ensure to review AI-generated content for accuracy before use. {% endhint %} ## How breakability appears in pull requests When Snyk opens a pull request for a dependency upgrade, breakability analysis is surfaced in two places: * **Pull request description**: the PR description includes the breakability risk level so you can assess the upgrade at a glance. * **Pull request comment**: Snyk also posts a comment on the newly opened PR with the risk level and a more detailed summary. This comment may appear shortly after the PR is created. The summary explains relevant details about the risk, such as which breaking changes may be included in the upgrade. ## Provide feedback on breakability analysis You can help improve breakability analysis by reacting to the breakability comment on your pull request. Add a 👍 or 👎 reaction to indicate whether the assessment was helpful. Snyk uses this feedback to improve the quality of future breakability analysis. ## Risk level definitions and actions ### Low risk Based on standard usage patterns, Snyk believes this upgrade is unlikely to introduce breaking changes. {% hint style="info" %} You can most likely auto-merge or approve low-risk PRs. {% endhint %} Criteria for low risk assessment include: * Explicit non-breaking evidence: Snyk retrieved release notes and verified they contain only bug fixes, security patches, or performance improvements. * Minimal practical impact: the upgrade is a major version, but only drops support for an element that has been End-of-Life (EOL) for several years. * Patch or minor upgrades: semantic versioning suggests compatibility, and the change log shows no anomalies. ### Medium risk (review recommended) The upgrade is likely safe, but requires developer validation due to uncertainty or specific environmental constraints. {% hint style="warning" %} Do not auto-merge medium risk PRs. Review the release notes or run your test suite to confirm compatibility. {% endhint %} Criteria for medium-risk assessment include: * Low confidence or missing data: official release notes or change logs are missing or are unparsable. Without evidence, Snyk defaults to caution. * Environment flags: The upgrade drops support for an element recently EOL or still in wide use. You must verify deployment environment compatibility. * Ambiguous changes: The change log mentions behavioral changes that are not strictly breaking, but have the potential to affect edge-case implementations. ### High risk (action required) Snyk confirms or suspects that the upgrade introduces breaking changes that require code refactoring. {% hint style="danger" %} Do not merge a high risk PR without code changes and thorough testing. Snyk recommends treating it as a development task. {% endhint %} Criteria for high-risk assessment include: * Confirmed API changes: release notes explicitly detail the removal or renaming of functions, classes, or methods used in standard implementations. * Configuration changes: the upgrade requires changes to config files, middleware ordering, or build pipelines. * Major runtime shifts: The package drops support for an active Long Term Support (LTS) runtime version. ## End-of-Life (EOL) threshold Major version upgrades often occur because a maintainer stops supporting an old language version. Snyk evaluates this as: * Low impact: if a package drops support for a runtime that has been EOL for more than two years. Snyk classifies this as low risk. Snyk assumes secure enterprise environments have migrated away from these legacy versions. * High impact: if a package drops support for a runtime that is current, LTS, or recently EOL. Snyk classifies this as high risk because it can break CI/CD pipelines that have not been upgraded. ## Deprecations and removals * Deprecations: in case of deprecations, a feature is marked as deprecated, but still functions in the code. Snyk considers this to be low risk. * Removals: if a deprecated feature is removed from the codebase, Snyk considers this high risk. ## Examples The following use cases show how the logic applies. | Use case | Version upgrade | Snyk risk assessment | Rationale | | ---------------------- | ----------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | Security patch | From `1.4.4` to `1.4.5` | Low | The changelog confirms only security fixes and no behavioral changes. | | Ancient runtime drop | From `3.0` to `4.0` | Low | The upgrade is a major version, but the only change is dropping Node.js v4 (EOL 2018). There is no practical impact. | | Missing documentation | From `2.1` to `2.2` | Medium | The upgrade is a minor version, but there is no changelog. Snyk cannot detemine if it is safe, so it flags it for review. | | API removal | From `3.0` to `4.0` | High | The changelog confirms that `_.pluck` was removed and must be replaced with `_.map`. Code changes are required. | | Long term support drop | From `5.0` to `6.0` | High | The upgrade drops support for Java 17, which is an active LTS. This upgrade breaks builds that are running on standard environments. | | | | | | ## Using breakability risk with Snyk Broker The breakability risk level in the pull request description does not require additional broker configuration. To receive the detailed breakability comment, your broker configuration must include the rule for creating pull request comments. If you use the [official broker templates](https://github.com/snyk/broker/tree/master/client-templates), this rule is already included. Ensure your `accept.json` is up-to-date with the latest template for your SCM platform. If you maintain a custom `accept.json` configuration, ensure that it includes the appropriate rule for your SCM: * GitHub or GHE: `POST /repos/:name/:repo/issues/:issueNumber/comments` * GitLab: `POST /api/v4/projects/:project/merge_requests/:pullRef/notes` * Azure Repos: `POST /:owner/_apis/git/repositories/:repo/pullRequests/:pullRef/threads` * Bitbucket Server: `POST /rest/api/1.0/projects/:project/repos/:repo/pull-requests/:pullRequestId/comments` If the rule is missing, Snyk still opens the pull request with the breakability risk level in the description, but fails to post the comment containing the detailed breakability analysis. For configuration details, visit [Snyk Broker](/platform-administration/snyk-broker/snyk-broker.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.snyk.io/scan-fix-and-prevent/fix/snyk-pull-or-merge-requests/breakability-risk-levels.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.