What's new

You can now add tags to Trace0 transactions and view them directly in the Transaction screen.

Tags let you attach important business context to a transaction, such as a customer ID, order ID, tenant ID, etc.

Tags use the trace0.tag.* namespace and can be added through logs or span attributes.

1. Logs

Tags can be included in standard log messages:

log.info("Processing order trace0.tag.customer.id=12345");

Or as fields when using structured logging:

{
  "message":"Processing order",
  "trace0.tag.customer.id":"12345"
}

​2. Span attributes

Tags can also be added directly as OpenTelemetry span attributes:

span.setAttribute("trace0.tag.customer.id", "12345");

Trace0 extracts these values and displays them as Tags on the corresponding transaction.

You can now view the runtime environment for every transaction by opening the Runtime section on the Transaction screen.

This section displays information about the environment in which the transaction executed. Depending on the cloud provider and compute platform, you’ll see details such as the region, availability zone, host, container, and other runtime-specific metadata.

Here’s an example of a transaction that executed on an EC2 instance:

And here’s an example of a transaction that executed in AWS Lambda:

Having this information alongside the Flow and Breakdown gives you additional context about where a transaction executed, helping you debug issues faster.

For transactions that involve multiple services, Trace0 combines the runtime information from each service into a single view, making it easy to see every environment involved in handling a request.

We have released two new dedicated sections on the Transaction screen that allow you to trace asynchronous transactions:

• Consumed By — the downstream transaction(s) that consumed the message(s) this transaction sent.

• Produced By — the upstream transaction(s) that sent the message(s) this transaction consumed.

Why is this needed?

Asynchronous transactions are transactions triggered independently of the transaction that originally initiated them — for example, a Lambda function reading messages from an SQS queue, or an ECS task consuming messages from a Kafka topic.

Unlike a typical synchronous call (e.g. an HTTP request), these transactions aren’t a direct extension of the transaction that triggered them. This creates two challenges for standard trace visualization:

1. Duration doesn’t roll up naturally. It wouldn’t make sense to include the duration of a downstream transaction (e.g. an SQS consumer) as part of the duration of the transaction that produced the message (e.g. the producer Lambda) — the two run independently, often at completely different times.

2. A single transaction can have multiple sources. A consumer might process a batch of several messages in one invocation, and those messages could have been sent by different upstream transactions.

For these reasons, asynchronous transactions aren’t shown in the Flow section of the triggering transaction the way a normal synchronous call would be. Instead, they are show in these new Consumed By and Produced By sections.

Each entry in the sections includes the transaction summary and a link to the detailed view for that transaction, so you can navigate between them directly. This makes it easy to answer questions such as:

• Did any of my downstream async services fail?
• Which transaction sent the message that triggered this one?

Search filters for Transactions and Logs are now stored in the page URL, making it easy to bookmark searches or share them with your colleagues. Once you open the link, it automatically restores the same search criteria.

Here is an example from the Transactions page showing search filters reflected in the page URL:

And here is an example from the Logs page showing search filters reflected in the page URL:

We’ve released our MCP server. This means you can now connect Claude Code, Cursor, and other MCP-compatible AI agents to Trace0 to investigate errors, analyze performance, and troubleshoot issues faster.

Authentication

The Trace0 MCP server uses OAuth for authentication. Simply add the server URL (https://app.trace0hq.com/api/mcp) to your MCP client, and you’ll be redirected to your browser to sign in to your Trace0 account and authorize access. See our docs for full instructions.

Tools

The Trace0 MCP server provides the following tools for querying your environments, services, transactions, logs, and metrics:

Tool	Description
get_environments	Returns the names of all environments in the authenticated user’s Trace0 account.
get_services	Returns the name and programming language of all services in the given environment.
get_transactions	Returns the summaries of transactions matching the specified filters.
get_transaction_detail	Returns the transaction details for the given transaction ID.
get_log_count	Returns the number of logs matching the specified filters, aggregated by service name, severity level and time bucket.
get_service_metric_summaries	Returns metric summaries for all services in the given environment and time period.
get_service_metrics	Returns detailed metrics for a specific service in the given environment and time period, aggregated by time bucket.

Fair Use Limits

The Trace0 MCP server comes with the following fair-use limits:

• 50,000 monthly tool calls

Once a limit is exceeded, the MCP server will return an error describing the applicable restriction.

If you require higher limits, please contact us at [email protected] to discuss.

We’ve shipped new transaction search functionality. You can now apply the following filters to your transaction search:

• Latency — set a minimum or maximum duration in milliseconds or seconds to focus on slow or fast requests.

• HTTP Status Code — filter to all 4xx errors, all 5xx errors, or a specific code like 404 or 503.

• Endpoint — filter by the endpoint that handled the request.

• Log Search — show only transactions where any of its log entries contain the search term.

How to use it

Open the Transactions screen and click the More Filters icon in the top right:

You can then add additional filters from the pop-up modal. Filters are combined using AND logic, so only transactions matching all applied filters are returned, including any already set in the Transactions screen, such as Service or Time Period.