Help · CI

Check every deploy, before your client does

One step after your staging deploy. The build waits for UICheck, prints the score and the top findings with a link to the full report, and fails when the quality gate fails: new critical or major issues, or a score drop since the last check of the same pages.

Create a CI token →See the setup

GitHub Actions
GitLab CI
Bitbucket Pipelines
Any CI with Node 18+
One file, no install

deploy · uicheck

$ node uicheck.mjs run --url https://staging.client.comUICheck: checking https://staging.client.comReport: https://uicheck.app/app/checks/cm4x…  5 of 5 screens checked Quality gate: PASSED · improved (+6 points)  ✓ New critical issues (must be 0): none  ✓ New major issues (must be 0): none  ✓ Score change (may drop 2 points at most): +1 point Score 92 · 0 critical · 1 major · 4 minor PASSED (fail-on: gate)

Set it up in three minutes

1
Create a CI token
In Integrations → CI tokens, name it after your pipeline and copy it. It’s shown once. It can only start and read checks, and you can revoke it any time.
2
Save it as UICHECK_TOKEN
Add it as a secret in your CI under that name. Where it goes for each CI is shown below the code.
3
Add the step after your deploy
Paste the step for your CI and change the address to your staging site. The next deploy is checked.

.github/workflows/uicheck.yml

name: UICheck
on:
  deployment_status:          # after your staging deploy (Vercel, Netlify, …)
  workflow_dispatch:
jobs:
  uicheck:
    if: github.event_name == 'workflow_dispatch' || github.event.deployment_status.state == 'success'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-node@v4
        with: { node-version: 22 }
      - run: curl -fsSL https://uicheck.app/ci.mjs -o uicheck.mjs
      - run: node uicheck.mjs run --url https://staging.example.com
        env:
          UICHECK_TOKEN: ${{ secrets.UICHECK_TOKEN }}

Token: Settings → Secrets and variables → Actions → New repository secret

What the build does with the result

exit 0

Passed

The quality gate passed (or nothing at your --fail-on level). The build goes on.

exit 1

Failed

The gate failed, or the site couldn’t be checked. The log links to the report.

exit 2

Couldn’t ask UICheck

UICheck couldn’t be reached, or the token was refused.

Options

--url <url>: A page to check. Repeat it for more pages.
--project <domain>: A saved project, e.g. client.com: its pages, screen sizes and settings.
--env <name>: production (default) or staging, with --project.
--crawl: Check the whole site, starting from the first URL.Lens · Prism
--viewports <list>: Screen sizes, e.g. 390x844,1280x800. Default: your plan’s standard sizes.
--browser <name>: chromium, webkit (Safari) or firefox.Safari, Firefox: Lens · Prism
--fail-on <level>: gate (default), or fail on any critical, major or minor finding.
--timeout <minutes>: Stop waiting after this long (default 20). The check keeps running.
--json: Print the full result as JSON.

Good to know

Branch and commit on every check

Read from GitHub, GitLab or Bitbucket and shown on the report. On GitHub the result also appears in the job summary.

Counts as a check

CI checks count towards your plan’s checks per day. See plans

Staging behind a firewall?

Let UICheck in past Cloudflare or Vercel protection with your site access key.

Coming soon

UICheck inside your Playwright tests

Check the screens a link can’t reach: after login, a full cart, a step of checkout, an open menu. One line in the tests you already have, and every layout problem lands in your UICheck report with the branch and commit.

await page.click('text=Checkout');
await uicheck(page);   // checks this screen, logged in

Make the next deploy the last one with a broken layout

Create a token, paste one step, and every deploy is checked on phone, tablet and desktop.

Create a CI token See pricing