ScreenshotNeo

BlogHow-to

How to Schedule Recurring Website Screenshots with Cloudinary

Cloudinary can capture webpages through URL2PNG, but a separate scheduled job must request the capture URL. Here’s how to build the workflow safely.

By the ScreenshotNeo team4 October 20267 min read

Direct answer: Cloudinary documents webpage screenshots through its URL2PNG delivery type, but the reviewed documentation does not describe a built-in recurring screenshot scheduler. Schedule an external job to request the signed screenshot delivery URL at your chosen interval. The screenshot is generated when that URL is opened; creating the URL alone does not trigger a capture. Confirm URL2PNG is currently available for your account before building around it. Cloudinary’s CLI documentation describes the request-triggered behavior, and its URL2PNG article describes the screenshot workflow.

How the scheduled Cloudinary workflow works

  1. Choose a target page and capture URL. Build a URL2PNG delivery URL using Cloudinary’s documented format and parameters.
  2. Sign or authenticate it on a trusted backend. Keep Cloudinary credentials and signing secrets off the client. Restrict which target URLs your job is allowed to capture.
  3. Schedule a job outside Cloudinary. Use cron, a hosted scheduler, or an application job. Treat that scheduler as the cadence mechanism; the reviewed Cloudinary material establishes screenshot delivery, not recurring scheduling.
  4. Have the job request the URL. The request is the capture trigger. Merely preparing or storing the URL does not generate the derived screenshot asset.
  5. Choose an asset naming and retention policy. Use a stable name if the latest capture should replace the previous one, or a timestamp/version strategy if you need a history for comparisons. The cited materials do not prescribe a recurring-capture retention scheme.
  6. Observe the job. Record when it ran, the target, the result, and failures so you can tell a missed schedule from a page that changed or a capture request that failed.

Check URL2PNG availability first

The CLI documentation still lists url2png as a delivery type, while the detailed how-to is older. The research for this guide did not verify current account entitlement, add-on availability, or plan terms. Before committing to the integration, check whether URL2PNG can be enabled for your Cloudinary account and what current requirements apply.

Build the capture URL and trigger it

Use Cloudinary’s URL2PNG delivery format and signing procedure from its documentation for your account. The exact signed URL depends on your Cloudinary cloud name, URL2PNG configuration, target page, and capture options; use the documentation’s signed example rather than constructing an unsigned arbitrary-URL endpoint. Signing should happen in a trusted server-side component. The scheduler should invoke that component or securely receive a URL produced by it.

A minimal scheduler task has this shape, independent of the scheduler vendor:

# Pseudocode for the scheduled task
# 1. Ask your trusted backend to create an approved, signed URL2PNG delivery URL.
# 2. Request that URL so Cloudinary performs the screenshot capture.
# 3. Check the HTTP result and record success or failure.
response = request(signed_capture_url)
if response.status is not successful:
    record_failure(response.status)
else:
    record_success(capture_time, response.asset_url)

This is intentionally pseudocode: the cited sources do not establish a scheduler product, its SDK, or a universal URL2PNG endpoint for every account. Follow Cloudinary’s current URL2PNG documentation to form and sign the actual delivery URL.

Schedule it with cron or another external runner

For a self-managed server, cron can invoke a script at a fixed interval. For a managed runtime, use its scheduler or a job in your application. These are orchestration choices, not Cloudinary features established by the cited documentation.

# Example: run a local capture script every day at 06:15 UTC
15 6 * * * /usr/bin/python3 /srv/jobs/capture_page.py

Make the script call your backend capture endpoint, or securely obtain the signed URL at runtime. Do not put a long-lived Cloudinary secret in a browser bundle, public repository, or scheduler command line that may be visible to other users. Store secrets in the execution environment’s protected secret store where available.

Decide what a run means

  • Cadence and timezone: specify the intended timezone and whether the schedule follows local time or UTC. Check how your scheduler handles daylight-saving changes.
  • Timeout: allow for page loading and screenshot generation, and set a bounded timeout appropriate to the scheduler’s execution limit.
  • Retries: retry transient network or service errors with a limit and delay. Avoid unlimited rapid retries, which can create duplicate work.
  • Overlap: prevent a second run from starting if a slow capture from the previous interval is still active, unless overlapping captures are intentional.
  • Naming: select a predictable asset identifier. A stable identifier is convenient for “latest screenshot”; time-based identifiers preserve snapshots for history.
  • Retention: decide whether to keep every result or overwrite a stable asset, and account for your storage and delivery needs. The researched sources do not specify retention behavior for this recurring use case.

