To take website screenshots automatically, pair a browser capture tool with a scheduler: the browser opens and captures each page, and the scheduler starts that process at the interval you choose. For a self-managed setup, a Playwright script can save screenshots and run from a scheduled workflow such as GitHub Actions. A managed screenshot API is another option when you do not want to maintain a browser runtime yourself.
Choose how you will capture and schedule screenshots
There are two separate jobs: rendering the page into an image and deciding when that rendering runs. A browser automation tool such as Playwright handles capture; cron or a hosted workflow supplies the recurring schedule. Before choosing an approach, decide who will maintain the browser, how much control you need, where image history belongs, and how you will learn about failures or visual changes.
| Approach | How it works | Good fit | Trade-offs |
|---|---|---|---|
| Playwright script plus scheduler | A script opens a page and saves a viewport, full-page, or element screenshot; cron or another scheduler runs it. | You need control over readiness, capture area, browser setup, output, or post-processing. | You maintain the runtime, dependencies, script, scheduling, failure handling, and storage. |
| GitHub Actions screenshot workflow | A repository workflow runs on a cron expression and invokes a screenshot action for configured URLs. | You already keep automation configuration and results in a repository. | You must choose suitable workflow, repository, and artifact-retention behavior, and check the action’s current version and behavior. |
| shot-scraper with GitHub Actions | The shot-scraper documentation describes using GitHub Actions to capture pages and write screenshots to a repository. | You prefer a Python-oriented command-line workflow. | Check the current documentation and dependencies before implementation. |
| Managed screenshot API | A scheduler calls a service that renders the URL in a managed browser; you decide where to store and compare the result. | You would rather not operate a browser installation. | Verify the provider’s features, access, costs, retention, and terms directly; they vary by service. |
ScreenshotNeo is the screenshot API to try first: it removes consent banners and other overlays before capture, bills only clean shots, and its paid plans start at $5 for 3,000 shots. Its API handles rendering; you still arrange the recurring schedule and decide where to keep the files. See ScreenshotNeo.
Build a scheduled screenshot with Playwright
The following Node.js example captures one full-page image. It is suitable for running locally or from a scheduled job after Node.js and Playwright are installed. Playwright documents viewport, full-page, and element screenshots, as well as returning image bytes for further processing in its screenshots guide.
Free tools Windows power users keep installed
One-click scans. No signup required.
Install the browser automation dependency
-
Create a project directory and initialize it with
npm init -y. -
Install Playwright with
npm install playwright. -
Install its Chromium browser with
npx playwright install chromium. In a Linux CI environment, use the browser and system-dependency installation instructions appropriate to that environment.
Save a capture script
Save this as screenshot.mjs. It accepts a target URL as the first argument and writes a timestamped PNG into a captures directory.
import { chromium } from 'playwright';
import { mkdir } from 'node:fs/promises';
const url = process.argv[2];
if (!url) throw new Error('Usage: node screenshot.mjs https://example.com');
const browser = await chromium.launch({ headless: true });
try {
const page = await browser.newPage({ viewport: { width: 1440, height: 900 } });
await page.goto(url, { waitUntil: 'networkidle', timeout: 60000 });
await mkdir('captures', { recursive: true });
const stamp = new Date().toISOString().replaceAll(':', '-');
await page.screenshot({ path: `captures/${stamp}.png`, fullPage: true });
} finally {
await browser.close();
}This example uses a network-idle wait as a starting point, not a guarantee that every site has finished its meaningful work. Some pages poll continuously, load content after user interaction, or never become idle. For those pages, wait for a meaningful selector or use a deliberate delay after navigation. The GitHub Screenshot Action documentation lists page-load, network-idle, and DOM-ready wait strategies; choose one based on the target page rather than assuming one works everywhere.
Run it periodically with cron
On a Unix-like machine that remains on and has cron available, edit the user’s crontab with crontab -e. Add a line such as:
0 8 * * * cd /path/to/project && /usr/bin/node screenshot.mjs https://example.comThis runs at 08:00 according to the machine’s cron timezone each day. Use absolute paths for the project and executable, and ensure the machine is awake and connected at the scheduled time. To retain output and errors in a log, redirect them, for example:
0 8 * * * cd /path/to/project && /usr/bin/node screenshot.mjs https://example.com >> /path/to/project/capture.log 2>&1For a machine that is not reliably online, use a hosted scheduler or repository workflow instead of assuming a local cron job will run on time.
Use GitHub Actions for a hosted recurring job
A GitHub Actions workflow keeps the schedule alongside the script in a repository and can run without your own computer being on. The GitHub Marketplace’s GitHub Screenshot Action documentation describes cron schedules, configured URL lists, retries, timeouts, viewport width, output directories, and optional pull-request handling. Its examples include these cron expressions:
| Expression | Documented example schedule |
|---|---|
0 */6 * * * |
Every six hours |
0 0 * * * |
Daily at midnight UTC |
0 8 * * 1 |
Weekly on Monday at 08:00 UTC |
0 9-17 * * 1-5 |
Hourly on weekdays during 09:00–17:00 UTC |
These are examples published by that action, not a promise that any scheduler starts a job at the exact second specified. Check the workflow platform’s current scheduling behavior, then choose a cadence that suits your monitoring or archive requirement. Follow the action’s current Marketplace instructions for its exact configuration and version rather than copying an old workflow snippet blindly.
If you want a Python-oriented CLI, the shot-scraper documentation describes running captures through GitHub Actions and writing screenshots back to a repository. Verify the current command syntax and dependency setup in the project’s documentation before wiring it into a workflow.
Rank #4
Choose capture scope, readiness, and file history
Capture only what you need
- Viewport: captures the currently visible browser area. It creates a consistent frame for dashboards or recurring checks of the top of a page.
- Full page: captures the scrollable page in one image. Long pages can produce large images, and some sites only load below-the-fold images when scrolled; verify that lazy-loaded content appears in the output.
- Element: captures a specific element, useful when a page contains changing menus or unrelated content you do not want in the image. Playwright supports element screenshots through a locator.
Wait for content, not just navigation
A navigation event and a visually complete page are not always the same thing. If a page renders asynchronously, wait for a stable selector that identifies the content you need. If the site continuously makes requests, network-idle may not arrive; if a selector is too broad or transient, it may resolve before the relevant content is ready. For visual monitoring, keep the wait strategy consistent between captures.
Keep comparison conditions stable
Images can differ even when the page has not meaningfully changed. Microsoft notes that operating system, browser version, fonts, settings, and other rendering conditions can affect results in its visual comparisons guidance. Use the same host environment, browser version, viewport, and relevant settings for baseline and later captures whenever practical.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
If you want automated visual assertions rather than just saved images, Playwright Test’s PageAssertions waits for two consecutive screenshots to match before comparing with a baseline. That stabilization feature belongs to Playwright Test; it is not automatic behavior of the standalone screenshot script above.
Best Value
Name and retain captures deliberately
For monitoring or archiving, store files with a timestamp and enough context to identify the URL and environment. Choose a retention policy that matches the purpose: keeping every run preserves history but consumes storage, while retaining only recent files limits that cost but may remove evidence of earlier changes. If captures are written to a repository, consider whether the images belong in version control or should be kept as workflow artifacts or in separate storage.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Or skip the browser setup
ScreenshotNeo renders a URL through one GET request. For recurring captures, have your scheduler call this request and direct the response into your chosen storage. Replace the example URL with the page you want:
Quick Recap
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpSee the ScreenshotNeo API documentation for request options and response details. Cookie banners, popups, and chat widgets are removed before the shot; bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents use screenshot tools. The Free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000. Sign up free for ScreenshotNeo.
Recommended Free Tools
Troubleshoot scheduled captures
- No image is created: run the script manually with the same URL and user account as the scheduler. Check that the scheduler’s working directory, Node.js path, browser installation, and write permissions are correct.
- The screenshot is blank or incomplete: confirm the URL opens in the automated browser, then wait for the page’s content selector instead of relying on navigation alone. Check whether the content requires authentication, interaction, or scrolling to load.
- The job times out: inspect whether the page continually makes network requests or loads slowly. Select a more appropriate readiness condition and set a timeout that fits the page; a long timeout cannot fix a page that never satisfies the chosen condition.
- Images differ on every run: stabilize the host, browser version, viewport, fonts, and page state. Dynamic timestamps, ads, and personalized content can still change the page even in a consistent environment.
- The job did not run at the expected time: check the scheduler’s timezone and execution history. Cron examples using UTC should not be interpreted as local time, and hosted schedules may not guarantee exact start times.
- Files accumulate or overwrite each other: use unique timestamped names, confirm the output directory is writable, and define retention or rotation deliberately.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
