Skip to main content
This reference lists the error codes Bright Data Scraper Studio returns when a crawl, parser, request, validation or delivery step fails during a collection run, and the suggested action for each one. Read the error_code, status_code and raw error message together to understand what failed and what to do next.
These are Scraper Studio collection errors, not API authentication or API request errors. For proxy-layer HTTP errors returned outside Scraper Studio, see the Error catalog.

How do I read a Scraper Studio error?

Scraper Studio uses five system fields to describe the status of each record. Branch on error_code rather than on the raw error string, because the message text changes as scrapers are updated:

What do the Scraper Studio status codes mean?

status_code summarizes the crawl result as an HTTP-like numeric value.
status_code is sometimes missing or undefined, because some error paths do not assign a numeric status code. Treat status_code as optional and do not assume it is always present.

How do errors and warnings differ?

An error means the record failed. A warning means the record was delivered but something should be reviewed.
  • Error: the record failed and should be treated as unsuccessful. A failed record usually includes error, error_code and status_code
  • Warning: the record was delivered, but something should be reviewed. A delivered record with a non-fatal issue usually includes warning, warning_code and status_code
  • Successful record: none of error, error_code, warning or warning_code is populated
Warnings occur when a partial crawl returned data but also hit an issue, when a normally failing condition was configured as a non-error, or when output validation found an issue but the record was still kept. When a dead_page error is downgraded to a warning, the output includes:
Schema validation warnings usually use:
The same underlying issue can appear either as an error or as a warning, depending on the scraper logic, validation rules and output schema settings.

Where do Scraper Studio errors come from?

Scraper Studio errors come from one of three layers.

What causes scraper errors?

Scraper errors come from the scraper’s interaction code, parser code or input handling. Examples include invalid input, wait_element_timeout, parse_error, click_timeout, dead_page, bad_input and blocked. Fix these by updating the scraper logic, parser selectors, validation rules or input data.

What causes proxy and unblocker errors?

Proxy and unblocker errors come from Bright Data’s proxy, routing or unblocking layer. Examples include proxy connection issues, target website blocking, geo or zone configuration issues, no available peers and rate limiting. Fix these by retrying, reducing the request rate, changing country or geo settings, or contacting Bright Data support if the issue persists.

What causes platform and infrastructure errors?

Platform and infrastructure errors come from the Scraper Studio platform, browser worker, parser sandbox, storage layer or internal infrastructure. Examples include worker timeout, browser disconnected, parser memory limit exceeded, upload failure and WebSocket connection issues. These are often transient and are frequently resolved by retrying. If the issue persists, open a support ticket with the scraper ID, job ID, failed input and raw error message.

Common scraper error codes

These error codes indicate scraper execution issues. The request may have failed because of invalid input, a missing or changed page element, target blocking, parsing problems, rate limits, CAPTCHA handling or scraper logic that needs to be updated.

How do block and blocked differ?

block and blocked are different error codes. blocked is raised by scraper logic, while block is raised by the layer that fetched the page. blocked is usually raised by scraper logic. The scraper calls blocked() when it detects a blocked page, login wall, CAPTCHA page or other condition that should mark the crawl as blocked:
block usually comes from navigation, request rejection, target-site blocking or proxy-level response handling. It may include the real HTTP status returned by the target site or upstream layer. Observed status codes for block are:
In short:
  • blocked is collector-level block detection, usually raised by scraper logic
  • block is target, proxy or navigation-level rejection, often with an HTTP status
These error codes indicate navigation or browser loading issues. The scraper may have failed because the page did not load in time, the browser could not reach the URL, the target kept network requests open, or the connection timed out or closed before completion.

Browser and infrastructure lifecycle errors

These error codes indicate that the browser session, runner or browser-control connection was interrupted during the crawl. They are usually transient platform or browser lifecycle errors. Common lifecycle error codes are runner_disconnected, network_error, cdp_conn_err, cdp_cmd_timeout, cdp_disconnect, bad_browser, browser_disconnected and ipc_timeout. Suggested action: retry the job. If the error persists, open a support ticket with the job ID, response IDs, failed input and raw error message.

Rate limit variants

global_rate_limit and bucket_rate_limit mean that requests to the target domain are being rate limited. This usually happens when the target site is sensitive to high request volume or too many requests are sent in parallel. Suggested action: retry after a short delay. If the issue repeats, reduce concurrency and queue jobs instead of running many jobs in parallel.

Job lifecycle error codes

These error codes indicate that the collection did not complete because of runtime, deadline, cancellation or page-volume limits.

Infrastructure and storage error codes

These error codes indicate platform, worker, storage or delivery issues. The collection may have failed because an internal service was unavailable, a worker was overloaded, the result was too large or delivery to an external destination failed.

Proxy and unblocker error codes

These error codes indicate a routing or connection issue between Scraper Studio and the underlying proxy network. They usually happen when the proxy network cannot establish or maintain a stable connection to the target site.

Parser and payload error codes

These error codes indicate parser execution or payload-size issues. The scraper may have failed because parser code encountered invalid or missing data, the payload sent to the parser was too large, or parser execution exceeded memory or CPU limits.

Access and permissions error codes

These error codes indicate an access or compliance issue. The request was stopped because the target is restricted by Bright Data’s compliance safeguards or because account permissions need review.

How to troubleshoot a failed Scraper Studio collection

Work through these steps in order when a collection run returns errors.
  1. Check the error_code.
  2. Check the status_code, if present.
  3. Read the raw error message.
  4. Open the failed URL manually to confirm whether the page exists and is accessible.
  5. Use Debug crawl or Crawl inspector to inspect the failed input, crawl stage, children, files, warnings and output records.
  6. If the error is parser-related, run a preview and inspect HTML, Output and Last errors.
  7. If many inputs fail with the same error, check the request rate, concurrency, blocking, worker type and recent target-site changes.
  8. If the issue persists, open a support ticket with the scraper ID, job or response ID, failed input and raw error message.

FAQs

Why is status_code missing from my failed record?

Some Scraper Studio error paths do not assign a numeric status code, so status_code is sometimes missing or undefined. Treat the field as optional and branch on error_code instead.

Does a warning mean the record was lost?

No. A warning means the record was delivered but something should be reviewed, such as a partial crawl, a condition configured as a non-error or an output validation issue. Only records with error and error_code are unsuccessful.

Which errors should I retry automatically?

Retry transient platform, browser lifecycle, proxy and rate limit errors, such as infra_error, runner_disconnected, browser_disconnected, worker_too_busy, proxy_error, global_rate_limit and bucket_rate_limit. Do not retry bad_input, ERR_INVALID_URL or dead_page, because those need an input or discovery-logic fix.