ScreenshotNeo

BlogHow-to

How to Schedule Daily Website Screenshots with BrowserCat

Use BrowserCat with Playwright for capture, then add a separate daily scheduler and archive. Includes a runnable script, cron setup, troubleshooting, and a no-browser API option.

By the ScreenshotNeo team4 October 20269 min read

To schedule daily website screenshots with BrowserCat, use Playwright to connect to BrowserCat’s cloud browser, capture the page, and save or deliver the image. Configure a separate scheduler to run that script every day: BrowserCat provides the browser session in this workflow, while the scheduler provides the recurring trigger. The reviewed BrowserCat quick start documents screenshot capture and a cloud connection, but not a built-in daily schedule.

This guide uses Node.js and Playwright, then covers scheduling, stable capture settings, storage, failures, and operational tradeoffs. For current BrowserCat setup details, follow its official quick start; confirm the current URL and account setup in the documentation before deploying.

1. Prepare the script and credentials

Use a Node.js runtime with playwright-core installed. The script below connects to BrowserCat over its documented WebSocket endpoint and sends the API key in the Api-Key header. Set BROWSERCAT_API_KEY and TARGET_URL in your local environment or the scheduler’s secret configuration. Do not commit the key to a repository.

npm install playwright-core

Save this as capture.mjs:

import * as pw from 'playwright-core';

const apiKey = process.env.BROWSERCAT_API_KEY;
const targetUrl = process.env.TARGET_URL;

if (!apiKey) throw new Error('Set BROWSERCAT_API_KEY');
if (!targetUrl) throw new Error('Set TARGET_URL');

async function run() {
  const browser = await pw.chromium.connect(
    'wss://api.browsercat.com/connect',
    { headers: { 'Api-Key': apiKey } }
  );

  try {
    const page = await browser.newPage({
      viewport: { width: 1440, height: 1000 }
    });
    await page.goto(targetUrl, { waitUntil: 'load', timeout: 60000 });

    // Replace this with a selector that identifies the content you need.
    // For example: await page.locator('main').waitFor({ state: 'visible', timeout: 30000 });
    await page.waitForLoadState('networkidle', { timeout: 30000 }).catch(() => {});

    const date = new Date().toISOString().slice(0, 10);
    await page.screenshot({
      path: `site-${date}.png`,
      fullPage: true
    });
  } finally {
    await browser.close();
  }
}

run().catch(error => {
  console.error(error);
  process.exitCode = 1;
});

The connection and screenshot calls follow BrowserCat’s documented quick-start approach. The viewport, dated filename, and wait strategy are implementation choices. This illustrative script has not been represented as tested. In production, write to a directory or object store that exists and is writable in the scheduler’s runtime; a temporary job filesystem may not preserve files between runs.

Choose a capture scope and readiness condition

  • Viewport: omit fullPage: true when only the visible screen matters. Keep viewport width and height fixed so daily images remain comparable.
  • Full page: use fullPage: true when the whole document is needed. Long pages can produce large files and take longer to capture.
  • Specific content: wait for a stable selector with page.locator('selector').waitFor({ state: 'visible' }). Use a selector that represents the content you need, rather than relying on an arbitrary long delay.
  • Navigation: load waits for the page load event. Some sites continue making requests after that. networkidle can be useful, but analytics or streaming requests may prevent it from occurring; use a bounded timeout and a meaningful selector when appropriate.

Dynamic sites can still vary from day to day because content, advertisements, experiments, and data change. A stable viewport and explicit readiness condition make captures more comparable, but do not guarantee identical pixels.

2. Schedule the script to run daily

Choose a scheduler that can run a Node.js command and provide its environment variables. The exact setup depends on the runtime. For a conventional five-field cron parser, this expression means 06:00 every day in the scheduler’s configured timezone:

0 6 * * *

Before activating the job, check the scheduler’s timezone display and next-run time. Confirm how it handles daylight-saving changes. Cron implementations and managed schedulers differ, so verify the expression in the environment that will run it.

Configure the scheduled command to run from the directory containing the script, with the required environment variables:

node /path/to/capture.mjs

Store BROWSERCAT_API_KEY and TARGET_URL in the scheduler’s secret or configuration facility. Set a job timeout long enough for browser startup, navigation, content readiness, and image transfer, but finite enough that a hung run is stopped and reported. If your scheduler supports it, prevent overlapping runs or define what should happen if one run is still active when the next is due.

3. Choose where screenshots go

A local file is sufficient for a one-off run or a persistent machine. A recurring job needs an intentional archive destination and retention policy. The reviewed BrowserCat quick start establishes browser capture, not a particular storage or delivery feature. The destination is your responsibility unless you use a separate service that documents it.

  • Use a predictable key or path, such as screenshots/site-name/YYYY-MM-DD.png.
  • Include a timezone or region in the folder or metadata if capture time is important for review or evidence.
  • Decide how many days or months to retain images, and whether older files should be deleted or moved to lower-cost storage.
  • Restrict access to the archive. Screenshots can contain personal, account, or business information, especially for authenticated pages.
  • For external storage, upload after the capture succeeds and report upload failures separately from browser failures.

