Capabilities by runtime

What each runtime can send to Belvador, generated from the same list the SDK tests check. Automatic needs no code beyond setup; You call it needs a function call in your code; Not possible cannot work on that runtime. Tested means a test in Belvador's repository runs it; seen in production adds the date it was confirmed on a real customer app; untested means it follows the same protocol but nobody has run it here yet.

Errors and connection#

Background work, traces, source maps#

Traces and logs (OpenTelemetry)#

These rows come from Belvador's certification harness, which runs a real app on each runtime against a full local copy of the pipeline and reads every span and log back; the date and versions are those of the last passing run. Linked to traces means log records carried the request's trace id and span id. Setup for each runtime: OpenTelemetry.

Notes#

• Monitor check-ins never come from browsers: Belvador refuses them, so a closed tab is never a failed job. Use a server, a worker or HTTP check-ins.

• Trace headers in browsers are experimental: they work, but turn them on per API only after checking its CORS settings — see Link errors across tiers.

• Dropped-data counts are the SDK's client reports: how many events it dropped and why (rate limit, offline, queue full). They feed the project's Connection tab.

• Source maps are uploaded from CI, not sent by the SDK — see Source maps.

• Rows marked untested are best effort. If one does not work, tell us at hello@belvador.dev.

For the data each Belvador package sends — and what it drops before anything leaves your app — see Choose the right SDK.