Scheduled scans

A scheduled scan checks a live site with no pull request involved: a nightly look at production, a weekly check of a client’s site, or monitoring a page that content editors change outside of code review.

Scheduled scans have their own monthly allowance, so they never use up the runs your pull requests need.

Plan	Scheduled scans per month
Free	5
Developer	60
Team	300
Agency	1,500

Each project can also start at most 4 scheduled scans per UTC day.

GitHub Actions

Add a workflow triggered by schedule, pointed at the live site. The site’s host must be in the project’s allowed domains. id-token: write is required: it is how QualityGate confirms the run really was started by a schedule.

name: QualityGate nightly

on:
  schedule:
    - cron: '0 3 * * *' # 03:00 UTC every day

permissions:
  contents: read
  id-token: write

jobs:
  production:
    runs-on: ubuntu-latest
    steps:
      - run: npx -y playwright@1.61.1 install --with-deps chromium
      - uses: qualitygate/scan-action@v1
        with:
          url: https://www.example.com/
          bundle: full

For several pages or sites, use a matrix as described in Multiple pages and sites.

GitLab CI

The released template already runs for scheduled pipelines. Create a schedule under Build → Pipeline schedules and set the variable QUALITYGATE_URL on the schedule to the live site.

What is different about scheduled runs

• They never comment on a pull request and never become a regression baseline.
• A failing scheduled scan fails its workflow run, which GitHub or GitLab can notify you about. QualityGate notifications also cover failed gates.
• They appear in run history and score trends labelled Scheduled scan, and the weekly digest lists the latest scheduled result for each project and bundle.