What's new

Trace0 now shows Node.js runtime metrics for services running on Node.js, alongside the request metrics you already see for each service. They come from the OpenTelemetry metrics the V8 and Node.js runtimes report, as defined by the OpenTelemetry semantic conventions for V8 JS metrics and the OpenTelemetry semantic conventions for Node.js metrics, so services using the OpenTelemetry JavaScript SDK (with auto-instrumentation or with the @opentelemetry/instrumentation-runtime-node module registered) report them without any extra setup.

The metrics include garbage collection duration per GC type, heap space used per space, active resources, event loop delay stats, and more.

Service Instances

Each instance of your service runs reports its own runtime metrics, so you view them one instance at a time. Trace0 identifies each instance from the resource attributes your service reports, such as the ECS Task ARN or Service Instance ID.

To view Node.js runtime metrics for one of your services, open the Metrics section, click View more for the service and select an instance from the instance filter. The example below shows the Node.js runtime metrics for a Node.js service running on ECS:

See our Node.js Metrics user guide for the full list of metrics and how each one is calculated.

Available via MCP

Node.js runtime metrics are also available to your AI agents through the Trace0 MCP server get_application_metrics tool. If the agent doesn’t pass an instance, the response lists the instance IDs it can pass to load the metrics for one instance.

When a JVM service slows down, there are many possible causes, such as long garbage collection pauses, heap usage nearing its limit, or blocked threads. JVM runtime metrics help you identify which one is responsible.

Trace0 now shows JVM runtime metrics for services running on the JVM, alongside the request metrics you already see for each service. They come from the OpenTelemetry metrics the JVM reports, as defined by the OpenTelemetry semantic conventions for JVM metrics, so services using the OpenTelemetry Java agent report them without any extra setup.

The metrics include heap and non-heap memory per memory pool, garbage collection duration per collector, thread counts by thread state, buffer pool usage, loaded classes, CPU usage, open file descriptors, and more.

Service Instances

Each instance of your service runs its own JVM and reports its own runtime metrics, so you view them one instance at a time. Trace0 identifies each instance from the resource attributes your service reports, such as the ECS Task ARN or Service Instance ID.

To view JVM runtime metrics for one of your services, open the Metrics section, click View more for the service and select an instance from the instance filter. The example below shows the JVM runtime metrics for a Java service running on ECS:

See our JVM Metrics user guide for the full list of metrics and how each one is calculated.

Available via MCP

JVM runtime metrics are also available to your AI agents through the Trace0 MCP server get_application_metrics tool. If the agent doesn’t pass an instance, the response lists the instance IDs it can pass to load the metrics for one instance.

Cloud services like S3, KMS, and SES often handle important parts of an application’s request path, so their performance can affect application latency and reliability. Tracking request volume, latency, and errors for these services makes it easier to identify which cloud dependencies are slowing down requests or causing failures.

Trace0 now collects metrics for calls your service makes to these managed cloud services, alongside the rest of your service metrics.

Calls made through the AWS SDK are captured automatically, and for each service you can see request rate, latency, and error rate, broken down by operation.

To view metrics for a cloud service used by one of your services, open the Metrics section and click View more for the service. The cloud services used by the service appear in the toggle at the top of the page. The examples below show metrics for Amazon S3 and KMS:

The metrics include request count, requests per second, latency, and error rate, all broken down by operation, such as GetObject for S3, Decrypt for KMS, etc.

See our Cloud Service Metrics user guide for full details.

Available via MCP

Cloud service metrics are also available to your AI agents through the Trace0 MCP server get_cloud_service_metrics tool.

Database activity is often a major part of a service’s request path, so database performance can have a direct effect on application latency and reliability. Seeing request volume, latency, and errors at the database level makes it easier to identify which tables or operations are responsible when a service starts behaving differently.

Trace0 now provides database client metrics alongside the rest of your service metrics.

To view database metrics for a service, open the Metrics section and click View more for the service. Database systems used by the service appear in the toggle at the top of the page. In the example below, the service uses DynamoDB.

The database metrics include request count, requests per second, latency, and error rate. You can view these metrics by table and operation, such as GetItem for DynamoDB, HGET for Redis, or SELECT for PostgreSQL.

See our Database Metrics user guide for full details.

Available via MCP

Database metrics are also available to your AI agents through the Trace0 MCP server get_database_metrics tool.

Uncorrelated error logs in OpenTelemetry are log records that do not contain a Trace ID.

These logs can be especially useful during an incident. They often capture startup failures, background-job errors, connection drops, or errors logged after a span has closed, where there is no trace to associate the error with.

Trace0 now displays these logs directly in the Triggered Alert view for the given error or exception, so you can see relevant errors even when they are not associated with a transaction.

When an alert is triggered, you need to quickly understand what happened and who was affected. Our new Triggered Alerts section gives you the context you need to investigate immediately.

Alongside notifying your configured Destinations, Trace0 now adds each occurrence to the Triggered section in the Alerts screen, where you can view its details.

Error Alert Detail

For triggered error alerts, you can view the alert Volume Over Time, the Tags Involved to understand which users, customers, orders, or other business entities were affected (see Tags for more details), and the Failing Transactions that triggered the alert.

Metric Alert Detail

For triggered metric alerts, you can view the alert Volume Over Time, the Tags Involved to understand which users, customers, orders, or other business entities were affected (see Tags for more details), and the Contributing Transactions that led to the metric threshold being exceeded.

Available via MCP

Triggered alerts are also available through the Trace0 MCP server, allowing your AI agents to investigate alerts using the same context available in Trace0.

• get_triggered_alerts_summaries — Returns summaries of alerts triggered within a specified time period.
• get_triggered_alert_detail — Returns detailed information for a triggered alert, including the tags and transactions involved.

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 hello@trace0hq.com 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.