ScreenshotNeo

BlogHow-to

How to schedule website screenshots for a specific day of the week

Schedule a website screenshot for a chosen weekday, time, and timezone. Compare scheduler, no-code, and cron workflows, then verify the next run.

By the ScreenshotNeo team4 October 20269 min read

To schedule a website screenshot for a specific weekday, create a weekly recurring job, choose the weekday and run time, set the timezone, configure the page capture, and verify the next scheduled run. You can do this in a screenshot service’s scheduler, a no-code automation workflow, or a server-side cron job that calls a screenshot API.

The schedule controls when the job starts; the screenshot settings control what it captures. Keep the timezone and capture configuration consistent if you plan to compare images over time.

1. Choose a scheduling method

Method Best when What to check
Built-in screenshot scheduler You want scheduling, capture history, and delivery in one service. Weekday selection, timezone and daylight-saving behavior, retention, plan limits, and failure notifications.
No-code automation You already use an automation platform and want to connect a weekly trigger to a screenshot action. Trigger timezone, selected-day behavior, task limits, image storage, and what happens when an action fails.
Cron plus screenshot API You want to manage recurring jobs on your own server or scheduler. Cron syntax and timezone, retries, secure API-key storage, output storage, and alerts.

For a visual scheduler, PagePixels advertises schedules based on intervals, weekdays, time of day, and timezone. Allscreenshots documents weekly schedules, history, and optional email or webhook delivery. Site-Shot documents daily, weekdays-only, or chosen-day schedules, using UTC. These are provider-documented capabilities; check current plans and behavior before relying on them. PagePixels, Allscreenshots, Site-Shot.

For a no-code workflow, Zapier documents using Schedule by Zapier as a weekly trigger and ScreenshotOne’s “Take Website Screenshot” as the action. The trigger includes selected day or days, time of day, and an optional timezone override. Confirm where the resulting image is stored and how action failures are surfaced. Zapier’s workflow documentation.

For a cron-based scheduler, ScreenshotAPI.net documents a five-field expression in this order: minute, hour, day of month, month, day of week. Its example 0 8 * * 1 represents Monday at 08:00 according to that provider’s documentation. Cron dialects and timezone defaults vary by host, so do not assume that expression means 08:00 in your local timezone. ScreenshotAPI.net.

2. Define the weekly schedule

  1. Choose the weekday or weekdays. If selecting multiple days, check whether the scheduler creates one capture on each selected day.
  2. Choose the time of day and decide whether it should follow a local clock or a fixed UTC hour.
  3. Set the timezone explicitly where the service supports it. Review how the service handles daylight-saving transitions; provider documentation does not establish one universal rule.
  4. Save the schedule and inspect the displayed next-run time. Check that the date, weekday, and timezone match your intent.

Example cron expression

In a cron implementation that uses the documented five-field order, this expression schedules a run each Monday at 08:00 in the scheduler’s configured timezone:

0 8 * * 1

Some systems require a timezone setting outside the expression; others run cron in UTC or use a service-specific timezone. Confirm the syntax and next execution with the scheduler that will actually run the job.

3. Configure what the screenshot captures

  • URL: Use the exact page URL, including any path or query parameters required to reach the intended state.
  • Full page or viewport: Choose full-page capture for a record of the whole scrollable page; choose viewport-only when the fold or a fixed screen area is the subject.
  • Viewport and device: Keep the screen size or device profile fixed across scheduled captures. Otherwise, responsive layout changes can look like page changes.
  • Format: Select an image format supported by the capture service and suitable for your archive or downstream workflow.
  • Wait behavior: If the page renders asynchronously, wait for a stable selector, a delay, or another supported readiness condition. Avoid a delay so short that content is missing or so long that it wastes execution time.
  • Dynamic overlays: Hide or wait for cookie banners, chat widgets, ads, or other changing regions when your goal is to track the underlying page. If the overlay itself matters, leave it visible.
  • Access: For pages that require authentication, check whether the capture service supports the required cookies or headers, and handle secrets through the service’s secure configuration.

Capture controls differ by provider. Allscreenshots documents full-page and viewport capture options, along with ways to wait for content and hide elements. See its feature documentation. For visual comparisons, consistent capture settings reduce differences caused by the capture setup itself. This is a practical consequence of changing viewport and rendering options, not a guarantee about any provider’s comparison algorithm.

4. Choose storage, delivery, and change alerts

Decide what should happen after each run before you depend on the schedule:

  • History: Check how long images are retained and whether old captures expire or count against storage limits.
  • Delivery: Choose an archive, email, webhook, or another supported destination. Verify that the destination can receive the image or a usable image link.
  • Change-only notifications: If supported, check what the service compares. Pixel-based comparisons can flag rotating ads, counters, personalized content, and other dynamic regions even if the meaningful page content is unchanged.
  • Failure handling: Find out whether a missed or failed run is retried, logged, or reported. A saved schedule alone does not prove that a capture completed.

