How to Schedule Website Screenshots in India Using Google Cloud Mumbai

To schedule website screenshots in Google Cloud Mumbai, configure Cloud Scheduler to invoke a Cloud Run service or job in the asia-south1 region. Put headless Chrome capture code in the workload, choose a five-field cron expression and time zone, and authorize the scheduler to invoke the target. Google’s Cloud Run browser automation guidance names Puppeteer and Playwright and lists web screenshots as a use case. Cloud Run browser automation guidance.

1. Choose a Cloud Run service or job

Both patterns can run in Mumbai. Choose based on how you want the capture to start and finish:

Pattern	Invocation shape	Good fit
Cloud Run service	Scheduler sends an authenticated HTTP request to an endpoint.	Your capture is naturally an HTTP handler, or you need an endpoint to accept parameters.
Cloud Run job	Scheduler starts a job execution; the process exits when the capture finishes.	The screenshot is a bounded task that does not need an always-available request endpoint.

Google documents scheduling both a Cloud Run service and a Cloud Run job. The service tutorial uses authenticated invocation; the job path requires a service account with permission to invoke the job. Choose the execution form that matches your process lifecycle and output handling. The documentation does not establish a workload-specific cost winner between these patterns.

2. Select Mumbai and plan dependencies

Set the Cloud Scheduler location and Cloud Run workload region to asia-south1, which Google identifies as Mumbai, India. Check the location of any connected services, such as the storage destination for screenshots: Cloud Run guidance notes that using products across locations can affect latency and cost. Regional placement does not by itself guarantee a particular capture latency or browser compatibility.

3. Build the browser capture workload

Install a headless browser and a browser automation library in your container. Google’s browser automation guidance covers Puppeteer and Playwright. The example below uses Playwright with Node.js; it accepts a target URL from an environment variable, navigates to it, waits for the page load event, and writes a full-page PNG. This is illustrative workload code; adapt the browser installation and storage destination to your container and deployment.

const { chromium } = require('playwright');

async function main() {
  const target = process.env.TARGET_URL;
  if (!target) throw new Error('Set TARGET_URL');

  const browser = await chromium.launch({ headless: true });
  try {
    const page = await browser.newPage({ viewport: { width: 1440, height: 1000 } });
    await page.goto(target, { waitUntil: 'load', timeout: 60000 });
    await page.screenshot({ path: '/tmp/screenshot.png', fullPage: true });
    console.log('Screenshot saved to /tmp/screenshot.png');
  } finally {
    await browser.close();
  }
}

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

For a production workload, make the output useful after the process exits: write it to a configured storage destination or return it from a service endpoint. Cloud Run instances and job executions should not be treated as permanent local file storage. Pick a destination and retention policy that fit your use case; these are implementation choices, not requirements specified by the cited Google guides.

Capture choices to make

Viewport or full page: The example captures the full page. Long or dynamically growing pages can produce large images and longer capture times.
Wait condition: load waits for the load event. Sites that render data later may need an explicit selector wait or a measured delay; avoid waiting indefinitely for network idle on pages with persistent connections.
Timeouts and retries: Set a navigation timeout appropriate for the target. Retry transient failures a limited number of times, and record the URL and error for diagnosis. These are application-level policies.
Output names: Include a stable site identifier and capture time in the object name if you retain multiple scheduled snapshots.

4. Create the schedule

Cloud Scheduler uses five Unix-cron fields and a selected time zone. For example, 0 */3 * * * runs every three hours. Select the time zone that matches the intended operating schedule, especially if the schedule is intended to follow local Indian time. Confirm the next scheduled run in the Scheduler configuration rather than assuming the machine’s time zone controls it. See Google’s cron schedule documentation.

# Five fields: minute hour day-of-month month day-of-week
0 */3 * * *

A different cadence should use an expression that represents the desired local schedule. Consider the consequence of missed or delayed runs: a periodic screenshot is usually a snapshot, so decide whether a later run should replace a missed capture or whether each expected interval must be accounted for.

5. Configure authorization and deploy

Enable the Cloud Scheduler API in the project.
Deploy the Cloud Run service or job in asia-south1.
Create or select a service account for scheduled invocation, and grant only the permissions needed to invoke the chosen target.
For a service target, configure an authenticated HTTP request with an OIDC token and the invoking service account, following Google’s Cloud Run scheduling guide.
For a job target, configure the scheduler to start the job and use a service account permitted to invoke that job, following Google’s scheduled jobs guide.
Run an initial invocation, then inspect the Cloud Run execution or logs and confirm the screenshot reached its intended destination.

