How instrumentation works
A peek under the hood — how the SDK captures events without slowing your app down.
The SDK has three jobs: capture, batch, and ship.
Capture
Instrumentation is done by patching well-known integration points: Meteor.methods,
Meteor.publish, the MongoDB driver, http/https, popular job runners. Each
patch adds an inline timing span and emits a structured event.
Patches are version-aware. The SDK detects the major version of the Meteor /
Mongo / http API it's wrapping and selects the right strategy.
Batch
Events are pushed onto an in-memory ring buffer. A flush fires every 5 seconds or when the buffer crosses 1MB, whichever comes first. The flush runs out of band on the macrotask queue — it never blocks your event loop.
If the buffer fills before a flush succeeds (e.g. network outage), the SDK
drops the oldest events first and increments a events_dropped counter you
can see in the dashboard.
Ship
Telemetry is sent over HTTPS to api.uptimeclarity.com. Payloads are
gzipped and delivered with keepalive so they survive process exit.
There is no agent, no sidecar, no UDP. Telemetry takes the same path as any other outbound HTTP request.
Overhead
Typical overhead measured under load is well under 1% of CPU and a few MB of RAM. The SDK is benchmarked against a hot-path Meteor method that does ~10k calls/sec; instrumentation adds ~150ns per call.