Skip to main content
Production browser workflows should retry deliberately. Some failures are transient. Others are policy decisions, user-denied approvals, blocked pages, invalid input, or site behavior that should stop the job.

​
Retry guide

SignalTypical action
Timeout or transient connection errorRetry with a fresh browser or a longer timeout when the task is still safe
429 rate limitBack off and retry later
409 browser not ready/configuringWait briefly and retry the status or resource read
Policy denialStop or ask the user to change the policy
Approval denialStop and report the denial
CAPTCHA or blocker stateStop, ask for human review, or use the documented CAPTCHA resolver when appropriate
Validation errorFix the request before retrying

​
Redacted logging

Log bounded, redacted fields rather than raw browser errors. 
import { redactValueForObservability } from "@webcompute/sdk";

function safeError(error: unknown) {
  if (error && typeof error === "object") {
    const value = error as { code?: unknown; name?: unknown; message?: unknown };
    return redactValueForObservability({
      code: value.code,
      name: value.name,
      message: value.message,
    });
  }
  return { message: redactValueForObservability(String(error)) };
}

try {
  const result = await browser.playwright.execute({
    code: `return await page.title();`,
  });
  console.log(result.result);
} catch (error) {
  console.error("Browser job failed", safeError(error));
}
Raw browser errors can include page content, URLs, local paths, request fragments, or signed capabilities. Redact before storing or sharing.

​
Preserve evidence

When a job fails, keep the evidence that helps someone decide the next step:
  • Browser ID.
  • Final status.
  • Redacted error code and message.
  • Step summaries or observations.
  • Relevant artifact IDs.
  • Recording segment IDs when recording was enabled.
Reference: observability, error codes, status, events, and logs, and blockers and CAPTCHA.