Skip to main content

Observability overview

Mastra's observability system gives you visibility into every agent run, workflow step, tool call, and model interaction. Agent behavior depends on model responses, prompts, tools, memory, and workflow state, so observability helps you inspect runtime decisions from day one. It captures three complementary signals that work together to help you understand what your application is doing and why.

  • Tracing: Records every operation as a hierarchical timeline of spans, capturing inputs, outputs, token usage, and timing.
  • Logging: Forwards structured log entries from your application and Mastra internals to observability storage, correlated to traces automatically.
  • Metrics: Extracts duration, token usage, and cost data from traces automatically, with no additional instrumentation required.

When to use observability
Direct link to When to use observability

  • Debug unexpected agent behavior by inspecting the full decision path, tool calls, and model responses.
  • Monitor latency across agents, workflows, and tools to identify bottlenecks.
  • Track token consumption and estimated cost over time to control spending.
  • Diagnose workflow failures by tracing execution through each step.
  • Compare agent performance before and after prompt or model changes.

How the pieces fit together
Direct link to How the pieces fit together

Tracing is the foundation. When observability is configured, every agent run, workflow execution, tool call, and model interaction produces a span. Spans are organized into traces that show the full request lifecycle as a hierarchical timeline.

Metrics are derived from traces automatically. When a span ends, Mastra extracts duration, token counts, and cost estimates without any extra code. These metrics power the dashboards in Studio.

Logs are correlated to traces automatically. Every logger.info(), logger.warn(), or logger.error() call within a traced context is tagged with the current trace and span IDs. You can navigate from a log entry directly to the trace that produced it.

All three signals share correlation IDs (trace ID, span ID, entity type, entity name), so you can jump between a metric spike, the traces behind it, and the logs within those traces.

Quickstart
Direct link to Quickstart

Install @mastra/observability and storage backends that support traces and metrics:

npm install @mastra/observability @mastra/libsql @mastra/duckdb

Then configure observability in your Mastra instance. The following example uses composite storage to route observability data to DuckDB (which supports metrics aggregation) while keeping everything else in LibSQL:

src/mastra/index.ts
import { Mastra } from '@mastra/core/mastra'
import { LibSQLStore } from '@mastra/libsql'
import { DuckDBStore } from '@mastra/duckdb'
import { MastraCompositeStore } from '@mastra/core/storage'
import {
Observability,
MastraStorageExporter,
MastraPlatformExporter,
SensitiveDataFilter,
} from '@mastra/observability'

export const mastra = new Mastra({
storage: new MastraCompositeStore({
id: 'composite-storage',
default: new LibSQLStore({
id: 'mastra-storage',
url: 'file:./mastra.db',
}),
domains: {
observability: await new DuckDBStore().getStore('observability'),
},
}),
observability: new Observability({
configs: {
default: {
serviceName: 'mastra',
exporters: [
new MastraStorageExporter(), // Persists observability events to Mastra Storage
new MastraPlatformExporter(), // Sends observability events to Mastra platform (if MASTRA_PLATFORM_ACCESS_TOKEN is set)
],
spanOutputProcessors: [
new SensitiveDataFilter(), // Redacts sensitive data like passwords, tokens, keys
],
},
},
}),
})

This enables tracing, log forwarding, and metrics. Mastra also supports external tracing providers like Langfuse, Datadog, and any OpenTelemetry-compatible platform. See Tracing for configuration details.

Mastra platform
Direct link to Mastra platform

For hosted traces, logs, and metrics across projects and deploys, see Observability on Mastra platform.

Storage
Direct link to Storage

Not all storage backends support every signal. Traces and logs work with most backends, but metrics require an OLAP-capable store like DuckDB (development) or ClickHouse (production). For the full compatibility list, see storage provider support.

For production environments with high traffic, use composite storage to route the observability domain to a dedicated backend. See production recommendations for details.

Next steps
Direct link to Next steps