Browser fails to launch
Chromium revision is not downloaded
Chromium revision is not downloaded
Failed to launch browser: Chromium revision is not downloaded.- Cause: Playwright needs specific browser binaries that aren’t installed.
- Fix (Docker): Rebuild the image to re-download browsers:
- Fix (NPM):
Target closed or detached
Target closed or detached
Protocol error (Target.detachFromTarget): Target closed.- Cause: The browser crashed, usually due to insufficient memory or shared memory limits.
- Fix:
- Increase Docker memory limits in
docker-compose.yml: - Figranium already passes
--disable-dev-shm-usageby default, which helps on constrained systems.
- Increase Docker memory limits in
Out of memory (ENOMEM)
Out of memory (ENOMEM)
spawn ENOMEM or Cannot allocate memory- Cause: The host machine is out of RAM.
- Fix: Restart Docker, increase swap space, or upgrade your instance.
Proxies not working
Proxy connection failed
Proxy connection failed
ERR_PROXY_CONNECTION_FAILED or net::ERR_TUNNEL_CONNECTION_FAILED- Cause: Invalid proxy credentials, wrong format, or network firewall blocking the connection.
- Fix:
- Verify the proxy format:
http://user:pass@host:portorsocks5://host:port. - Test the proxy from your server:
curl --proxy "http://host:port" https://ifconfig.me. - Check your server’s outbound firewall rules.
- Verify the proxy format:
Traffic still goes through direct IP
Traffic still goes through direct IP
- Cause: The proxy is configured but the task doesn’t have it enabled.
- Fix:
- Open the task in the Editor > Settings > Proxy tab and confirm proxy use is toggled on.
- Check
Settings > Proxiesto ensure at least one proxy is marked as active/default.
Element not found
Timeout waiting for selector
Timeout waiting for selector
Timeout 30000ms exceeded while waiting for selector ".foo"- Cause 1: The selector is wrong — the element doesn’t match the CSS you provided.
- Fix: Use Headful Debugging to open the browser and inspect the live page. Right-click > Inspect to find the correct selector.
- Cause 2: The element loads asynchronously after the page renders.
- Fix: Add a
waitaction (e.g., 2000ms) before the failing action, or use await_selectoraction explicitly targeting the element.
- Fix: Add a
- Cause 3: The element is inside a
<iframe>.- Note: Figranium does not currently support cross-origin iframes. Same-origin iframes may work via JavaScript execution.
- Cause 4: The element is inside a Shadow DOM.
- Fix: Enable Shadow DOM support in task settings, then use deep selectors.
- Cause 5: The element is only visible on desktop and the viewport is too small.
- Fix: In task settings, set a larger viewport width (e.g., 1920x1080).
Dashboard session expires frequently
Logged out repeatedly
Logged out repeatedly
- Cause 1: Sessions expire after 7 days. This is expected behavior — log in again to start a new session.
- Cause 2:
SESSION_SECRETchanges on every server restart (auto-generated secret).- Fix: Set a static
SESSION_SECRETin your.envfile:
- Fix: Set a static
- Cause 3:
SESSION_COOKIE_SECURE=trueis set but you’re accessing via HTTP.- Fix: Either access via HTTPS, or set
SESSION_COOKIE_SECURE=falsefor HTTP-only setups.
- Fix: Either access via HTTPS, or set
CAPTCHA / Bot Detection
Page shows CAPTCHA or Access Denied
Page shows CAPTCHA or Access Denied
- Cause: The target website detected automated browser behavior, or served a CAPTCHA challenge.
- Fix:
- If a supported CAPTCHA renders (reCAPTCHA v2/v3, hCaptcha, Cloudflare Turnstile), drop a Solve Captcha block at that step, or toggle Auto-Solve Captchas in the task’s Behavior tab. Figranium routes solves through a configured YesCaptcha/AntiCaptcha-compatible endpoint first and falls back to the built-in local model. See CAPTCHA Solving for setup and environment variables.
- Enable Stealth Mode options in the Task Editor (natural typing, idle movements, etc.).
- Use high-quality Residential Proxies rather than datacenter IPs.
- Rotate User Agents in
Settings > System > User Agent. - Add random
waitactions (500–2000ms) between interactions. - Avoid actions that no human would do (instant form fill, no mouse movement).
Task runs successfully in headful mode but fails headless
Headless detection or viewport mismatch
Headless detection or viewport mismatch
- Cause: Some sites detect headless browsers via JavaScript (e.g.,
navigator.webdriver). - Fix:
- Ensure Stealth Plugin is active (it is by default in Figranium).
- Check if the failure is viewport-related (some sites show different content at different sizes). Set a realistic viewport in task settings.
- Compare the page HTML in both modes using
javascriptblocks that returndocument.documentElement.outerHTML.
Data extraction returns empty or wrong results
Empty or incorrect extraction output
Empty or incorrect extraction output
- Cause 1: The extraction script runs before dynamic content finishes loading.
- Fix: Add
waitorwait_selectoractions before your final extraction step.
- Fix: Add
- Cause 2: The extraction script has a bug.
- Fix: Use a
javascriptaction in the middle of your task toreturn document.querySelector(".target")?.innerTextand inspect the result in the execution logs.
- Fix: Use a
- Cause 3: The page structure changed.
- Fix: Open the page in headful mode and re-inspect the selectors.
Execution hangs and never completes
Task hangs indefinitely
Task hangs indefinitely
- Cause 1: A
whileloop with a condition that’s always true.- Fix: Add a counter variable and a
stopcondition to break the loop.
- Fix: Add a counter variable and a
- Cause 2: A
wait_selectorwaiting for an element that never appears.- Fix: Wrap it in an
on_errorblock with a fallback, or reduce the timeout.
- Fix: Wrap it in an
- Cause 3: A download action waiting for a file that never triggers.
- Fix: Check that the target element actually initiates a download.
PostgreSQL connection fails
ECONNREFUSED or password authentication failed
ECONNREFUSED or password authentication failed
- Cause: Database connection environment variables are wrong or the database is unreachable.
- Fix:
- Verify
DB_POSTGRESDB_HOST,DB_POSTGRESDB_PORT,DB_POSTGRESDB_USER,DB_POSTGRESDB_PASSWORDin your.env. - Test connectivity:
psql -h $DB_POSTGRESDB_HOST -U $DB_POSTGRESDB_USER. - Check that the database and user exist with correct permissions.
- Figranium will fall back to file-based storage if the DB is unavailable — check server logs for the fallback warning.
- Verify
API requests return 401 or 403
API key save returns 400 (API_KEY_TOO_LONG)
Key exceeds 512 characters
Key exceeds 512 characters
- Cause: The API key you provided exceeds the 512-character limit. This applies to the system API key and all AI provider keys (Gemini, Claude).
- Fix: Use a shorter key. Standard provider keys are well under this limit — if you hit it, check for accidental whitespace or extra characters in your input.
Headful viewer shows “Connecting…” then “Disconnected” on Apple Silicon Macs
VNC viewer disconnects on Apple Silicon
VNC viewer disconnects on Apple Silicon
- Cause: An older Figranium image was published as
linux/amd64only. On Apple Silicon (M1–M4) Macs, Docker Desktop pulls that image and runs it under QEMU emulation, where Xvfb and x11vnc are prone to crashing seconds after start. The noVNC viewer connects briefly, then drops. The selector-picker SSE stream fails the same way because it depends on the same headful browser session. - Fix: Update to the latest image. Figranium is now published as a true multi-architecture image (
linux/amd64andlinux/arm64), so Apple Silicon pulls a native ARM64 build:Confirm the pulled architecture matches your host:On Apple Silicon this should printarm64. If it printsamd64, your Docker client is not selecting the ARM variant — rundocker compose pull --platform linux/arm64to force it. - If the viewer still drops: Xvfb, x11vnc, and websockify each run inside a restart loop, and the noVNC page auto-reconnects with backoff. Look at the per-process logs to see which component is crashing:
A quick post-connect drop is labeled “Browser session crashed, retrying…” in the viewer, distinguishing a real crash from a routine reconnect.
Server crashes on Render with ERR_ERL_UNEXPECTED_X_FORWARDED_FOR
Rate limiter crash behind Render proxy
Rate limiter crash behind Render proxy
- Cause: When Figranium runs behind a reverse proxy (such as Render’s edge), incoming requests carry an
X-Forwarded-Forheader. The rate limiter rejects this header unless the server is explicitly told to trust the proxy, causing the process to crash on the first authenticated request. - Fix: On Render, no action is needed — the server detects the platform-provided
RENDER=trueenvironment variable and enablestrust proxyautomatically. On other proxied deployments (Nginx, Caddy, AWS ALB, Fly.io), setTRUST_PROXY=truein your environment:See Reverse proxy andTRUST_PROXYfor the security implications of trusting forwarded headers.