Use transformations and serve the result

Cloudinary’s image transformations can resize, crop, and otherwise transform delivered image assets. Its SDK helpers can build delivery URLs and image tags. These operations affect how an image is delivered; they do not schedule a fresh webpage capture. Keep the schedule trigger, screenshot delivery request, and any later transformation or embedding as distinct steps. See Cloudinary image transformations and the Cloudinary API reference.

If the screenshot URL is dynamically signed, generate it server-side for the intended use and keep signing credentials private. Cloudinary documents authenticated API and signed dynamic URL approaches; those are controls for the delivery workflow, not a complete security design for every scheduler. Restrict the page targets your own application accepts so an exposed capture endpoint cannot be used to request arbitrary remote pages.

Reliability, performance, and cost considerations

  • Request-driven capture: a scheduler must actually request the URL. A generated link that nobody opens is not a scheduled capture.
  • Page variability: dynamic content, consent prompts, authentication, and network conditions can affect what a capture shows. The reviewed sources do not provide latency or reliability benchmarks for scheduled jobs.
  • Retries and idempotency: decide whether a retry should overwrite the same “latest” asset or create a distinct historical item. Log enough information to identify duplicate or missing runs.
  • Delivery transformations: transformations can produce the dimensions or crop needed by your application, but account for your own delivery and storage requirements.
  • Commercial terms: no current URL2PNG price or entitlement was verified for this article. Confirm the current add-on and account terms directly with Cloudinary before estimating cost.
  • Monitoring: alert on repeated failures or missed runs. A scheduler’s successful launch does not by itself prove that the screenshot request created the expected image.

Troubleshooting

Symptom Likely cause What to do
No screenshot appears The delivery URL was created but never requested, or the scheduled task did not run. Check scheduler execution logs and make the task request the signed capture URL. Cloudinary documents that the derived asset is generated when the URL is opened.
URL2PNG delivery fails URL format, signing, configuration, or account availability may be wrong. Verify current URL2PNG availability and follow the current Cloudinary URL2PNG and CLI documentation for URL construction and signing.
Signature or authorization error The URL was altered after signing, signed with the wrong credentials, or built outside the documented process. Generate the URL on the trusted backend and pass it unchanged to the requester. Keep the API secret private.
The job succeeds but the expected asset is missing The job may only have generated the URL, or it may not have checked the response and resulting asset. Confirm the task makes the HTTP request and records the response. Verify the delivered asset identifier and naming strategy.
Different runs appear to overwrite one another The job uses a stable asset name. Use a timestamp or versioned identifier when history is required; use a stable identifier when only the latest result is needed.
Runs are late or overlap A capture takes longer than the interval or the runner has queue/execution constraints. Set a bounded timeout, monitor duration, and configure a concurrency or overlap policy in the scheduler.
Capture contains unexpected page content The page changed, loaded asynchronously, required a session, or showed a prompt. Check the target page in the same access context and verify which URL2PNG options your current account supports. The cited sources do not establish specific wait or session options for this workflow.

Or skip the browser setup

If the goal is a recurring screenshot rather than specifically using Cloudinary URL2PNG, ScreenshotNeo provides a website screenshot API and MCP server. Schedule an external job to call the API at the cadence you need; use its response as the screenshot output. See the ScreenshotNeo API documentation.

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}`);
  • Cookie banners are accepted and removed, along with known newsletter popups and chat widgets, before the screenshot.
  • Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed; response headers report the page verdict and billing status.
  • An MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs.
  • The free plan includes 1,000 screenshots a month with no card. Paid plans start at $5 for 3,000 screenshots.

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

FAQ

Can Cloudinary take website screenshots automatically on a schedule?

The reviewed sources document URL2PNG screenshot delivery, not a recurring scheduler. An external job must request the capture URL on the cadence you choose.

Does creating a URL2PNG URL create the screenshot?

No. The CLI documentation warns that the derived asset is not generated until the URL is opened.

Can I use Cloudinary transformations to set the schedule?

No. Transformations change delivered image output. Scheduling is a separate orchestration step.

Is URL2PNG available on every account?

This research did not verify current availability or account requirements. Check with Cloudinary before relying on it.