How to Schedule Recurring Website Screenshots with Thumbalizr
Thumbalizr’s API can generate screenshots, but its reviewed docs don’t describe a recurring scheduler. Use an external scheduler, request fresh captures, and monitor each result.
How do I schedule recurring website screenshots with Thumbalizr? The reviewed Thumbalizr documentation describes screenshot generation through an authenticated API, but not a built-in recurring schedule. Set up an external scheduler to send a Thumbalizr API request at the interval you choose, use a changing timestamp when you need a fresh thumbnail, and check the response status and error headers after every run. The scheduler examples below are implementation patterns based on the API documentation; Thumbalizr does not document or endorse a particular scheduler.
How the recurring workflow works
A scheduled screenshot is a small automation pipeline:
- Store your Thumbalizr API credentials securely.
- Choose a scheduler that can run a script at your desired cadence.
- At each run, construct a valid authenticated request with the target URL and capture options.
- Use a fresh
timestampvalue if each run should generate a new thumbnail. - Inspect the response headers and save or forward the image only when the request succeeds.
- Log failures and configure the scheduler to retry or alert you according to your needs.
The scheduler is responsible for recurrence. The API request is responsible for asking Thumbalizr to generate a screenshot. Your script or surrounding workflow decides where to store the resulting image; the reviewed documentation does not prescribe a universal retention or storage system.
1. Get credentials and choose a schedule
Create or use a Thumbalizr account and obtain the API key and secret from the member area as described in the Thumbalizr API documentation. Keep credentials in a secret manager or protected environment variables. Do not commit them to source control or place them in a public URL.
Choose an external scheduler based on how often you need captures and where the job should run. A machine you already operate can run a scheduled script; a hosted scheduler can run it without your computer being on. These are general implementation choices, not Thumbalizr-endorsed integrations. Consider setup effort, whether the runner is available at the scheduled time, retry and alert features, where outputs are stored, and ongoing maintenance or hosting cost.
Before enabling the job, estimate monthly usage:
captures per month = URLs × runs per day × days per month
For example, one URL captured once per hour is about 720 capture requests in a 30-day month. Check your account’s current quota and feature entitlements against your actual schedule. The Thumbalizr features page currently displays Free, Silver, Gold, and Platinum allowances of 100, 2,000, 3,000, and 5,000 or more screenshots per month, respectively; prices and included features vary by plan and can change. Verify the live Features & Pricing page before relying on a particular allowance.
2. Make a fresh Thumbalizr API request
The API reference documents request authentication and capture parameters, including width, timestamp, watermark, full-page or screen capture, delay, browser dimensions, and country. Use only parameters available to your account, and check the current API table for exact names, accepted values, and plan availability.
When a recurring run must produce a new thumbnail, set timestamp to a changing value such as the current date and time. The API documentation says any value can be used and recommends a current-date style value. A constant value may allow an old thumbnail to be reused instead of requesting a fresh generation.
The reference includes language-library examples. The following cURL pattern shows the operational pieces; replace the endpoint and authentication fields with the exact format in the current API documentation, and do not put secrets into shell history or shared logs:
# Set credentials in your environment or secret manager first.
# Follow the current Thumbalizr API docs for the exact signed URL and parameters.
# Include a changing timestamp for a fresh thumbnail on each scheduled run.
curl --fail-with-body --silent --show-error \
"SIGNED_THUMBALIZR_API_URL_WITH_TARGET_AND_CURRENT_TIMESTAMP" \
--output screenshot.jpg
Thumbalizr’s API uses authenticated requests. Do not treat the illustrative placeholder above as a complete signature algorithm: use the API documentation’s signing instructions and its current language-library examples to build a valid request. The dossier does not provide the signing formula or a complete request URL, so supplying invented code for that part would be unreliable.
3. Run it on a schedule and monitor the response
Configure your chosen scheduler to invoke the request script on a cadence that fits the use case. For example, a daily visual archive could run once per day, while a frequent change monitor might run hourly. Ensure the scheduler’s timezone and the timestamp’s timezone are understood, especially around daylight-saving changes if the scheduler uses local time.
Inspect the response headers documented by Thumbalizr:
| Header | What it tells you | How to use it |
|---|---|---|
X-Thumbalizr-Status |
QUEUED, OK, or FAILED |
Record the state. Treat QUEUED as not yet complete; follow the API’s documented retrieval or polling behavior. |
X-Thumbalizr-Generated |
The generation date | Log it so you can tell whether the output corresponds to the intended run. |
X-Thumbalizr-Error |
A failure reason | Include it in an error log or alert, while avoiding disclosure of credentials. |
Do not assume that an HTTP response alone means the image is ready. Check the Thumbalizr status header and the current API documentation for how queued jobs should be handled. Save the resulting image with a predictable timestamped name or pass it to your own storage and reporting workflow.
4. Choose capture options deliberately
The API reference lists options and plan availability. Review the live parameter table before configuring a production schedule, since feature access can differ by plan.
- Width and browser dimensions: Use a consistent viewport when comparing captures over time. A changed viewport can look like a site change.
- Full-page or screen capture: Choose whether you need the visible viewport or the complete page. Full-page output may be larger and take longer to generate.
- Delay: A delay can give client-rendered content time to appear. Keep it only as long as the page requires; excessive waits increase runtime.
- Country: Use a country option only when you need to observe a region-specific version and your plan supports it.
- Watermark: Check whether the option is available and whether the resulting image suits your archive or downstream use.
- Timestamp: Vary it per invocation when freshness matters, and record the value alongside the output.
Make the capture configuration stable across runs. If you change parameters, record the change so later screenshots remain interpretable.
Reliability, performance, and cost
Reliability
- Log each scheduled invocation, target URL, timestamp, status, generation date, and error reason.
- Handle
QUEUEDseparately fromOKandFAILED; a queued job is not a successful saved image. - Use bounded retries for transient failures, with a delay between attempts. Avoid tight retry loops that can create extra requests or overload your scheduler.
- Send an alert after repeated failures or when a run produces no completed image. Keep the alert useful by including the target and status without including secrets.
- Decide how long to retain screenshots and where to store them. Thumbalizr’s reviewed documentation does not establish a required storage method or universal retention policy.
Performance
Capture duration depends on the target page and selected options; the reviewed sources provide no universal timing benchmark. Full-page capture and additional delay can increase job duration. If you schedule many URLs, avoid launching an unbounded burst of jobs: stagger runs or limit concurrency according to your account limits and scheduler capacity. Allow enough time for queued work to finish before the next run.
Cost and quotas
Calculate expected monthly volume before scheduling and compare it with the current plan quota. Include retries and any extra URLs in the estimate. The live Features & Pricing page lists plan-specific prices, allowances, and feature distinctions; verify it before publication or purchase because these details are volatile. Do not assume that a parameter shown in the API reference is included in every tier.
Troubleshooting
| Symptom | Likely cause | What to check |
|---|---|---|
| Request is rejected or authentication fails | Missing, invalid, or incorrectly signed credentials | Recheck the member-area key and secret, signing steps, encoded URL, and current API examples. Keep credentials out of logs. |
Status is QUEUED but no image is saved |
The request was accepted for processing but generation has not completed | Use the API’s documented queued-job handling and retrieval behavior; do not treat queue acceptance as completion. |
Status is FAILED |
The API could not generate the requested capture | Read X-Thumbalizr-Error, verify the target URL and options, and retry only after addressing the reported cause. |
| Repeated runs return an old thumbnail | The request may reuse a prior result | Send a changing timestamp value for each run and confirm the generated date header. |
| Scheduled job works manually but not unattended | The scheduler environment may lack credentials, network access, or the expected working directory | Configure secrets and paths in the scheduler environment, and log a safe summary of the request and response. |
| Captures are missing or late | The runner did not start on time, the job exceeded its runtime, or queued work was not followed through | Check scheduler history, execution limits, queue handling, and timezone configuration. |
| Monthly allowance is reached sooner than expected | Cadence, URL count, retries, or manual runs exceed the estimate | Recalculate URLs × runs per day × days, include retries, and verify the current plan quota and feature entitlements. |
Thumbalizr service context
Thumbalizr’s announcement dated April 8, 2026 described a progressive transition from a Browshot-powered backend to ScreenshotCenter. It said newly created accounts would use ScreenshotCenter first, followed by a phased migration of existing accounts, and that thumbnails, settings, and API usage were expected to continue working as before. That announcement describes a rollout plan, not proof of its current completion. Check the live API documentation for current behavior.
Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server. Its API can return a screenshot or PDF, and its documented options include scheduled-workflow building blocks such as caching and async jobs. For a one-off capture, the cURL request is:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
See the ScreenshotNeo API documentation for request options. 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 take screenshots. The Free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.
Sign up for ScreenshotNeo’s free plan to try 1,000 screenshots a month with no card.
FAQ
Does Thumbalizr include a recurring scheduler?
The reviewed API documentation describes screenshot generation, not a built-in recurring scheduler. Use an external scheduler to invoke the API repeatedly.
How do I make sure every run creates a new image?
Send a changing timestamp value with each request and check X-Thumbalizr-Generated to confirm the generation date.
Can I use any scheduler?
Use a scheduler that can securely provide credentials, execute the request at the needed cadence, and expose logs or failure notifications. Thumbalizr’s reviewed pages do not endorse a particular scheduler.
Where should I keep the screenshots?
That depends on your workflow. The reviewed documentation does not mandate a storage destination or retention period, so choose and operate storage separately from the capture request.