A hosted scheduling guide from Add Screenshots documents recurring schedules and delivery options including S3, Azure, Google Cloud Storage, Cloudflare R2, FTP, webhooks, and email. Those are documented capabilities of that service, not BrowserCat. Verify its current settings and terms if considering a managed archive.

4. Keep the daily captures useful

  1. Fix the capture conditions. Keep URL, viewport, capture scope, and relevant browser settings consistent. Record any intentional changes to those settings.
  2. Wait for what matters. Prefer a selector for the content being monitored. Use a timeout so a missing element becomes a visible failure rather than an indefinitely stuck run.
  3. Make each output unique. Include the date in the filename or object key. If the schedule can run more than once per day, include time as well.
  4. Record run results. Log the capture timestamp, target, output location, and error. Keep logs free of API keys, cookies, and sensitive page content.
  5. Alert on missed runs. Configure the scheduler to notify you when a run fails or does not complete. A successful browser connection alone does not prove the image reached the archive.
  6. Review access and retention. Respect access controls and the site’s terms when capturing third-party or authenticated pages. Keep only the images and logs you need.

5. Troubleshoot common failures

Symptom Likely cause Fix
Browser connection fails or is rejected Missing, invalid, or unavailable API key; incorrect connection endpoint; network restrictions. Check the current BrowserCat quick start, confirm the scheduler has the secret configured, and verify outbound WebSocket access. Never print the key into logs.
Script works locally but fails on the schedule The job has a different working directory, Node version, environment, permissions, or filesystem. Use an explicit script path, configure the runtime and secrets in the scheduler, and write to a known writable location or upload directly to persistent storage.
Navigation times out The site is slow, unreachable, or keeps loading; the chosen navigation event may not fit the page. Check the target URL and network reachability. Set a reasonable timeout and wait for the specific content required. Avoid treating an unbounded wait as a fix.
Screenshot is blank or missing expected content The page had not rendered the relevant content, a selector was wrong, or content loads after navigation. Wait for a visible, page-specific selector and inspect the failed run’s logs. Use a bounded fallback only when a selector is not available.
networkidle times out Ongoing requests such as analytics or streaming prevent the page from becoming idle. Use a meaningful selector or a short, bounded wait after the required element appears. Do not make network idle the only readiness condition for such pages.
Images are overwritten The output name is constant or the scheduler runs more than once per day. Add an ISO date to the path; include time or a run identifier when multiple captures per day are possible.
Files disappear after the job The scheduler uses an ephemeral filesystem. Upload the image to persistent storage as part of the job or use a runtime with persistent storage.
Runs overlap or create duplicate output A run takes longer than the schedule interval or retries are configured. Set a maximum runtime and scheduler concurrency policy. Make the destination key and upload behavior safe for retries.
Capture time shifts seasonally The scheduler timezone or daylight-saving behavior differs from the intended local time. Inspect the configured timezone and next run, and decide whether the schedule should follow local time or a fixed UTC time.

6. Performance, reliability, and cost

Capture time depends on BrowserCat connection and browser startup, the target site, readiness waits, page length, and image transfer. Full-page shots generally involve more content than viewport shots. Keep waits bounded and avoid capturing more page area than the workflow needs.

For reliability, handle browser closure in a finally block, surface failures to the scheduler, and separate capture success from archive-upload success. Decide whether a failed run should retry; retries can help with transient failures but may create duplicate files or additional browser usage. Use dated, deterministic output names and define a concurrency policy.

BrowserCat’s homepage describes managed cloud browser execution and usage-based pricing. The supplied research does not establish a neutral price or performance comparison, nor a decision-relevant benchmark. Check the current BrowserCat pricing and account details for your expected run frequency, browser usage, retries, and retention needs. A daily schedule is 30 or 31 runs in many months, but each run’s resource use depends on the actual capture workload.

7. When to use a managed schedule instead

BrowserCat plus your scheduler gives you control over the Playwright logic, while leaving the recurring trigger and archive configuration to your infrastructure. If you prefer a bundled scheduling and delivery workflow, Add Screenshots documents daily or custom cron schedules, reusable capture settings, and destinations such as cloud storage, FTP, webhooks, and email. Compare setup effort, capture controls, timezone behavior, destination support, current pricing, and terms. These scheduling and delivery features should not be attributed to BrowserCat.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. Use the DIY BrowserCat and Playwright workflow above when you need that browser script; for a one-call capture, ScreenshotNeo returns a screenshot or PDF from a URL. See the ScreenshotNeo API docs for its request options.

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}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

Before capture, ScreenshotNeo accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

Create a free ScreenshotNeo account for 1,000 screenshots a month with no card.

FAQ

Does BrowserCat itself run screenshots on a daily schedule?

The reviewed BrowserCat quick start documents cloud browser connection and capture, not a daily scheduling setting. In this guide, a separate scheduler launches the script each day.

Can I capture a page that requires login?

A script can only capture pages it is authorized to access and can successfully load. Handle credentials as secrets, limit access to the resulting archive, and follow the site’s terms.

Will daily screenshots be pixel-identical?

No. The page’s content and behavior can change. Consistent capture settings improve comparability but cannot freeze the website itself.

Should I use a fixed UTC schedule or local time?

Choose based on when the capture must happen. Check the scheduler’s timezone and daylight-saving behavior, then verify the displayed next run before enabling the job.