Skip to main content
In Trace0, a Transaction represents a single end-to-end trace across all services involved in handling a request — such as an inbound HTTP request, a message consumed from a queue, etc. You can view the list of transactions for each of your services in the Transactions section: Transactions Light

​
Filtering and Searching

You can filter transactions by service, time period, or using the Errors only toggle. You can also search transactions by free text, returning any transactions where the search term appears in the transaction’s log entries: Transactions Light Additional filters are available by clicking the Filter icon in the top-right corner of the Transactions screen. This opens a pop-up modal containing all available filters: Transactions More Filters Light The current additional filters are: 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.

​
Transaction Detail

To view more details for a single transaction, click on it to see a full breakdown — including all spans, logs, and time taken across each component and service: Transaction Detail Flow Light

Transaction Detail Component Breakdown Light

Transaction Detail Service Breakdown Light

Transaction Detail Runtime Info Light

​
Errors

For transactions that fail, the transaction will appear as an error in Trace0, with the full error details and stack trace included: Transactions Light

​
Tags

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:
Or as fields when using structured logging:
​2. Span attributes Tags can also be added directly as OpenTelemetry span attributes:
Trace0 extracts these values and displays them as Tags on the corresponding transaction. Transaction Tags Light

​
Asynchronous Transactions

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’re linked via two dedicated sections on the Transaction screen:
  • 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.
Consumed By Transactions Section Light

Produced By Transactions Section Light Each entry 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?