Start free

Mastra integration

Observability for Mastra agents and workflows

Trace Mastra agents and workflows in production. Inspect steps, tools, model calls, and suspended runs, detect recurring failures, and turn real traces into evals.

Start tracing MastraView setup docs

SEND MASTRA TRACES TO LATITUDE

import { Mastra } from "@mastra/core"
import { Observability } from "@mastra/observability"
import { OtelExporter } from "@mastra/otel-exporter"

const latitudeExporter = new OtelExporter({
  provider: {
    custom: {
      endpoint: "https://ingest.latitude.so/v1/traces",
      protocol: "http/protobuf",
      headers: {
        Authorization: `Bearer ${process.env.LATITUDE_API_KEY!}`,
        "X-Latitude-Project": process.env.LATITUDE_PROJECT_SLUG!,
      },
    },
  },
})

export const mastra = new Mastra({
  agents,
  workflows,
  observability: new Observability({
    configs: {
      production: {
        serviceName: "my-mastra-app",
        exporters: [latitudeExporter],
      },
    },
  }),
})

Mastra emits standard OpenTelemetry GenAI spans. Point its native OTLP exporter at Latitude. No Latitude SDK or changes to agent and workflow logic are required.

What your Mastra traces turn into

Complete agent and workflow runs you can inspect end to end, with recurring failures already grouped for you.

Three steps to your first Mastra trace

Add Mastra’s native OpenTelemetry exporter to the observability config you already use.

1

Install the exporter

Mastra and Latitude use standard OTLP over HTTP/Protobuf.

2

Point Mastra at Latitude

Add the exporter to Mastra’s Observability config. Agent runs, workflow steps, tools, and model calls emit automatically.

3

Run one workflow

Open Traces. Follow the workflow timeline and inspect each agent, step, tool, and model interaction. Mastra names step spans after the workflow, so you read a step from its input and output.

Serverless and short-lived runtimes should await mastra.observability.flush()before the runtime pauses or exits. Long-running servers export in the background. Mastra integration guide →

Debug Mastra failures in production

The workflow-state, retry, tool, and model failures that emerge after real traffic reaches branching agents.

Workflow steps fail or take the wrong branch

A step throws, or a condition routes production input down the wrong path. The failed step arrives with its error type and its input, and every branch condition arrives with the value it evaluated to, so the path taken is visible in the execution tree.

Workflow traces →

Retries hide a persistent failure

Mastra retries a failing step in place, so all attempts collapse into one span carrying the final error. A deterministic failure looks like a single bad run each time. Counting how many runs it affects is what turns it into one tracked Signal.

Signals →

Suspended runs never resume

A workflow waits for approval, callback data, or a resource. A suspended run exports with its input and no output, and its resume lands in the same trace marked as resumed. The runs with no resume are the ones stuck.

Search →

Regressions after a workflow change

A prompt, tool, schema, model, or control-flow release raises failure rates. Tag traces by release and let resolved Signals reopen when the issue returns.

Signal lifecycle →

Find recurring failures hidden across Mastra runs

Reading traces one at a time finds the failure you went looking for. Latitude surfaces the one costing you the most sessions.

Search

Describe it in plain language

Find sessions by meaning, exact text, or metadata. The query above finds traces that never use those words.

Search →

Behaviors

Grouped by what users tried to do

Whole sessions clustered by intent and outcome, so patterns surface without you writing the query.

Behaviors →

Signals

One named, tracked problem

Repeated failures become one Signal with a trend, affected sessions, and a lifecycle. Flaggers feed it automatically.

Signals →

From production failure to verified fix

Turn a recurring Mastra failure into a regression test, an opened PR, and a verified fix.

DetectLatitude groups workflow runs that remain suspended after an approval callback into a Signal.
TestTurn affected traces into a regression eval.
FixAgent Dispatch sends the Signal, affected traces, run metadata, and sample workflow state to Claude Code or Cursor. The coding agent writes the smallest fix and regression test, then opens a PR.
VerifyLatitude scores new traffic and alerts you if the failure returns.

Latitude detects and verifies. Your coding agent writes the fix. You review the PR.

Fits the Mastra stack you already have

  • TypeScript
  • Native Mastra OTLP exporter
  • Agents, workflows, tools, and suspend/resume
  • Any model provider
  • Mastra Studio can stay enabled
  • Latitude Cloud or self-hosted (MIT)

Using Mastra Studio or another observability backend?

Keep it. Mastra accepts multiple exporters. Retain MastraStorageExporter orMastraPlatformExporter for Studio and hosted Mastra visibility, then add Latitude’s OTLP destination to the same config.

Latitude begins building Search, Behaviors, and Signals from newly exported traces. Historical Mastra Platform or Studio traces are not imported.

When do you need more than Mastra logs and traces?

Mastra observability explains individual runs. Latitude adds cross-session discovery, recurring failure lifecycle, production evals, and coding-agent dispatch.

CapabilityApplication logsMastra observabilityLatitude
Complete agent sessionsLimitedYesYes
Semantic search across sessionsNoVariesYes
Recurring failure detectionManualVariesSignals
Production traces into evalsNoVariesYes
Dispatch and verificationNoNoYes

MIT

Open source, 4.6k stars

20K

Free credits a month, 30-day retention

Unlimited

Seats on every plan, no per-user pricing

GDPR

Compliant, data in AWS eu-central-1

PricingSelf-hostingSecuritySource on GitHub

Mastra observability FAQ

How do I send Mastra traces to Latitude?

Install @mastra/observability, @mastra/otel-exporter, and @opentelemetry/exporter-trace-otlp-proto. Add an OtelExporter with endpoint https://ingest.latitude.so/v1/traces, protocol http/protobuf, and the Latitude Authorization and X-Latitude-Project headers to your Mastra Observability config.

What does Latitude trace in Mastra?

Mastra emits spans for workflow runs and their steps, agent runs, tool calls, and model calls. Model spans carry the messages, model name, provider, token counts, and finish reason, so Latitude shows them with latency and estimated cost. Tool spans carry the tool name, arguments, and result. Workflow and step spans carry their input and output, and every Mastra attribute is kept on the span. One naming detail to expect: Mastra names step spans after the workflow rather than the step, so a step is identified by its input and output.

Can I keep Mastra Studio observability?

Yes. Keep MastraStorageExporter for Studio and MastraPlatformExporter for hosted Mastra, then add Latitude’s OTLP exporter to the exporters array. Mastra sends each completed span to the configured destinations.

What should I do in serverless Mastra deployments?

Use external storage for persisted Mastra observability and await mastra.observability.flush() before the runtime pauses or exits. Spans are batched with a delay of a few seconds, so the flush is what gives them time to reach Latitude.

Does Latitude sample Mastra traces?

Latitude captures 100% of the traces it ingests within your retention window. Mastra can apply its own trace sampling before export. Latitude’s LLM-based flaggers and evaluations can also sample at analysis time, starting around 10% by default.

Trace your first Mastra workflow

Connect Mastra’s native OTLP exporter, run one production-like agent or workflow, and inspect the complete execution in Latitude.

Start tracing MastraRead the integration guide

No credit card required.