Impact GateDocs

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#

  1. Open the PR in GitHub

    Find the Impact Gate check in the PR's checks. It starts in progress while analysis is running.

  2. 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.

  3. 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.

  4. 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.

An example report from an Impact Gate lab repository. Findings depend on the changed contract and the consumers indexed in your workspace.

Read the sections in order#

SectionWhat to check
Title and Assessment SummaryThe overall assessment and the reasons behind it. Analysis incomplete means the report has coverage limitations.
Static evidenceHow many indexed call-site references were loaded for changed endpoints. This is not a count of all production callers.
Breaking Changes DetectedThe HTTP endpoint, change kind, field or location, and before/after contract values.
Consumer Impact AnalysisThe consumer, verdict, source location, and explanation. Expand any evidence chain when available.
Suggested Backward-Compatible AlternativesOptions for preserving compatibility while planning a migration.
Analyzed PR headThe immutable head commit represented by the report.

Tiers, verdicts, and check conclusions#

Report tierInterpretation
HighA verified affected consumer has high or critical importance in the assessment.
MediumA consumer is affected, or unresolved consumer impact or coverage requires review.
LowA breaking contract change was found without confirmed affected consumers in the available evidence.
NoneNo 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.

An evidence chain can show a contract, call site, and field read while impact remains possible because the deployment host association is unresolved.
Consumer resultMeaning
verified / affectedThe inspected evidence establishes use of the changed interface within the analysis scope.
possible / cannot_tellThe relationship or impact is plausible, but the available evidence cannot establish it.
not_affectedThe inspected consumer handling did not show the specific detected impact; the conclusion is limited to that analysis.
observed caller, code not analyzedA 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#

  1. Read the contract difference

    Check that the reported endpoint and field match the intended change. Follow the provider source reference at the recorded commit.

  2. 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.

  3. 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.

  4. Push the revision

    Update code and contract together. Wait for analysis at the new head, then compare the revised evidence and remaining coverage gaps.

Explore the documentation

↑↓ NavigateEnter Open guideSearch stays in your browser