Skip to main content
This quickstart walks through the full Signals loop: generate traces, write a Signal that reads them, run it, and look at the events.
Every new Laminar project ships with a Failure Detector signal pre-created. It runs automatically on traces with more than 1000 tokens, and categorizes issues as tool_error, api_error, logic_error, looping, wrong_tool, timeout, or other. You don’t need to build this one yourself. Open it from the Signals list to see events as soon as your traces start arriving.

Prerequisites

  • A Laminar project and LMNR_PROJECT_API_KEY.
  • An agent or LLM app whose traces land in Laminar. The example below uses the Claude Agent SDK to produce traces quickly.

1. Generate traces

Any traced application will do. The Claude Agent SDK example below sends a handful of prompts and emits one trace per prompt. Enough to exercise a Signal end-to-end.
Run it, then refresh the Laminar traces page to confirm the quickstart_agent traces arrive.

2. Open Signals

Click Signals in the project sidebar. If this is a new project, the Failure Detector signal is already there, ready to run on any trace over 1000 tokens.
Signals list view with cards for each Signal and recent event counts

Signals list: one card per Signal with its event and cluster counts

To write your own, click + Signal. The Create Signal drawer opens with the definition at the top and the trigger, filters, and sampling below it.
Empty Create Signal drawer showing the trigger options and the default total tokens filter

Create Signal drawer: name, template, prompt, and output schema on top, trigger and filters below

3. Write the Signal

Create Signal drawer populated with a name, the Task template, a prompt, and two output schema fields

Create Signal drawer filled in from the Task template: the prompt and output schema come prefilled

1

Name

2

Template (optional)

Templates prefill the prompt and schema
3

Prompt

Describe what the Signal should detect or extract from the trace in plain English.
4

Structured output

Signals Agent will generate a payload for every event. Define the shape of this payload with a JSON schema.
5

Trigger

When the Signal evaluates a trace. A Signal has exactly one trigger.
  • When a trace finishes — fires once the trace’s root span ends. The default, and right for most agents.
  • When a specific span finishes — fires when any span you name ends. Use this when the work is spread across services and spans keep arriving after the root span closes (distributed tracing).
6

Filters

Which traces actually run once the trigger fires. Filters are AND-combined — a trace runs only if every filter passes. The default is total tokens > 1000.
7

Sampling (optional)

Evaluate only a percentage of matching traces (5–95%). Sampling is applied per user, so coverage stays spread across your user base instead of concentrating on whoever is noisiest. Useful when a broad filter would otherwise fan out across every trace.
Click Create. The Signal is live from this point on: the trigger starts processing new traces that match the filters.
By default, Signals will notify the creator of critical events through the platform notifications panel and email. Open the Signal’s Settings > Alerts section (or Project Settings > Alerts) to change channels or add additional filters. See Alerts.

4. Manage the Signal

A Signal can evaluate new traces as they arrive, or a historical slice. Open a Signal and click Settings to manage both from a sidebar with three sections: General (definition, trigger, and filters), Alerts, and Backfill. Every evaluation the Signal performs is listed on the Signal’s own Runs tab, alongside Events and Settings.
Signal settings General section with the trigger options and the filters bar

Signal Settings > General: prompt, output schema, trigger, filters, and sampling

Backfill (historical)

Use Backfill to run a Signal across historical traces, for example to evaluate a freshly-created Signal over the last 24 hours of traffic.
Backfill page with trace selection, filters, and trace table

Start a backfill: pick traces or filters, then enqueue

  1. Open the Signal’s Settings > Backfill section.
  2. Pick a time range (defaults to the last 24 hours).
  3. Optionally narrow with filters or search.
  4. Choose specific traces or all traces matching your filters.
  5. Click Start backfill. Laminar enqueues one Run per trace.
Runs appear on the Runs tab with a status (Pending, Processing, Completed, Failed). Backfilled Runs are marked as such, so you can tell them from the Runs a live trigger produced. Each Run that detects the Signal links to the resulting event in the Events tab, and every Run reports the token cost of the evaluation.
Signal runs table listing runs with status, source, event, clusters, cost, and event id

The Runs tab: one row per evaluated trace with its source, status, cost, and the event it produced

Pause and resume a Signal

A Signal you’re not ready to delete can be paused. Open the Signal’s Settings > General section and flip the Active switch off.
Signal settings General section with the Active switch flipped off and the signal marked Inactive

The Active switch at the top of Settings > General; flipped off, the Signal reads Inactive

While a Signal is paused:
  • New traces are not evaluated, even if they match the Signal’s trigger and filters.
  • Backfills are rejected until the Signal is re-enabled.
  • Existing events and clusters are kept, and stay queryable in SQL and the UI.
  • Alerts on the Signal stay configured but have nothing to fire on.
Paused Signals show a Disabled badge on the Signals list and are grouped separately from active ones. Flip the switch back on and the Signal resumes evaluating new traces immediately.
Signals list with an Active section and a Disabled section, the disabled Signal card dimmed with a Disabled badge

The Signals list groups paused Signals under a Disabled section

You can also pause a single alert instead of the whole Signal, to keep collecting events while silencing notifications.

5. Inspect events

Open the Signal detail page and switch to the Events tab. Each row is one detected event, linked back to the trace that produced it.
Signal events view with chart, event list, and per-event payload

Events tab: structured payloads, timestamps, and jump-to-trace links

From here you can:
  • Filter events by any field you defined in the structured output schema.
  • Click any row to open the corresponding trace.
  • Use the clusters view above the events table to see similar events grouped together. See Clusters.
  • Query the raw events in the SQL Editor via the signal_events table.

Querying signal_events in SQL

signal_events stores each event’s payload as a JSON string. The UI’s payload filter uses simpleJSONExtractString / simpleJSONExtractRaw, so you can mirror the same behavior in SQL.

Quick payload filter (UI-equivalent)

Numeric comparisons with JSONExtractFloat

Typed or nested fields with JSONExtract

Next steps

Clusters

Group similar events into recurring patterns.

Alerts

Send Slack or email notifications on new signal events.

CLI

Do all of this from the terminal instead: create, update, and delete Signals.

SQL Editor

Query the signal_events table directly across every Signal.