The collection
Loading the collection…
Small-batch objects for slow mornings and long weeks. Designed in the studio, built to be used daily — never to be replaced yearly.
Loading the collection…
This store is a live observability demo. Demo faults: Break the cart
throws a minified TypeError (→ error log → symbolicator), Checkout hits a
deliberately slow 2.5 s endpoint (→ the stitched slow trace). Rage-click
Track my order 4× fast (→ rage span — it also opens a real order-status
panel), and the footer's decorative links go nowhere (→ dead clicks). Filters,
promo codes and the newsletter all emit Glasspane.track()
events. Every click you make is real telemetry — watch it arrive in the
Live telemetry panel (bottom right), or open your DevTools console for the
identical batches.
Static export note: this page runs with no backend, so Checkout plays a
clearly-labelled simulated 2.5 s flow (the console logs the interception); everything
else — the SDK, break-the-cart, rage-clicks, filters, promo codes — is the real thing.
Three tools for self-hosted SigNoz — investigate the incident, watch the real browser, price the waste.
Static export — the Live telemetry panel streams the SDK's real events; checkout is simulated (no shop backend behind this page).
GLASSPANE is a browser SDK — 9.89 KB gzipped, under a hard 15 KB build gate
— that turns real user sessions into OpenTelemetry for SigNoz: Web Vitals, page
loads, clicks, fetch spans that carry a W3C traceparent into your backend, and
JavaScript errors with full stacks.
The storefront below is Meridian, a fictional demo shop. The SDK is genuinely running on it right now — this page is not a mockup of the product, it is the product working. 92 offline tests, verified on three browser engines, MIT-licensed.
Every row in this panel is decoded from an OTLP batch the SDK actually produced. The page
wraps console.log before the SDK loads and renders the exporter's own payloads
— same events, same order, same attributes. These rows are the SDK's real
batches; nothing here is staged.
Open DevTools and you will see the identical batches, byte for byte. With an
endpoint configured, they go to SigNoz instead of the console.
The fastest way to believe a telemetry SDK is to make it emit. Add any product to the
cart and watch a cart.add event land in the readout with its item, session id
and trace id attached.
The four-step checklist here ticks itself off as each kind of signal arrives. The SDK buffers and flushes on a timer, so rows arrive in batches — exactly as they would be POSTed to a collector.
This button throws a real TypeError inside minified code. The SDK catches it
through onerror and the readout shows the resulting error log with its stack
frame and severity.
The raw frame reads shop.min.js. The drawer sends that stack to a running
GLASSPANE symbolicator, which maps it back through the build's sourcemap — watch the
note under the error row turn into renderItems (src/cartlist.js:7:22).
That resolution is live, not a caption.
The service is read-only: it holds this demo's own sourcemap and nothing else, and it accepts no uploads. If it is unreachable the note says exactly that instead of showing a frame nobody resolved.
Click Track my order four times fast: the SDK reports one rage-click span plus the dead clicks around it — the frustration signal server-side traces cannot see.
In real use these batches go over OTLP/HTTP to a self-hosted SigNoz, where the browser span roots the backend trace and the dashboard and alert JSON ship with the repo. Checkout on this page is a clearly-labelled 2.5 s simulation — this static export has no shop backend. Everything else you just watched was real.