> ## Documentation Index
> Fetch the complete documentation index at: https://docs.opslane.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Results: Screenshots, Video, and GitHub Status Checks

> Learn what Opslane posts to your pull request after a browser run — pass/fail verdict, screenshots, full session video, and how merge blocking works.

After every browser run, Opslane posts a structured comment directly on your pull request and updates the GitHub status check. You get a complete picture of what was tested, what passed, and exactly what went wrong — all without leaving GitHub.

## The PR comment

When a run finishes, Opslane adds a comment to the PR that contains everything you need to evaluate the result at a glance.

<Steps>
  <Step title="Pass/fail verdict">
    The comment opens with a clear pass or fail status. If the run passed, all tested flows completed without regressions. If it failed, at least one regression was detected.
  </Step>

  <Step title="List of flows tested">
    Opslane lists every flow it exercised during the run — each page visited, form submitted, or interaction sequence completed. This tells you the scope of coverage for that run.
  </Step>

  <Step title="Screenshots of key states">
    Screenshots are embedded in the comment for important moments in the run: page loads, form states, and any point where a failure occurred. For failed runs, screenshots show the exact state the browser was in when the regression was detected.
  </Step>

  <Step title="Full session video">
    A video recording of the entire browser session is attached. You can watch exactly what the browser did, in sequence, from start to finish.
  </Step>
</Steps>

## Screenshots

Opslane captures screenshots throughout the browser run, not just at the end. This gives you a visual record of what the app looked like at each stage.

<CardGroup cols={2}>
  <Card title="Passing flows" icon="circle-check">
    Screenshots confirm that pages and states rendered correctly. Use these to verify that the UI looks right, not just that it loaded.
  </Card>

  <Card title="Failing flows" icon="circle-xmark">
    When a regression is found, the screenshot captures the exact state where the failure occurred — the broken page, the missing element, or the error message the browser encountered.
  </Card>
</CardGroup>

<Tip>
  Screenshots are useful for catching visual regressions — layout breaks, missing content, or UI states that indicate something went wrong — even when the underlying assertion is functional.
</Tip>

## Video recording

The full session video is a recording of everything the Chromium browser did during the run. It plays back in real time, showing:

* Every page navigation
* Every form fill and button click
* How the app responded to each interaction
* The moment and context of any failure

<Info>
  Video is especially useful for diagnosing intermittent failures or complex multi-step flows where a screenshot alone doesn't give enough context to understand what went wrong.
</Info>

## GitHub status checks and merge blocking

In addition to the PR comment, Opslane reports a GitHub commit status check. This is the standard GitHub mechanism that integrates with branch protection rules.

<Tabs>
  <Tab title="Run passed">
    The status check is set to **success**. If you have branch protection rules that require the Opslane check to pass, the PR is cleared for merge.
  </Tab>

  <Tab title="Run failed">
    The status check is set to **failure**. If branch protection rules require the Opslane check, GitHub blocks the merge button until the regression is resolved.
  </Tab>

  <Tab title="Run in progress">
    While the browser run is executing, the status check shows as **pending**. GitHub surfaces this as a pending check on the PR.
  </Tab>
</Tabs>

<Warning>
  Merge blocking only works if you add Opslane as a required status check in your repository's branch protection settings. Without this configuration, Opslane will post results but cannot prevent a regression from being merged.
</Warning>

To enable merge blocking:

1. Go to your repository settings on GitHub.
2. Navigate to **Branches** → **Branch protection rules**.
3. Edit the rule for your main branch (or create one).
4. Enable **Require status checks to pass before merging**.
5. Search for and add the Opslane status check to the required list.

## Interpreting a failed run

When the PR comment shows a failure, use the following sequence to diagnose it:

<AccordionGroup>
  <Accordion title="Check the verdict and summary">
    The top of the comment states which flows failed. Start here to understand the scope — a single broken form is different from multiple pages failing to load.
  </Accordion>

  <Accordion title="Review the failure screenshots">
    Screenshots pinpoint the visual state at the moment of failure. Look for error messages, blank sections, or unexpected UI states that indicate what broke.
  </Accordion>

  <Accordion title="Watch the session video">
    The video shows the sequence of events leading to the failure. This is the fastest way to understand whether the failure is a hard crash, a timing issue, or a logic error in a multi-step flow.
  </Accordion>

  <Accordion title="Identify the regression in your PR diff">
    Compare the failure context against your code changes. Most regressions trace directly to a specific change in the PR — a component update, a routing change, or a new API call that isn't handled correctly.
  </Accordion>

  <Accordion title="Push a fix and wait for the re-run">
    Push updated commits to the PR branch. Opslane automatically triggers a new browser run on the update. If the fix resolves the regression, the status check will update to passed.
  </Accordion>
</AccordionGroup>

<Note>
  If a run fails due to an infrastructure issue rather than a code regression — for example, if the preview deployment was not ready in time — you can trigger a re-run by pushing an empty commit or by reopening the PR. Opslane will launch a fresh browser run on any PR update event.
</Note>