Edge Functions — Request Tracing

Introduction

After the installation, turn on request tracing to see each invocation of your function under Requests in the dashboard, with its route, duration, database calls and outbound requests. You can also open the exact request behind any error. See Request Tracing for what the dashboard shows.

Enable it

const lerix = Lerix.init({
  apiKey: Deno.env.get('LERIX_KEY')!,
  projectId: Deno.env.get('LERIX_PROJECT_ID')!,
  app: { id: 'orders' },
  tracing: { enabled: true },
});

Deno.serve(lerix.wrap(handler));

Tracing is off by default. When it is off, fetch is not patched and nothing is queued.

What is recorded

One server span per wrapped request, named METHOD /route. The route is the URL path with value-like segments replaced (GET /orders/:id). An incoming W3C traceparent header is continued, so a request from your app (or from another function) shows up as one trace.
Outbound fetch: every call inside the request becomes a client span named METHOD host and carries a traceparent header. Calls to the Lerix API itself are ignored.
Supabase database calls: requests that supabase-js sends to PostgREST are named like database spans: select orders, insert orders, upsert orders, update orders, delete orders, rpc apply_discount. Filters are in the query string and are never recorded.

Turn the fetch hook off with tracing: { enabled: true, instrumentations: { fetch: false } }. Trace anything else by hand:

const pdf = await lerix.trace('render invoice', () => renderInvoice(order));

lerix.trace() adds a child span of the current request; outside a traced request it just runs the function.

Sampling

Option	Default	Description
`sampleRate`	`0.1`	Share of successful requests whose full trace is kept
`slowThresholdMs`	`2000`	Slower requests are always kept in full
`maxSpansPerRequest`	`1000`	Child spans beyond this are dropped
`flushIntervalMs`	`10000`	How long unsampled root spans may wait to be sent with a later request

The sampling decision is made once when a trace starts and travels downstream in traceparent. Requests that fail, run slow, or report an error are always kept in full. The root span of every request is sent, so the per-route counts, error rates and percentiles cover all traffic. Root spans of unsampled requests only feed those counters, so they are held in the isolate and sent together with a later request instead of one export per invocation. Anything sampled or failed is sent right after its response.

The trace behind an error

An error reported inside a traced request carries its trace id. Its page in the dashboard links to the request’s waterfall, and that trace is kept even if sampling had dropped it.

Client address

The client address is recorded according to the project’s tracing settings (masked by default). Deno.serve and Cloudflare (cf-connecting-ip) supply the caller’s address directly. Supabase and Vercel only pass it in a forwarded header: set that header and the trusted proxy depth in the project settings, or no address is recorded.

Limits

Child spans need AsyncLocalStorage to find their request. On Cloudflare, turn on nodejs_compat. On Vercel Edge, child spans depend on the runtime exposing a global AsyncLocalStorage. Without it you still get the server span for every request, and errors still link to it.
Cloudflare Workers only advance clocks across I/O, so pure-CPU work shows as zero duration there.

Getting started

Frameworks

Modules

Developers

Edge Functions — Request Tracing

Introduction

Enable it

What is recorded

Sampling

The trace behind an error

Client address

Limits

​Introduction

​Enable it

​What is recorded

​Sampling

​The trace behind an error

​Client address

​Limits

Introduction

Enable it

What is recorded

Sampling

The trace behind an error

Client address

Limits