How to schedule website screenshots with BrowserStack

To schedule website screenshots with BrowserStack, configure a recurring job in your test runner or CI scheduler that launches a Percy-enabled test suite. BrowserStack’s documentation describes capturing and comparing screenshots with Percy, including Percy integrations with BrowserStack Automate. The reviewed documentation does not establish a native BrowserStack calendar scheduler, so the recurrence comes from the scheduler your team already uses.

Use Percy Web for visual tests on the newest browsers, or Percy with Automate when you need a broader desktop, mobile, browser, or device matrix. The steps below show the capture setup; the exact recurring schedule depends on your test runner and CI provider.

1. Choose the capture route

First decide what the scheduled run needs to cover:

Browser coverage: Percy Web targets visual tests on the newest browsers. Percy with Automate is suited to a range of desktop, mobile, browser, or device combinations.
Capture trigger: capture automatically at supported events, or add explicit checkpoints in the test.
Page coverage: capture a full page for broad review, or scope a snapshot to a specific component when that is the intended target.
Viewport coverage: choose fixed dimensions and device combinations that match the comparison you want.
Schedule owner: use the test runner or CI scheduler already responsible for recurring jobs.

BrowserStack’s documentation covers Percy integration and capture modes, while the recurring job configuration is specific to the chosen scheduler. See Percy’s SDK integration overview and the recommended Percy guidelines.

2. Integrate Percy with the test suite

Install and configure the Percy SDK that corresponds to your test stack, then make the scheduled job run that Percy-enabled suite. The following example is a JavaScript/Mocha capture pattern based on BrowserStack’s Selenium and Mocha integration guide. It assumes the project has already installed and configured the relevant Selenium and Percy SDK packages and credentials as described in that guide.

// In a Selenium + Mocha test, capture at the point where the page is ready.
describe('scheduled visual check', function () {
  it('captures the product page', async function () {
    await driver.get('https://example.com');
    await driver.wait(until.elementLocated(By.css('main')), 10000);

    // Use the Percy SDK screenshot method at this deliberate checkpoint.
    await percySnapshot(driver, 'Product page');
  });
});

The exact imports, driver setup, SDK initialization, and package commands depend on the integration version and project configuration. Follow the current BrowserStack Selenium and Mocha guide for a runnable project setup. Percy supports SDK-driven capture, including automatic capture with percyCaptureMode: auto, as well as explicit screenshot calls.

3. Choose when each screenshot is taken

The Selenium/Mocha integration documents these capture modes:

Mode	Use it when
`auto`	You want supported page or test events to trigger capture automatically.
`testcase`	You want captures associated with test cases.
`click`	You want capture behavior associated with click actions.
`screenshot`	You want the screenshot method to be the capture trigger.
`manual`	You want an explicit checkpoint after the page reaches a meaningful state.

For pages with asynchronous content, manual capture is often easier to reason about: wait for the relevant content and then call the snapshot method. Avoid capturing before the page state you care about is present. Refer to the integration guide for mode configuration details.

4. Set stable viewport dimensions and page coverage

Percy with Automate captures at the browser’s current window size. Set the window dimensions before the screenshot call, and keep them consistent between scheduled runs when you want comparable results. If the check needs multiple widths, set each width deliberately and capture each state. BrowserStack explains this behavior in its guide to capturing screenshots at different viewport widths.

For long pages, Percy with Automate supports a full-page option. For a focused visual check, Percy CLI supports scoped snapshots. Choose full-page capture when the whole page matters; choose a scoped snapshot when unrelated dynamic regions would obscure the component under review. BrowserStack recommends broader page verification for wider coverage. See the docs for full-page screenshots and running Percy with the CLI.

5. Schedule the test run

Confirm the Percy-enabled suite runs successfully when launched manually.
In your existing test runner or CI scheduler, create a recurring job that runs the same suite and supplies the required environment and Percy configuration.
Choose the recurrence that matches your review cadence and application release process.
Ensure the job reports its result and that someone can review the resulting Percy build.
Run the scheduled job once on demand to confirm that it launches the suite and creates the expected Percy build.

