Operational
These categories report on the session itself rather than page content.control answers “what did my agent do.” platform is mostly Kernel acting on the VM on your behalf - saving a profile, capturing a replay, polling a recorder - so it is off by default even though the rest of this group is on. Enable it when you are debugging a profile save, a replay, or a session-setup step rather than the agent itself.
control reports one cdp_command for each supported browser-control command it can classify from the CDP proxy - input gestures, navigation, dialogs, file selection, screenshots, and every command phase, including mouseMoved, keyUp, and char. It doesn’t report arbitrary CDP traffic; general inspection traffic such as most DOM and Runtime commands isn’t classified as browser control. The command stream isn’t sampled, coalesced, or reordered.Reduce CDP command volume
Usecontrol.cdp.excluded_methods to omit high-volume methods such as Input.dispatchMouseEvent during a humanized cursor path or Page.captureScreenshot during a screencast:
cdp_disconnect, telemetry_excluded counts configured exclusions. Treat a nonzero telemetry_dropped as a telemetry-loss signal rather than using it to reconstruct the missing command sequence; the browser commands themselves still reach the browser.
Captcha event fields
A visible captcha challenge can require multiple solver tasks. These events report task progress and challenge outcomes separately:
Every captcha event has
ts (Unix microseconds), type, category: captcha, and source. The data payload holds the event details, and optional truncated: true means the payload was cut to the size limit.
Use
captcha_provider for the product and task_kind for what a task result means. captcha_type values are frozen: other covers Arkose, unclassified tasks, and some image rounds; press-and-hold reports press_and_hold. An image round can also report hcaptcha, so don’t infer its task kind from captcha_type. Older events may lack the new fields, so fall back to captcha_type when reading stored events.
What each captcha provider emits
An observed result covers the visible challenge across its solver tasks. An inferred result reports a returned token without observing the page. Each eligible successful
token task can produce one, so a challenge may have several inferred results. Failed tasks and image rounds don’t produce inferred results. Turnstile tokens don’t produce challenge results.
Correlate captcha tasks and challenges
Usetask_id to pair a captcha_solve_started event with its captcha_solve_result. Use challenge_id to group tasks for a visible challenge when it’s present. It can continue across a page reload; it doesn’t indicate task order or completion.
Most solver tasks identify an individual solve, so they have task_id but no challenge_id. In-browser hCaptcha image rounds and press-and-hold attempts also identify the visible challenge and carry challenge_id. This means an observed recaptcha_v2 result can’t be joined to its task events, even when both arrive. Join an inferred result on its task_id instead; it has no challenge_id.
Telemetry delivery is best-effort and unordered: a start can arrive after its result, and any event can be absent. When you need a challenge outcome, wait for a bounded interval, then check available task results and the current page state.
Captcha challenge outcomes
Observedrecaptcha_v2 and hcaptcha results report solved or abandoned. human can also report failure when its solve budget is exhausted. Inferred results report solved without observing the page.
Use each result event’s duration_ms as the authoritative duration rather than calculating it from event timestamps. An observed challenge’s duration covers every solver attempt from when it appeared until its terminal outcome.
Browser activity
These categories report what’s happening in the page. Capturing any of them attaches a Chrome DevTools Protocol (CDP) collector to the session and produces highly granular page-level events. Capturing them adds overhead, so enable only the ones you need.interaction events are browser-native DOM events observed in the page, not calls to the computer-control API (those are reported by the control category).Computed readiness events
Three of the event types above don’t come from Chrome. Kernel computes them from sequences of CDP events, so Kernel defines when they fire:
Each fires at most once per navigation, and all three reset when a
page target navigates at the top level. page_navigation also fires for subframes and for iframe targets, and those don’t reset readiness state. A timer from a previous navigation never fires against the current one.
page_navigation_settled is deliberately independent of network_idle, so a single hung request can’t stall it. It does depend on page_layout_settled, which in turn needs page_load, so a page where load never fires emits neither. If you want one readiness signal per navigation, consume page_navigation_settled: it’s the only one gated on both the DOM and visual stability.
The 1 s layout window covers late-loading web fonts and deferred image reflows. network_idle uses the same 500 ms quiet-period heuristic as Playwright’s networkidle wait state, but it’s an observation rather than a wait: it reports that a quiet period happened, and won’t re-arm if traffic resumes.
network_idle counts requests on a single target. If telemetry attaches to a page that’s already loading, the monitor can miss requests that started earlier, so network_idle might fire before the page is really quiet. A monitor_disconnected discards readiness state that was in progress, so computed events still pending for that navigation never fire. monitor_reconnected means the collector is healthy again; it doesn’t restore them. Reattachment starts a fresh state machine, so computed events can resume before the next navigation, carrying empty navigation context until one happens.interaction_scroll_settled the same way: it fires 300 ms after the last scroll event on a target, and only when the position moved more than 5 px on either axis, so scroll jitter doesn’t emit an event.
The monitor category
monitor reports the health of the CDP collector itself: monitor_disconnected, monitor_reconnected, monitor_reconnect_failed, and monitor_init_failed.
It isn’t directly settable. It flows automatically whenever any of the browser-activity categories are captured. You can still filter the stream by monitor to isolate these events.
Data sensitivity
Telemetry is off by default. The default set isn’t limited to session metadata:control records the source you submit for Playwright execution and sanitized arguments for supported browser-control commands, while captcha can record the host and path of the page where a solve ran. The browser-activity categories capture what flows through the page, which is your own browser’s data and can include credentials and personal information.
Captured events are persisted and can be replayed by resuming the stream, so this sensitivity applies to the data at rest, not just the live stream. Events are retained for 30 days, then expired (see Retention). Treat captured telemetry - and anywhere you forward or store it - with the same care as the underlying content. For how Kernel encrypts, retains, and processes data overall, see Security and the Data Processing Addendum.
Some exposure is reduced for you automatically: input into sensitive fields such as passwords is suppressed (
interaction_key isn’t emitted for them, and interaction_click omits the element text), and cdp_command reports text lengths rather than the text itself. Beyond that, because selection is opt-in, the most effective control is to capture only the categories you need - enable network, console, page, interaction, or screenshot deliberately, and prefer the operational categories when you only need session health.
If you capture control and run Playwright code, pass credentials in through variables your snippet reads rather than as literals in the submitted source, so the captured code doesn’t carry them.