Both are captured from the moment the provider mounts. Both are rolling buffers — you get the entries leading up to the report, not the whole session.
Console
<TraceItXProvider
config={{
apiKey: 'txx_live_…',
console: { maxEntries: 100, levels: ['warn', 'error'] },
}}
>| Option | Default | Notes |
|---|---|---|
console.maxEntries | 100 | Ring-buffer capacity. |
console.levels | all five | log, info, warn, error, debug. |
Narrowing levels is the cheapest way to cut report size on a chatty app —
['warn', 'error'] usually keeps everything a triager wants and drops most of
the volume.
Network
<TraceItXProvider config={{ apiKey: 'txx_live_…', network: { maxEntries: 100 } }}>fetch and XMLHttpRequest are both captured, as metadata: method, URL, status
and timing. Bodies are separate and off by default — see
Network bodies.
How they reach the envelope
Both land as breadcrumbs, with kind: "console" and
kind: "network", on the shared clock. The envelope also carries
payload.logs and payload.network arrays, but those are deprecated —
derived from the breadcrumb chain during the deprecation window so older
receivers keep working.
Read payload.breadcrumbs and filter by kind. It is the only way to see console
and network interleaved with clicks and navigation on one timeline.
Redaction
Both streams pass through the redaction engine before they are buffered, not before they are sent. A token in a query string never reaches the buffer, so it cannot be recovered from a report even by us.