Install the SDK

Errors and Sessions come from the BWorlds SDK, a small package the app loads in the visitor's browser. Until it is installed, those two commands have nothing to return, and they return it the same way they return good news.

Anyone in the Build's Workspace can run the install. Only the publish at the end needs the Builder's builder tool, so agree the change with them before you start.

An unmonitored Build reads as healthy

bworlds telemetry errors storefront

Heartbeat: no_data
Window: last 7 days
Impact: 0 users, 0 sessions, 0 occurrences

No client errors recorded.

Sessions answer No sessions found. Uptime answers in full, because BWorlds pings the Build's URL from its own servers and never needs the SDK:

bworlds telemetry uptime storefront

Status: up
Uptime: 99.63%
Avg Response: 736ms

The Build now reads up, error-free and quiet. All three of those readings are the absence of measurement. Read the heartbeat first, and treat the lists as evidence only once it says the SDK reported.

What the heartbeat says

The SDK sends a heartbeat from a visitor's browser while the app is open.

no_data is the one to act on. That Build is unmonitored: nobody hears about a production error on it, including you.

One-click install

In the app, the Build offers Connect your app wherever its monitoring has no data. With GitHub connected, that path ends in Install for me and BWorlds commits the SDK into the repository itself. build info reports whether the connection is there:

bworlds build info storefront

GitHub: not connected

BWorlds detects the app's framework, commits the change to the default branch, and stops. Someone then publishes from the builder tool, which is what puts the SDK in front of real visitors.

The commit also leaves a marked block in AGENTS.md asking the Builder's coding assistant to keep the init call, because an assistant tidying the entry file is a common way for monitoring to disappear.

One-click install covers Next.js, Vite and Create React App. It declines rather than guess on any other framework, on a repository with no single app root, and on a default branch that refuses commits. Each of those sends the Builder to the manual path.

Manual install

The app hands you a ready-made prompt for the builder tool, because Lovable, Bolt and the rest own the app's entry file. Paste it there, accept the change, and publish. What the prompt asks for is two lines:

npm install @bworlds/launchkit

import { init } from '@bworlds/launchkit';
init({ buildSlug: 'storefront' });

buildSlug is the Build's slug, the same one every bworlds command takes. Nothing else is configured in code: the SDK reads its settings from BWorlds at startup, and there is no API key to hold.

A coding assistant asked to add this sometimes rewrites it into a shape it prefers. Keep it as written, and check afterwards that exactly one init call survived.

Confirm it reports

bworlds telemetry errors storefront

Heartbeat: alive (last seen: 2026-09-30T10:09:13Z)

alive proves the published app reached BWorlds. Give no_signal a visitor before concluding anything from it: with nobody on the app, a correct install reads that way ten minutes after the last visit.

A Build that stays at no_data after a visited publish has two usual causes. The code that went live does not hold the init call, which the app's own repository shows. Or the Build's URL in its settings is not the origin the published app serves from: BWorlds accepts telemetry only from the URL the Build declares, and drops the rest without an error the app can see.

Once the heartbeat is alive, Production evidence is what to do with what it brings back.