Loki Cannot Launch Chrome: Troubleshooting Browser and Binary Errors
A Chrome launch error may come from Grafana’s renderer or another browser tool, not Loki. Identify the failing process, then fix its binary, cache, or runtime configuration.
Why can’t Loki launch Chrome? First identify which process emitted the error. A Chrome launch failure alone does not show that Loki ingestion, storage, or LogQL is broken. Dashboard rendering may use Grafana Image Renderer; browser automation may use Grafana k6 or another tool. Each has its own browser installation and configuration. Grafana’s Loki data-source troubleshooting guide covers data-source connection, query, and configuration problems, not troubleshooting the Loki service itself. Grafana’s Loki data-source troubleshooting guide and image-rendering troubleshooting guide address different failure paths.
1. Identify the component that launches Chrome
Record the exact message and the action that triggers it: dashboard export, alert image rendering, a k6 browser script, or a Loki query. Also note component and version, deployment type, operating system, and the operating-system account that runs the process. A message that says Chrome is missing points toward the launcher’s browser setup; a Loki connection or query error needs a separate investigation.
| Where it happens | Likely area to investigate |
|---|---|
| Grafana dashboard image export or rendering | Grafana Image Renderer browser installation, path, cache, dependencies, or runtime security settings |
| k6 browser automation | k6 browser installation and its executable-path configuration |
| Loki data-source query or connection | Loki URL and API path, tenancy header, credentials, network access, TLS, query syntax, or WebSocket configuration as applicable |
| A Loki executable or extension reports a browser error | Identify the exact extension or process and follow documentation for that component and version; the sources here do not establish a Chrome-launch procedure for Loki itself |
2. Check the browser in the launcher’s runtime
Check from inside the renderer, container, or service environment, using the same operating-system account that starts the browser. Confirm the executable exists, is executable by that account, matches the runtime architecture, and can access its required system libraries. A browser installed on a host is not necessarily present or visible inside a separate container.
Grafana Image Renderer can use Chromium, Google Chrome, Microsoft Edge, Brave, and other Chromium-based browsers that support Chrome DevTools Protocol. Grafana states: “Only Chromium is officially supported.” For the most directly supported setup, use Chromium; compatibility with other browsers is not the same as official support. See the renderer troubleshooting documentation.
Set the renderer’s browser path
If automatic browser discovery fails, configure the renderer with --browser.path set to the actual executable path in that runtime. For example, if the executable is at /usr/bin/chromium, use this argument when starting the renderer:
grafana-image-renderer --browser.path=/usr/bin/chromiumThis example assumes the executable really is at that path and that the process can run it. Paths vary by image, package, operating system, and installation method. Check the executable inside the service environment rather than copying a path from another machine.
3. Resolve missing browser and cache errors
If the message says the browser or a particular version cannot be found, check that the browser expected by the installed renderer or automation tool was installed. For Puppeteer-based setups, inspect the cache path using the service account: a browser downloaded under one user’s cache may not be visible to another. Confirm that the configured cache directory matches the actual installation and is readable by the process.
A historical renderer issue reported Could not find Chrome (ver. 116.0.5845.96) and named both a missing installation and a misconfigured Puppeteer cache path as possible causes. That version and cache path are diagnostic examples from that report, not current universal defaults. See the Grafana Image Renderer issue tracker and verify requirements for the version you run.
4. If Chrome exists but will not start
A found executable can still fail at launch. Read the full renderer or automation log and identify the failure stage before changing security settings. Look for sandbox, namespace, shared-memory, missing-library, or permission errors. In containers and Linux service environments, inspect the applicable seccomp and AppArmor profiles, capabilities, virtualization features, and filesystem permissions. Grafana’s image-rendering troubleshooting guide discusses these environment-specific considerations.
Grafana Image Renderer provides a --browser.sandbox option and supports custom browser flags. Do not treat --no-sandbox as a universal repair: it changes browser security behavior and will not fix a missing binary, a bad path, or an unrelated dependency problem. Use the setting only when the concrete error and deployment guidance call for it.
5. Use the path setting for the right tool
Browser configuration names are tool-specific. For Grafana Image Renderer, the documented executable-path option is --browser.path. For Grafana k6 browser, the documented override is K6_BROWSER_EXECUTABLE_PATH. Do not copy one component’s setting into another component’s configuration; confirm the exact product and version first. See the Image Renderer documentation and k6 browser options.
6. Troubleshooting checklist
- Capture the exact error. Preserve the full message and nearby logs, with secrets redacted.
- Name the launcher. Determine whether it is Image Renderer, k6 browser, another automation tool, or a Loki process or extension.
- Check versions and deployment. Record relevant component versions, operating system, package or container image, and runtime account.
- Verify the executable in context. Check its path, permissions, architecture, and dependencies from inside the process’s runtime.
- Check discovery and cache. Confirm the tool expects that browser version and that its cache or installation path is accessible to the service account.
- Separate launch from runtime restrictions. If the binary exists, inspect sandbox and container security errors before changing flags or permissions.
- Keep Loki diagnostics separate. If the failure is actually a data-source or query issue, investigate its URL, credentials, network, TLS, tenancy, query, or WebSocket configuration instead.
7. Common errors and fixes
| Symptom | Likely cause | What to check |
|---|---|---|
| “Could not find Chrome” or executable not found | Browser is not installed where the launcher runs, or discovery points to the wrong place | Install a compatible browser in that runtime; for Image Renderer set --browser.path to its real path |
| Error names a specific Chrome version | Installed browser and tool’s expected browser or cache do not match | Check the installed tool version, browser version, and cache path for the service account; do not assume an old issue’s version is a current requirement |
| Binary exists but launch is denied | Permissions or container security restrictions prevent startup | Check the runtime account, executable permissions, logs, security profile, and required capabilities |
| Browser process starts and immediately exits | Possible missing system library, shared-memory constraint, incompatible architecture, or sandbox issue | Use the full process logs to identify the failure; verify runtime dependencies and deployment-specific requirements |
| Changing a path variable has no effect | The setting belongs to a different browser tool or is not applied to the process that launches the browser | Confirm the component and version, then configure its documented path option |
| Loki query still fails after browser setup | The query or data-source connection is a separate problem | Return to Loki data-source diagnostics; browser configuration will not correct URL, auth, TLS, network, or query issues |
8. Performance, reliability, and cost considerations
Browser launch troubleshooting is primarily about a reliable runtime, not a LogQL performance setting. Keep the browser installed in the same immutable image or environment as the launcher, use a stable executable path, and ensure the service account’s cache and permissions survive restarts. This avoids host-versus-container mismatches and user-specific cache surprises. For renderer performance or resource sizing, use the documentation for the exact renderer version and deployment; the sources here do not provide benchmark numbers or a universal resource recommendation.
Changing browser flags or sandbox controls can affect security and reliability, so tie each change to a logged failure and validate it in the same deployment context. No browser-launch cost benchmark is established by the research sources; avoid inferring cost from the error itself.
Or skip the browser setup
If your goal is to capture a website rather than render a Grafana dashboard, ScreenshotNeo provides a website screenshot API and MCP server. One GET request returns a PNG, JPEG, WebP, or PDF. It handles browser setup for the capture, removes cookie banners, newsletter popups, and chat widgets before the shot, and bills only clean shots: bot checks, blank pages, failed loads, timeouts, and cache hits cost nothing. Responses identify the page verdict and billing status in headers. Its MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf. The free plan includes 1,000 shots per month with no card; paid plans start at $5 for 3,000 shots. 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.webpimport 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}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);Replace YOUR_API_KEY with your key. The Python and Node.js examples save the returned body as provided; select the output format using the API’s documented options when needed. This is for website captures, not a fix for Grafana dashboard rendering.
Sign up free for 1,000 screenshots a month, with no card required.
FAQ
Does a Chrome launch error mean Loki is down?
No. It identifies a browser-launch failure in whichever process emitted it. Establish the component before diagnosing Loki availability.
Can I use Google Chrome instead of Chromium with Grafana Image Renderer?
Grafana lists Chromium-based alternatives as technically compatible, but Chromium is the officially supported browser.
Should I always disable the browser sandbox in a container?
No. First identify the specific launch restriction in the logs and follow the security requirements for that deployment.
What details should I include when asking for help?
Include the exact redacted error, reproduction steps, component and version, deployment method, operating system, and relevant redacted configuration. Grafana’s Loki troubleshooting guidance also recommends useful version, error, reproduction, and configuration details for unresolved data-source issues.
