How to Fix Scheduled Chrome Screenshots That Fail With a Browser Crash
Is Chrome crashing only on scheduled screenshot runs? Compare the browser, flags, user, and launch context to isolate the failure before changing capture settings.
If Chrome crashes only when a screenshot runs on a schedule, first compare the scheduled launch with a manual launch: identify the exact process that exits, Chrome binary and version, command-line flags, operating-system user, and service context. Run that same binary with the same flags from a normal-user command prompt, then launch Chrome directly from the scheduled environment without WebDriver. This separates browser startup, service-context, and automation-driver problems before you change screenshot timing or viewport settings.
On Linux, check whether the job runs as root. Chrome documents root execution as a common startup-crash cause and recommends running Chrome as a regular user. Do not treat --no-sandbox as a routine fix: Chrome describes it as unsupported and highly discouraged. The title does not identify your scheduler, OS, framework, or crash message, so use the steps below to isolate the cause rather than assume one.
1. Identify which process is crashing
A screenshot pipeline can involve a scheduler, your script, ChromeDriver, and Chrome. A process can exit or close while another remains healthy. Record the process name and exit status from scheduler logs, and capture standard output and standard error. In a WebDriver setup, inspect the ChromeDriver log to confirm the Chrome binary path.
| Observed failure | First diagnostic |
|---|---|
| Chrome process exits at startup | Run Chrome directly with the same executable and flags. |
| Chrome works manually but not as a scheduled task | Compare account, service context, working directory, environment, and permissions. |
| Chrome starts, then the automation session fails | Determine whether Chrome or ChromeDriver exits first; inspect driver logs. |
| Capture succeeds but image is blank, early, or clipped | Investigate page readiness, timeout, virtual time, and viewport separately. |
Chrome’s troubleshooting guide recommends verifying the binary path from the ChromeDriver log, using the same switches in a normal-user command prompt, and then testing direct Chrome launch from the test environment. ChromeDriver: Chrome doesn’t start.
2. Compare the manual and scheduled launch contexts
- Save the scheduled command. Record the executable path, version, all flags, scheduler-configured user, working directory, and exit status. Preserve the actual argument list; shell quoting can cause a scheduled command to differ from the command you typed manually.
- Run the same binary and switches manually. Use a normal-user command prompt and the exact executable path shown in the driver log. If Chrome fails in this simple launch too, verify the installation and consider reinstalling Chrome, as the official troubleshooting guide suggests when Chrome itself cannot start.
- Launch Chrome directly from the scheduled environment. Temporarily bypass WebDriver or the browser automation wrapper while keeping the same user and service context. If direct Chrome launch fails, the problem is below the screenshot or WebDriver layer.
- Compare the account and environment. Check whether the scheduled task runs under a different account, as a service, or with different file access and environment settings. If Chrome starts in a normal user session but not the background service, isolate that context difference. Chrome’s guide notes that its alternate installer, which installs for all users, can often fix background-service issues.
3. Check Linux root execution and sandboxing
If the scheduled job runs on Linux, verify the effective user of the Chrome process, not just the user configured in a wrapper. Chrome identifies running as root as a common startup-crash cause and recommends configuring the environment to run Chrome as a regular user. See Chrome’s startup troubleshooting guidance.
Avoid making --no-sandbox the permanent workaround. Chrome says this setup is unsupported and highly discouraged. Configure the scheduler or service to run the browser as a regular user instead. If you are diagnosing an existing setup that includes the flag, record it as part of the command and test the intended user context before drawing conclusions.
4. Confirm which Headless Chrome you are running
Current Chrome Headless mode uses --headless. Since Chrome 112, Headless has shared Chrome’s regular implementation: it creates platform windows without displaying them. Starting with Chrome 132.0.6793.0, the old Headless implementation is available only as the separate chrome-headless-shell binary. Check the installed version and executable instead of assuming that an old Headless command or flag still applies. Chrome Headless mode.
The old shell documentation is marked deprecated. Treat examples from it as historical context and verify flags against the binary your scheduled job actually invokes. A version or binary mismatch can explain why a command behaves differently after a deployment, but it does not by itself prove the reason for a crash.
5. Run a minimal direct screenshot command
Once you have confirmed the executable and Headless implementation, make a minimal direct launch from the same environment. This example captures a page to screenshot.png in the working directory and sets the viewport to 1440 by 1000 pixels:
google-chrome --headless --screenshot --window-size=1440,1000 https://example.comReplace google-chrome with the exact binary path used by the job. This is a diagnostic starting point, not a universal scheduled-task configuration: the installed binary name, required environment, and scheduler vary. If this direct command crashes in the scheduled context, investigate startup and account differences before restoring the automation framework.
6. Tune capture timing and dimensions only after Chrome starts
Chrome’s command-line reference documents these capture options:
| Option | What it controls | When to investigate it |
|---|---|---|
--screenshot |
Saves a screenshot as screenshot.png in the working directory. |
The browser starts but no screenshot file is produced; also check working-directory write access. |
--window-size=WIDTH,HEIGHT |
Sets the viewport dimensions. | The screenshot is clipped or has unexpected dimensions. |
--timeout=MS |
Sets the maximum wait before screenshot, DOM, or PDF capture. | The page needs more time before capture or the capture waits too long. This is a capture wait limit, not a process-stability fix. |
--virtual-time-budget=MS |
Allows time-dependent page scripts to run under virtual time. | The page changes after load due to timers or other time-dependent scripts. |
For example, to allow up to 10 seconds before capture, use --timeout=10000; to set a 5-second virtual-time budget, use --virtual-time-budget=5000. These values are examples, not universal recommendations. Adjust them to the page and the behavior you need. Chrome documents these settings in its Headless command-line reference. They can change what or when Chrome captures, but they do not establish or repair a Chrome process crash.
7. Troubleshoot by symptom
| Symptom | Likely area to check | Next action |
|---|---|---|
| Chrome crashes in the scheduled run but starts interactively | Different service account or launch context | Run Chrome directly under the scheduler’s context and compare it with a normal-user launch. |
| Chrome crashes on Linux when started by a privileged service | Root execution and sandboxing | Configure the job to run as a regular user; do not rely on --no-sandbox as a standard fix. |
| The browser works in a shell but the WebDriver job fails | Driver harness, selected binary, or arguments | Check the ChromeDriver log for the executable path and preserve the exact switches in a direct-launch reproduction. |
| Chrome starts but the screenshot is blank or captures too early | Page readiness or capture timing | Adjust --timeout or, for time-dependent scripts, --virtual-time-budget. |
| Screenshot content is cut off or the viewport is wrong | Viewport dimensions | Set the intended --window-size and check whether the page itself scrolls. |
| The old Headless flags no longer work | Chrome version or binary changed | Check whether the job invokes current Chrome with --headless or the separate shell binary introduced for old Headless from Chrome 132.0.6793.0. |
| ChromeDriver itself crashes | Driver process, distinct from Chrome | Use the ChromeDriver crash guidance and build a reproducible driver failure. Its documentation explicitly distinguishes ChromeDriver crashes from Chrome crashing or closing. ChromeDriver crash troubleshooting. |
8. Keep a reliable scheduled capture
- Log the Chrome executable path, version, flags, effective user, working directory, start and end times, exit code, and which process failed.
- Use the same Chrome binary and arguments in diagnostic runs that the scheduled job uses.
- Separate browser startup failures from page-load and capture-quality issues; only tune capture waits after Chrome launches successfully.
- After changing the Chrome version, package, service account, or Headless binary, rerun the direct-launch check in the scheduled context.
- Do not infer a universal cause from the fact that failures occur on a schedule. The scheduler, OS, framework, and crash message determine the next branch of diagnosis.
Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request takes a URL and returns a PNG, JPEG, WebP, or PDF. It can remove cookie and consent banners, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and the response reports the page verdict and billing status in headers. AI agents can use its MCP tools, including take_screenshot, get_page_info, and capture_pdf. Every feature is available on every plan. See the ScreenshotNeo website and API documentation.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o shot.webpimport requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://example.com"},
timeout=90,
)
open("shot.webp", "wb").write(r.content)const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);It avoids maintaining your own browser launch for these captures, removes cookie banners, popups, and chat widgets before the shot, and does not bill bot checks, blank pages, or failed loads. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000.
Sign up for 1,000 free screenshots a month, with no card required.
FAQ
Does Headless Chrome need a display server?
Current Chrome Headless runs without displaying a visible UI. Since Chrome 112, it shares the regular Chrome implementation while keeping its windows hidden. Your scheduler and operating-system environment still need to be configured so the browser process can start.
Should I increase the screenshot timeout to stop Chrome crashing?
No. A longer capture wait may help a page that loads slowly, but it does not fix a Chrome process that exits during startup.
How can I tell whether ChromeDriver is the process that failed?
Check the process exit and driver logs. ChromeDriver’s crash guidance covers the driver process and distinguishes its crashes from Chrome crashing or closing.
What details should I include when asking for help?
Include the operating system, scheduler, Chrome and ChromeDriver versions, exact Chrome path and flags, configured and effective user, exit status, relevant logs, and whether direct Chrome launch succeeds in the scheduled environment.
