code, when present, to choose an action. Keep msg for logs and diagnostics. data may contain validation details or information from the browser.
Some forwarded browser responses and scraping errors do not include code, and may use detail or error instead. Your error handler should tolerate these shapes and non-JSON responses from a network intermediary. Record the status and x-cloud-tracing-uuid header when available.
Where the failure came from
Read the response first. Most failures fall into one of these:
A browser can start,
/scrape can return HTTP 200, and the page can still hold a challenge or an empty result, so check the content and not only the status.
Which timeout fired
Retrying
Choose retries by the reported condition rather than the HTTP status alone:
A
400 cluster_is_full can be retried; a 429 caused by exhausted traffic quota needs a different response. HTTP status alone cannot distinguish these cases.
If a start request times out or loses its connection, its outcome is uncertain. Check active sessions before repeating it. Creating a profile or one-time session is not an idempotent operation, so an automatic retry can create an extra resource.
Request errors
Limit errors
These errors return HTTP429. Profile API responses include headers for the current request limits and remaining allowance; see Limits.
Errors from the browser
These errors come from the container running your browser. They usually appear during startup, scraping, or cookie requests.Validation errors
Gateway validation errors return422 validation_error with the failing fields in data. For example: