Skip to main content
Browser jobs should leave enough evidence to answer three questions:
  1. What did the browser do?
  2. What did the page show?
  3. Why did the job stop, retry, or ask for review?
Webcompute gives you browser status, browser-code execution logs, observations, events, recordings, downloads, generated files, screenshots, and artifact IDs. Your application should connect those signals to its job ID, user request, policy, retry attempts, and final result. Webcompute Debug UI showing a live browser on Apple's Mac mini page with network events and the recording timeline visible Use Debug UI as the operator surface while a browser job is active. Store durable evidence with the job so operators can replay the run later through recordings, events, artifacts, and downloads.

What to store

SDK job log shape

Do not store full observations by default. Store summaries and artifact IDs, then fetch deeper evidence only when an operator needs it.

Events and recordings

Use events for timelines and recordings for visual review. Recording is opt-in at browser creation.
Debug UI can replay recording segments when recording was enabled. The replay view keeps captured page frames, timeline position, browser metadata, and inspector panels together so reviewers can understand what happened without rerunning the workflow. Webcompute Debug UI replaying a recorded Apple browser session with the Browser panel and recording timeline visible Keep signed Debug UI and CDP URLs out of shared logs. They are bearer capabilities.

Trace IDs

If your deployment exposes request IDs or trace IDs, store them with your app job record. Otherwise, correlate by your job ID, browser ID, timestamps, event IDs, and artifact IDs. Reference: observations, recordings, status, events, and logs, SDK resources reference, and errors and retries.