Mastra 推出 Trace Queries：让编码智能体定位并修复慢速或失败的运行

Find slow or failed runs for your coding agent to fix.

Oct 14, 2026

4 min read

You can now use trace queries to filter and find traces that match specific criteria. The Mastra platform and local Studio now let you filter by trace fields like time, primitive name, agent/workflow ID, status, score, and feedback. You (or your coding agent) can also construct the same queries using the CLI, Mastra Client SDK, and HTTP observability endpoints.

You can also let your coding agent query for traces that errored out or failed, or slow model calls, and then fix them.

Trace queries usually match fields on the trace itself: when it ran, which agent ran it, and whether it succeeded. The detail that explains a problem often sits deeper, in a failed tool call, a low score, or thumbs-down feedback. Trace queries can reach low-level information nested deep within a trace to provide a more detailed view of what really happened.

Each query covers a timeRange of up to 31 days and can combine up to 100 conditions, using fields like entityName, environment, spans.model, scores.score, and feedback.value, with up to 8 filters on trace internals (spans, scores, or feedback) rather than fields on the trace itself.

Trace queries work on Mastra platform and on self-hosted Mastra projects where storage.observability uses DuckDB, PostgreSQL, or ClickHouse.

Trace queries need a platform access token and your project ID, sent with each request. Use the correct Mastra observability base URL for your project's region:

There are three ways to run queries: Mastra Client SDK, Mastra CLI, and observability endpoints. Each example below finds agent traces from the last 7 days that ended in an error.

Mastra CLI

Install or upgrade the Mastra CLI globally:

Run the mastra api trace query command from your terminal. The CLI reads MASTRA_PLATFORM_ACCESS_TOKEN and MASTRA_PROJECT_ID from your environment:

Mastra Client SDK

Use queryTraces() with MastraClient:

Observability endpoints

You can also send a POST request using the trace query endpoint. The request includes MASTRA_PLATFORM_ACCESS_TOKEN and MASTRA_PROJECT_ID variables in the headers:

For more information and full configuration options, see:

Advanced trace queries reference; Client SDK observability reference; mastra api trace query CLI reference; Observability on Mastra platform; Mastra platform regions

Appendix

Fields and options available to queryTraces():

Combine conditions: and, or, not; Trace: traceId, threadId, resourceId, runId, sessionId, userId, organizationId, entityName, entityType, environment, status, startedAt, endedAt, durationMs, tags, metadata. ; Spans (spans.some, spans.none): name, spanType, model, provider, status, error, startedAt, endedAt, durationMs, entityType, entityId, entityName, entityVersionId, parentEntityVersionId, rootEntityVersionId, runId, sessionId, userId, organizationId; Scores (scores.some, scores.none): scorerId, scorerVersion, scoreSource, score, timestamp, spanId, entityVersionId, parentEntityVersionId, rootEntityVersionId; Feedback (feedback.some, feedback.none): feedbackType, feedbackSource, feedbackUserId, sourceId, value, timestamp, comment, entityVersionId, parentEntityVersionId, rootEntityVersionId; Operators: eq, ne, in, notIn, lt, lte, gt, gte, exists, notExists, includes, notIncludes (tags), matches, notMatches (span name, feedback comment); Pagination: page: { limit, after }, pagination: { page, perPage }, mode: 'delta'; Discovery: getTraceQueryFields(), getTraceQueryValues()

Paul Scanlon sits between Developer Education and Product Marketing at Mastra. Previously, he was a Technical Product Marketing Manager at Neon and worked in Developer Relations at Gatsby, where he created educational content and developer experiences.

On this page