Review changes
Read pull request reports
Interpret the Impact Gate check, contract changes, consumer evidence, and coverage notes.
On this page
When analysis runs#
Impact Gate analyzes open pull requests in selected repositories with an active installation and usable repository index. Opening, reopening, updating the head, or marking a PR ready for review can queue analysis. Draft pull requests are included.
The App also checks eligible repositories for missed open-PR events. This recovery runs periodically and can recover a PR opened before delivery was active. Several selected repositories may be scanned over multiple batches; it is not an instant delivery guarantee.
The report is tied to the PR's exact base and head commits. A later commit supersedes old work. If comments are enabled, the App updates its existing report for the PR instead of adding a new comment for every commit.
Find the check and report#
Open the PR in GitHub
Find the Impact Gate check in the PR's checks. It starts in progress while analysis is running.
Read the report comment
In the PR conversation, find the App's Impact Gate comment. Comments are controlled by Publish findings as pull request comments in Settings.
Confirm the analyzed head
Compare Analyzed PR head at the end of the report with the latest PR commit. Open the updated report after pushing additional changes.
Follow the dashboard link
Open the check's details to review the connected dashboard. Sign in with an account that has access to this workspace.
Read the sections in order#
| Section | What to check |
|---|---|
| Title and Assessment Summary | The overall assessment and the reasons behind it. Analysis incomplete means the report has coverage limitations. |
| Static evidence | How many indexed call-site references were loaded for changed endpoints. This is not a count of all production callers. |
| Breaking Changes Detected | The HTTP endpoint, change kind, field or location, and before/after contract values. |
| Consumer Impact Analysis | The consumer, verdict, source location, and explanation. Expand any evidence chain when available. |
| Suggested Backward-Compatible Alternatives | Options for preserving compatibility while planning a migration. |
| Analyzed PR head | The immutable head commit represented by the report. |
Tiers, verdicts, and check conclusions#
| Report tier | Interpretation |
|---|---|
| High | A verified affected consumer has high or critical importance in the assessment. |
| Medium | A consumer is affected, or unresolved consumer impact or coverage requires review. |
| Low | A breaking contract change was found without confirmed affected consumers in the available evidence. |
| None | No breaking change was detected in the analyzed supported contract scope. |
When analysis is incomplete, its title emphasizes that state rather than presenting an overall risk tier. Individual dashboard findings can still carry a risk label so that coverage gaps and potential impacts remain visible.
| Consumer result | Meaning |
|---|---|
| verified / affected | The inspected evidence establishes use of the changed interface within the analysis scope. |
| possible / cannot_tell | The relationship or impact is plausible, but the available evidence cannot establish it. |
| not_affected | The inspected consumer handling did not show the specific detected impact; the conclusion is limited to that analysis. |
| observed caller, code not analyzed | A caller reference was available, but its code impact was not analyzed completely. |
A GitHub success conclusion means the supported analysis completed. Neutral is used when coverage is incomplete, analysis is unavailable, or work was superseded. Reports are advisory; these conclusions are not a compatibility certification. Repository owners remain responsible for branch protection configuration.
Act on a finding#
Read the contract difference
Check that the reported endpoint and field match the intended change. Follow the provider source reference at the recorded commit.
Inspect the consumer
Open the linked consumer source and verify the call and field handling with that service's owner. Path-based relationships can remain possible when deployment host association is unverified.
Choose a migration approach
Consider retaining a field during migration, adding a versioned endpoint, or coordinating consumer updates. Suggested alternatives are starting points for review.
Push the revision
Update code and contract together. Wait for analysis at the new head, then compare the revised evidence and remaining coverage gaps.