Collection reliability

Persisted jobs and submission replay

Jobs are persisted before acceptance. Account-scoped submission idempotency lets you retry the same validated request and Idempotency-Key after an ambiguous response without creating another job. A changed request under that key conflicts. Worker claims, heartbeats, and reconciliation allow interrupted work to be recovered; they do not promise exactly-once browser execution.

Bounded collection attempts

Eligible retryable collection failures receive up to three total attempts, including the initial attempt. Permanent failures stop earlier, for example an unsupported Gemini login wall or a collected response exceeding the storage limit. Repeated collections requested with runCount are separate from retry attempts. A task can end as failed even after retry recovery.

Completion can include failed collections

completed means the final artifact is available, not that every collection succeeded. Inspect failedRuns by target and each target's responses. Some or all response arrays can be empty. Missing answers are collection failures, not evidence that a brand was absent. A job with failed status has a parent-level terminal failure; do not wait indefinitely for a completed result.

Google Search and Google News share one browser task per repeat when requested together. Status counts track tasks, while the result's failedRuns counts failures per requested target. One failed shared task counts for both google and google_news; summing per-target failures therefore does not give the task count. Successful response run numbers may have gaps.

Signed completion delivery

Webhook attempts are tracked durably and eligible network or non-2xx HTTP failures receive up to six total attempts. Configuration, secret-decryption, and network-policy failures stop immediately. Delivery is at least once: verify raw bytes and deduplicate stable delivery IDs with durable storage. If notifications fail or attempts are exhausted, poll the existing job and download its result with the owning account token.

Provider and country limits

• Provider interfaces, rate restrictions, authentication challenges, and layouts can change and cause failures. Sources can be empty, fields nullable, and Google AI Overviews absent.
• Perplexity requires an enabled authenticated provider session configured by the operator; website access approval alone does not establish provider availability.
• Gemini login-wall flows are not supported and can fail permanently. Retrying cannot guarantee a provider answer.
• options.country requests a supported proxy country. It does not guarantee a language, city, personalization state, or provider interpretation of location. Confirm deployed routing and country support with the team.

Mechanisms, not performance promises

These mechanisms are grounded in the reviewed implementation, not measured production uptime, extraction-success rates, or latency guarantees. API availability and collection success are different measurements. Confirm deployed configuration and provider availability with the team. No numerical success target, public monitoring schedule, or SLA is established here.