Introducing Browser Telemetry: a stack trace for browser agents

Your browser agent was supposed to book the flight. It didn't. The log says task failed: could not complete checkout. That's all you get.

So you do what everyone does: you run it again. You watch a screen recording at 2x. You add a screenshot step. You sprinkle in print statements and rerun a fourth time, hoping it fails the same way twice. Somewhere in there you start to suspect the "Continue" button moved, or a background request 500'd, or the page never actually finished loading, but you can't tell which, because by the time the error surfaced, the evidence was already gone.

A traditional backend failure leaves a stack trace, while a browser agent failure leaves a lot to be desired. That's why we built Browser Telemetry: to give every browser session the equivalent of a stack trace, a single ordered timeline your agent can read, write, and react to.

Why a browser is hard to debug

A browser session is four layers deep. Your code issues commands. Chrome executes them. The page reacts, firing network requests, scripts, and layout shifts. And underneath all of it, a VM keeps the whole thing alive.

Each layer can fail on its own. The catch is that a failure at the bottom almost always surfaces at the top as something useless. The agent just gets back the same generic disconnected from browser, whatever the root cause. A background fetch 500s and the page just renders an empty cart. None of it points back at the thing that actually broke.

What Kernel’s Browser Telemetry captures

With browser telemetry, everything that happens to a session lands on one timeline as a structured object: an event with a timestamp, a payload, a category, and a type like network_response, console_error, or system_oom_kill. Most come straight from Chrome, which already emits what it's doing over the Chrome DevTools Protocol, the same interface your agent uses to drive it. To capture them, we open a second, separate connection and just listen, so your agent never notices we're there.

Some of those events are derived. For example, "layout settled" fires once the page stops moving, and "navigation settled" only fires when the page has both loaded and stopped shifting. So a button that moved half a second after your agent located it becomes a single event you can point at, instead of something you reconstruct from a screen recording.

Chrome only sees its own layer, so we capture the rest at the source. When Linux runs out of memory it kills the biggest process and writes a full report into the kernel's own log, and we read the whole thing, not just the headline. Instead of "Chrome died," the event says "Chrome was holding 4.8GB on a 2GB machine with 17MB free." Captchas get the same treatment, caught at the proxy layer and stamped with how they ended. All of it adds up to serious volume. A busy page can fire hundreds of network and console events a second, so the heavy streams (network, console, screenshots) stay off until you ask for them.

Making telemetry fast, durable, and secure

We've spent a lot of time making our browsers fast, and adding telemetry doesn't undo that work. Whatever you capture still has to get off the machine without ever slowing it down. So we decided events should flow through a fixed-size in-memory buffer that accepts each new event by overwriting the oldest, which means producers never wait and a reader that falls behind gets skipped forward rather than allowed to drag. We accepted the tradeoff that comes with it: under load you can lose events, but every event carries a sequence number, so a reader always knows it missed something and exactly how much. The loss is detectable.

That keeps the live stream fast, but an in-memory buffer has one catch: it dies with the VM, which is the wrong property for debugging, since the failure you care about is usually the one you investigate after the session is gone. So we decided to also write every event to a durable log (a service called S2) as it happens. The browser disappears, but its timeline doesn't.

Of course, capturing events necessitates holding customer data. Network headers, bodies, console output, and screenshots can still hold customer data at rest once archived. To give developers more control over what data is shared, Browser Telemetry’s event capture is opt-in per category and per session.

A real-time feedback loop for your agent

So far this is a tool for whoever reads the timeline after the run is dead. But your agent doesn't have to wait for the post-mortem. The timeline is just an endpoint on the session it already holds:same API key, same SDK or CLI. That agent can watch its own session as it happens and act on what it sees: react to "captcha solved" instead of polling the DOM, or read an out-of-memory event as "stop retrying, this machine is gone." The agent can drop off and reconnect without losing events, or replay the whole session from the archive once the run is over.

And your agent can write, not just read. The same publish endpoint accepts custom events, so your agent can drop "attempting checkout, step 2" onto the timeline, and that marker lands in sequence between the click it issued and the 500 the page throws back. The agent's intent and the browser's state is interleaved in one trace.

Where this is going

As agents get smarter and smarter, it gets more important to equip agents with the right tools for the job. Browser Telemetry is part of Kernel’s ongoing work to empower agents to use the Internet faster and more reliably. Get started with Browser Telemetry today through our docs.