Do not make the service publicly invokable just to simplify scheduling when authenticated invocation is appropriate. The exact command-line or console fields depend on which target type you choose; use the linked Google guide for the corresponding setup.

6. Operate the scheduled capture reliably

Performance

Keep the browser workload and frequently used dependencies in the same region as the scheduler target where practical, and account for cross-location access to output storage.
Use a viewport that matches the monitoring need. Full-page screenshots of long pages can take more work and create larger outputs than viewport-only captures.
Set explicit navigation and selector timeouts. A site that never reaches a chosen wait condition can otherwise occupy an execution longer than intended.

Reliability

Log the requested URL, capture start and finish, and failure category without logging secrets or sensitive page content.
Make output handling safe for retries. For example, choose whether a retry overwrites a time-slot object or creates a separate attempt record.
Test at least one scheduled invocation and one direct/manual invocation. Confirm permissions, the browser launch, page rendering, and output access independently.
Set a deliberate policy for transient network failures, blocked pages, authentication requirements, and pages that change after the initial load.

Cost and regional limits

This workflow uses Cloud Scheduler and Cloud Run, and may use storage or other Google Cloud services for screenshot output. The research sources do not establish current prices, quotas, or a workload-specific cost comparison for a service versus a job. Check current pricing and quotas for the selected region and products before setting a high-frequency schedule. Capturing more often also means more browser executions and potentially more stored images.

7. Troubleshoot common failures

Symptom	Likely cause	What to check or change
Scheduler reports an authorization error	The configured identity lacks invocation permission, or the request authentication settings do not match the service.	Check the service account, its target-specific invocation role, and the OIDC audience and authentication settings in the Cloud Run scheduling guide.
Scheduler cannot reach the target	The target URL, region, or service configuration is wrong, or the required API is not enabled.	Verify the deployed target and enable Cloud Scheduler API; inspect the scheduler attempt details.
Browser fails to launch in Cloud Run	The container image may not include the browser or its required runtime dependencies.	Use a browser automation container setup that includes the matching browser binaries and dependencies; review the Cloud Run browser automation guidance.
Screenshot is blank or incomplete	The page may render after the selected wait condition, require authentication, or depend on client-side data.	Inspect navigation and page logs, wait for a page-specific selector, and verify access to the page in the workload’s environment.
Navigation times out	The site is slow, unavailable, or waiting on requests that do not finish.	Use an explicit timeout, choose a suitable readiness condition, and apply bounded retries only for transient failures.
Output is missing after execution	The file was written only to temporary local storage, or the workload identity cannot write to the destination.	Upload or return the screenshot as part of the task, then check destination configuration and write permissions.
Captures run at an unexpected hour	The selected schedule time zone or cron fields do not reflect the intended local time.	Check the configured time zone and five-field expression, then inspect the next scheduled run.

8. Common alternatives and when to choose them

Cloud Run is a reasonable fit when you want to run and control a browser automation workload in Google Cloud Mumbai. If you do not need to manage a browser container, a screenshot API can handle the browser capture request for you. ScreenshotNeo is a website screenshot API and MCP server; it is a useful first alternative when you want clean captures and only clean shots billed. You can call it from an existing scheduled task or another workflow that makes HTTP requests.

Or skip the browser setup

ScreenshotNeo takes a URL and returns a PNG, JPEG, WebP, or PDF. Cookie banners are accepted and 60+ known consent platforms, newsletter popups, and chat widgets are removed before the shot; each cleanup step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing state. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. One thousand screenshots a month are free with no card; paid plans start at $5 for 3,000.

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. Create a free account at ScreenshotNeo sign-up to get 1,000 screenshots a month with no card.

FAQ

Can Cloud Scheduler run a Playwright screenshot job in Mumbai?

Yes. The documented approach is to schedule a Cloud Run service or job in asia-south1, with the browser workload running in Cloud Run and an authorized identity invoking it.

Does choosing Mumbai guarantee the screenshot is generated in India?

The Scheduler and Cloud Run resources can use the Mumbai region. The cited sources do not establish where every external website processes a request or guarantee end-to-end data locality.

Should I use a service or a job for one screenshot per schedule?

Use the execution shape that fits your code: an HTTP handler for a service, or a bounded process that starts and exits for a job. Both scheduled patterns are documented.

Where can I verify region availability and scheduling behavior?

Check Google’s current Cloud Scheduler locations and Cloud Run locations pages, along with the scheduling guides linked above.