Whether request instrumentation spans can be root spans of new traces. This allows you to trace requests without any instrumentation in your own code, but may create a large number of traces. This will not affect metrics.

Whether fetch and XHR requests will be instrumented with traces automatically.

An array of HTTP response status codes to consider as errors. Status code families can be described as 4xx, 5xx, etc.

Optional regex pattern for URLs that should be excluded from auto instrumentation.

If true, requests to the OTEL Collector endpoints will not be instrumented. Recommended to keep true, since otherwise the request caused by the auto instrumentation telemetry will itself cause auto instrumentation to kick in and so on, creating unnecessary telemetry.

Optional regex pattern, if specified, only matching URLs will be auto instrumented.

If true, the io.Connect Desktop platform also instruments its OWN main-process HTTP traffic - Electron's net module (net.request and net.fetch) - at bootstrap, publishing through the platform's io.Insights instance with the same span and metric shapes as the renderer fetch/XHR instrumentation (spans under "interopio.api.instrumentation.electronNet"). Read by the platform's bootstrap, which guards its call to TracesManager.instrumentElectronNet with it; has no effect outside the platform process.

Unless false, the pre-init recorder (installEarlyInstrumentation from

If true or a string, the download phase (response headers received until the response body was fully delivered) will be published as a histogram metric. If a string value is specified, this will be the name of the metric. Otherwise, the default "io.insights.http.client.response.download.duration" is used (no semantic convention exists for this metric).

Same population and cost caveats as requestTotalDurationMetric: successful requests with an observable body completion only, and enabling it causes abandoned fetch response bodies to be downloaded in full.

Explicit histogram bucket boundaries for requestBodyDownloadDurationMetric, in seconds, ascending.

If true or a string, effective download throughput (response body bytes over the download window, in bytes per second) is published as a histogram metric. If a string value is specified, this will be the name of the metric. Otherwise, the default "io.insights.http.client.response.download.throughput" is used.

Derived from the same observation as requestBodyDownloadDurationMetric (same population and cost caveats), so it contributes samples only for successful requests with an observable body completion - and only bodies of at least 32KB: smaller transfers complete within the initial congestion window and would measure round-trip time, not bandwidth. Per-stream effective throughput: concurrent transfers share the link.

Explicit histogram bucket boundaries for requestBodyDownloadThroughputMetric, in bytes per second, ascending.

If true or a string, the request size in bytes will be published as a histogram metric. If a string value is specified, this will be the name of the metric. Otherwise, the semantic convention default "http.client.request.body.size" is used.

If true or a string, the request's time to first byte (request issued until the response headers were received) will be published as a histogram metric. If a string value is specified, this will be the name of the metric. Otherwise, the default "io.insights.http.client.request.ttfb.duration" is used.

Deliberately not named after the semantic convention: samples other instrumentations publish under "http.client.request.duration" cover the full operation, and mixing time-to-headers samples into that name would skew cross-tool comparisons - the semconv name is instead the default of requestTotalDurationMetric.

Cheap and always available: measured for every request (including failures, until the failure), with no response body observation required.

Explicit histogram bucket boundaries for requestFirstByteDurationMetric, in seconds, ascending. The default is the semantic-convention-recommended set for HTTP client durations, which suits time-to-first-byte distributions well.

If true or a string, the end-to-end request time (request issued until the response body was fully delivered) will be published as a histogram metric. If a string value is specified, this will be the name of the metric. Otherwise, the semantic convention default "http.client.request.duration" is used - the end-to-end measurement matches what other instrumentations publish under that name.

Successful requests only. Requests whose body completion cannot be observed (e.g. streaming responses) contribute no sample, so this metric's sample count is expected to be lower than requestFirstByteDurationMetric's.

Cost caveat: when this or requestBodyDownloadDurationMetric is enabled, body delivery of every non-streaming fetch response is observed by fully reading a clone of the body. As a side effect, responses the application abandons without reading (e.g. only checking response.ok) are downloaded in full over the network instead of being cancelled by the browser. Streaming content types (server-sent events etc.) are exempt. Weigh this before enabling in deployments with large-payload traffic.

Explicit histogram bucket boundaries for requestTotalDurationMetric, in seconds, ascending. The default is the semantic-convention-recommended set (this metric carries the semconv name by default), extended upward to cover long transfers of large payloads; overriding the sub-10s boundaries trades away comparability with other instrumentations that use the recommended set.

Which measurement responseBytesMetric (and the corresponding span data) reports:

• "content-length" (default): only the value of the content-length response header (the actual transfer size, after content-encoding). Cheap - the body is never read for sizing - but responses without the header (e.g. chunked transfer encoding) contribute no sample.
• "raw": only bytes counted by fully reading a clone of every fetch response body (the size after the browser removed any content-encoding; for XHR the already buffered response is measured). Always available, but carries the same cost caveat as requestTotalDurationMetric: every non-streaming fetch response body is drained, including ones the application abandons.
• "both": prefers content-length and falls back to the raw count when the header is absent. Maximizes coverage but mixes the two measurement kinds in one histogram - use the sizeKind metric attribute to separate them when querying.

If true or a string, the request size in bytes will be published as a histogram metric. If a string value is specified, this will be the name of the metric. Otherwise, the semantic convention default "http.client.response.body.size" is used.

Controls only the naming of the fetch/XHR request spans.

"semconv" (default) names the spans by the normalized HTTP request method (e.g. "GET"), per the OTEL semantic conventions for HTTP client spans. "product" keeps the product span names ("interopio.api.instrumentation.fetch"/".xhr").

Everything else is the same in both modes: the spans always carry the semconv attributes (url.full, http.request.method[_original], http.response.status_code, http.response.header.*, server.address/server.port, http.request.body.size / http.response.body.size, error.type), span kind CLIENT, and the semconv status rules. The filtering identity is also unaffected: span filters match these spans on source "interopio.api.instrumentation.fetch"/".xhr" and on context.url / context.method.

If false, no request spans are published - metrics-only mode. The whole instrumentation flow otherwise runs unchanged: measurement, the duration/size metrics, error classification, and the pre-init drain (which then produces metric samples but no retroactive spans). Applies to fetch, XHR, and the platform's Electron net instrumentation alike. Note that trace header injection requires a span context, so injectOTELHeaders has no effect in metrics-only mode. This is a hard switch - span filters cannot re-enable the spans.