Allscreenshots documents schedule history, email or webhook delivery, and optional change-only notifications; its documentation describes comparison as pixel-based. Site-Shot documents email alerts and notes that a page-height change can trigger an alert. Notification channels, retention, and comparison behavior vary, so verify current details with the provider. Allscreenshots and Site-Shot.

5. Run and verify the first capture

  1. Save the schedule and confirm the next-run time, timezone, URL, and weekday.
  2. If the scheduler has a test or run-now option, use it and inspect the resulting image.
  3. Check that the expected content has loaded, the desired page area is present, and unwanted overlays are handled as intended.
  4. Confirm that the image reached the chosen history or delivery destination.
  5. After the first scheduled run, check the run record and delivery before assuming the recurring job is working reliably.

6. Schedule screenshots with cron and a screenshot API

A typical implementation has two separate parts: a scheduler triggers a script on the chosen weekday, and the script calls a screenshot API and saves or delivers the response. The following shell example shows the API call portion using ScreenshotNeo. Add it to the scheduler you use only after checking that scheduler’s cron syntax and timezone. Keep the API key in a secret store or protected environment variable, not in a public repository.

cURL

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

Python

import requests

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

Node.js

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}`);
const image = new Uint8Array(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', image));

These examples make an immediate request; they do not create a recurring schedule by themselves. Configure the weekly trigger in your cron host, job runner, or scheduler, and make sure the script’s timezone matches the intended schedule. See the ScreenshotNeo API documentation for request options and response details.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. Configure your weekly scheduler to call its API at the chosen time:

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

Cookie banners, newsletter popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed; response headers report the page verdict and billing status. An MCP server lets AI agents use screenshot tools. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots. Read the API docs, then sign up for 1,000 free screenshots a month with no card.

Troubleshooting scheduled captures

Symptom Likely cause What to do
The screenshot ran on the wrong weekday or at the wrong hour. The scheduler uses a different timezone, cron dialect, or day-of-week convention than expected. Check the configured timezone and the scheduler’s next-run display. Confirm its cron field order and weekday numbering in its own documentation.
The local run time shifts after a daylight-saving change. The schedule may follow UTC or have provider-specific daylight-saving behavior. Check whether the scheduler follows local civil time or a fixed UTC time, then verify the upcoming run around the transition.
The image is blank or missing key page content. The page may render after the capture begins, or the requested URL may need authentication or a redirect. Inspect the final URL and access requirements. Add a supported readiness wait and test the resulting image manually.
Each screenshot looks different even when the page seems unchanged. Viewport, device settings, personalized content, ads, counters, or other dynamic elements may vary. Keep capture settings fixed and hide or wait for changing elements where appropriate. Treat pixel-change alerts as visual signals to inspect, not proof of a meaningful content change.
A scheduled capture was saved, but no image arrived. The action may have failed, or delivery and storage may be configured separately from the schedule. Check the run history, destination configuration, and failure logs. Verify delivery with a manual capture.
The API script reports an HTTP error. The key, request parameters, URL, network, or target-page load may be invalid or unavailable. Check the response status and API response details, confirm the key and URL, and retry only according to the provider’s documented behavior. Do not treat every failed attempt as a successful image.
The cron job fires more than once or not at all. The host may use a different cron syntax or have overlapping jobs and timezone assumptions. Use the host’s schedule preview, inspect job logs, and ensure only one active recurring job targets the capture.

Performance, reliability, and cost

  • Execution time: A screenshot takes longer when the page loads slowly or the job waits for delayed content. Set a timeout appropriate to the target and check whether your scheduler terminates long-running jobs.
  • Reliability: Record run status and alert on failures if the screenshots matter operationally. A weekly schedule can silently miss a capture if the scheduler or delivery action fails.
  • Retries: Avoid rapid repeated retries against a slow or protected site. Use the API and scheduler’s documented retry behavior, and prevent overlapping jobs if a run may exceed one week only in unusual failure scenarios.
  • Storage: Estimate the archive size from the number of URLs, image dimensions, format, and retention period. Confirm provider retention and storage limits.
  • Cost: Check whether pricing is based on capture requests, successful images, task executions, retention, or delivery. For ScreenshotNeo, only clean shots are billed; bot checks/CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. Its plans are Free: 1,000 shots/month; Starter: $5 for 3,000; Growth: $15 for 15,000; Pro: $39 for 60,000; Scale: $99 for 250,000; Business: $249 for 1,000,000. Yearly billing gives two months free, and every feature is on every plan.

FAQ

Does a cron expression specify a timezone?

Usually the timezone comes from the scheduler or host configuration, not the five cron fields shown here. Check the system that will execute the job.

Can one schedule capture on multiple weekdays?

Some schedulers allow several selected days. Confirm whether each selection produces a separate capture and how those runs are counted.

Should I capture the whole page every week?

Only if a page-wide record serves your purpose. A viewport capture can be more useful for monitoring a fixed region and may produce smaller images.

Will a visual change alert tell me what changed?

Not necessarily. A pixel comparison identifies visual differences; it may not explain their meaning or distinguish content changes from dynamic page elements.