Skip to main content

Overview

Lifecycle callbacks let you observe trace events without modifying your tracing logic. Use them for monitoring, metrics, alerting, or debugging — the SDK invokes them at key points in a trace’s lifecycle.

TraceCallbacks Interface

Callback Reference

onCreated

Fired once per trace, after the first successful flush (i.e., the server has acknowledged the trace).

onFlushed

Fired after every successful flush. Useful for tracking throughput or confirming delivery.

onFlushError

Fired when a flush fails after exhausting all retries. The data from that flush attempt is lost.

onClosed

Fired when a trace is closed, either explicitly via trace.close() or automatically (e.g., max lifetime exceeded, page unload).

onDropped

Fired when items are discarded because the flush queue has reached maxQueueSize. This is a signal to reduce event volume or increase the queue size.

Setting Callbacks

Client-Level (All Traces)

Callbacks set on the client apply to every trace it creates:

Per-Trace (Override)

Per-trace callbacks override client-level callbacks for that specific trace:

Use Cases

Metrics Collection

Track SDK health and throughput:

Error Alerting

Get notified when trace delivery fails:

Debug Logging

Verbose output during development:

Trace Correlation Logging

Log trace IDs for request correlation in your backend:

Error Safety

Callbacks are invoked inside a try-catch — if your callback throws, the SDK logs the error (via the configured logger) and continues normally. Your callbacks will never crash the SDK or interrupt trace delivery.

Next Steps

Custom Logging

Configure SDK logging output

Retry Logic

Network failure handling

Types

Full TraceCallbacks type definition