The documentation reviewed does not give verified setup steps for a specific CI vendor or show a native BrowserStack calendar scheduler. Consult the current documentation for your chosen scheduler for its recurrence syntax, secrets handling, and job configuration.

6. Review snapshots and keep runs comparable

Subsequent Percy-enabled runs capture screenshots for comparison and surface visual changes for review. Keep the important inputs stable: page state, browser window dimensions, device/browser combinations, and capture point. When a page changes frequently for reasons unrelated to the visual check, narrow the snapshot to the relevant region or wait for the intended stable state.

Configuration checklist

Choose Percy Web or Percy with Automate based on browser and device coverage.
Select the capture mode and make explicit checkpoints where timing matters.
Set browser dimensions before capture; Automate uses the current window size.
Choose full-page or scoped capture according to the question the snapshot should answer.
Schedule the Percy-enabled suite through your existing test runner or CI scheduler.
Keep run inputs consistent and review each resulting Percy build.

Common problems and fixes

Problem	Likely cause	Fix
No recurring screenshots appear	The scheduler is not launching the Percy-enabled suite, or the scheduled job lacks the project’s required configuration.	Run the job manually, inspect its logs and environment, and confirm it invokes the same test command as a successful local run.
The screenshot captures the wrong page state	The capture trigger occurs before navigation or asynchronous content has finished.	Wait for a page element that marks readiness, then use a deliberate screenshot checkpoint.
Snapshots differ in dimensions	The browser window size is not fixed before capture.	Set explicit dimensions for every run and capture width; Automate uses the current browser window size.
A long page is cut off	The capture is using the current viewport rather than a full-page option.	Enable the documented full-page option for Percy with Automate and confirm the resulting capture covers the intended page.
Unrelated dynamic content creates noisy differences	The snapshot includes regions that are outside the visual check’s scope.	Use a scoped snapshot for the relevant component, or capture after the page reaches the state being compared.
A Percy build is created but changes are hard to review	Runs use inconsistent page state, viewport, or browser/device coverage.	Standardize those inputs and label snapshots consistently in the test suite.

Performance, reliability, and cost considerations

A scheduled run’s duration depends on the test suite and the browser/device coverage it launches. A wider matrix provides more coverage but can require more browser sessions and time. Keep the scheduled suite focused on routes and viewports that provide useful visual coverage, and use explicit waits so captures represent the intended page state.

Reliability comes from treating screenshots as outputs of repeatable tests: use stable dimensions, deterministic capture points, and a scheduler that reports failures. The cited BrowserStack implementation documentation does not provide a pricing comparison or a benchmark for scheduled screenshot duration, so evaluate those against your actual plan and workload rather than assuming a fixed cost or runtime.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server from ScreenshotNeo. A GET request returns a PNG, JPEG, WebP, or PDF. See the API documentation for request options. This is useful when the task is recurring page capture without maintaining a browser test setup; it does not replace Percy visual test comparisons.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Replace the example URL with the page to capture. ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before the shot; bot checks, blank pages, and failed loads are never billed; its MCP server lets AI agents take screenshots; and 1,000 screenshots a month are free with no card, with paid plans starting at $5 for 3,000. Sign up for 1,000 free screenshots a month, with no card required.

FAQ

Does BrowserStack provide a built-in calendar schedule for Percy screenshots?

The BrowserStack pages reviewed document Percy capture and comparison, but do not establish a native calendar scheduler. Schedule the Percy-enabled test run with your existing test runner or CI scheduler.

Can screenshots be captured only at selected points?

Yes. The documented manual mode lets the test call the screenshot method at a chosen point, such as after the page reaches the state you want to check.

Should I capture the whole page or one component?

Use full-page capture when the complete page is under review. Use a scoped snapshot when the check is specifically about a component or region.

Why should viewport size be set before capture?

Automate captures at the current browser window size, so changing or unspecified dimensions can make snapshots incomparable.