Sweeper: finds console errors, broken links and 4xx/5xx on every page of your site

Sweeper is Spitfire's site-scan module. It opens your site in a real browser (headless Chromium) page by page from a start URL, follows its links (a crawl) and gathers the errors your users would run into in one report. In its default read mode it clicks nothing and submits no forms, so it is safe to run on production. Interactive mode tries every button, select and form on staging.

What it finds

How it works

1. Give it a start URL. The rest comes with defaults: depth 3, 2 pages at a time, a 3 s slow-page limit. Add extra hosts, include/exclude path patterns like /blog/*, headers or a cookie if you need them.
2. A browser runner crawls. The runner opens the pages and measures status, TTFB, load time and LCP on each; it listens to the console, the exceptions and the sub-requests, and queues the page's links within the scope and depth limits.
3. A report and a verdict. The run page counts the pages and each kind of finding, and lists the pages with findings in detail. Your thresholds decide whether the run passes; a failed run fails the CI job and, if you want, tells Slack, Teams, e-mail or a webhook.

Why read mode is safe on production

• It opens pages with GET requests only; it does not click, type or submit forms.
• Logout-like paths (/logout, /signout, /cikis…) are always skipped.
• It only crawls your hosts; links to other sites are, if you ask, only requested (HEAD or GET), never crawled.
• Pages, depth and concurrency are capped: at most 4 pages open at a time.
• Session headers and cookies are stored encrypted and go only to the sweep's hosts.

CI and schedules

After a deploy, the pipeline gets one more line: spitfire cloud sweep "Shop". When the thresholds are broken the command exits 99 and the job fails. With the Sweeper module a sweep also runs on a cron schedule (e.g. 0 3 * * *, every night at 03:00, in your time zone); a failed run goes to the notification channels subscribed to sweep.failed. Setting up CI: performance testing in CI/CD.

On GitHub Actions: deploy to staging, sweep it, and deploy to production only when the sweep passes (the token is the pipeline secret SPITFIRE_TOKEN; no CLI download, it ships in the Docker image):

# .github/workflows/deploy.yml
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh staging            # your own deploy step
      - name: Sweeper
        env:
          SPITFIRE_URL: https://spitfire.example.com
          SPITFIRE_TOKEN: ${{ secrets.SPITFIRE_TOKEN }}
        # exits 0 passed, 99 thresholds broken, 1 could not run: 99 and 1 stop the job here
        run: docker run --rm -e SPITFIRE_URL -e SPITFIRE_TOKEN usespitfire/spitfire spitfire cloud sweep "Shop" --timeout 30m
      - run: ./deploy.sh production         # only after a passed sweep

Interactive mode (staging, Spitfire 1.4.3)

Read mode only looks at the pages. Interactive mode goes one step further before a deploy: on every page of staging it tries every button, menu item, tab, checkbox and radio, select and form in a real browser, one by one, and measures the page after each try. It is not a production monitor; it is a test that runs on staging before a release goes out. Read mode stays the default and does not change.

• What it finds: a console error or exception after the try, a 4xx/5xx on a request to the sweep's hosts (e.g. POST /api/cart → 500), a page that crashes or goes blank, a click that never reaches its element. Each is reported with the page, the element's label, the action (click, select, submit) and the result, and counts as an error; the same max errors threshold applies.
• What it never clicks: irreversible actions such as delete, and payment-like buttons (pay, buy now, place order, checkout, subscribe…) are skipped; you add your own texts or CSS selectors to the list. Logout paths and logout buttons are always skipped. The skipped ones are listed in the report with the reason.
• Nothing goes out: requests and form submissions to other hosts (a payment provider, an e-mail service…) are blocked; only the sweep's hosts are allowed, and a blocked request shows in the report as "did not go out".
• Staging only: the mode runs only on the hosts listed in the sweep, and saving it asks you to confirm "This address is a staging/test environment"; the confirmation is stored with the sweep, and who started it on which host goes to the audit log.
• Forms: you give sample values by field name, label or selector (e.g. email → test@example.com); a form without values is submitted as it is, and the server is expected to answer with its validation, not a 5xx.
• CI stays the same: spitfire cloud sweep "Shop" does not change, the mode comes from the sweep, and so do the exit codes (0 / 99 / 1). The GitHub Actions example above is the deploy-to-staging, interactive sweep, then production flow.
• Limits: without the module up to 20 interactions a page and 50 pages a sweep; with the Sweeper module up to 500 interactions a page.

Limits, trial and price

Coming soon: a sweep that starts from a Recorder recording. Other plans and add-ons: pricing and licenses.

Frequently asked