Skip to main content
Search traces in the web UI when you have a request identifier, a function to investigate or a period of activity to inspect. You need the server URL and read access to its data. A trace is the recording of one instrumented entry-point execution.

​
Connect and choose scope

  1. Open the Vexlo server URL. If a connection screen appears, enter a read token in Read token and select Connect. An ingest token is rejected.
  2. Select Traces in the application bar.
  3. Choose the relevant team. A token covering one team displays its name; a token covering several teams offers a selector, including All my teams.
  4. Choose the deployment in Environment. Unset selects records with no environment label; All environments removes that environment restriction.
A trusted-proxy deployment authenticates through the proxy and does not ask for a browser token. The same applies to a server running with authentication disabled. See Authentication for the supported deployment boundaries.

​
Find an execution by identifier

On the home screen, enter a trace ID to open that recording directly. The UI recognizes a 32-character lowercase hexadecimal trace ID. Other text becomes a search across tag values. For example, entering order-1042 searches recordings tagged with that identifier, regardless of which tag key carries it. Select Search to continue. Use an identifier from your own recorded request. In the checkout example used in The execution graph, the entry point records order_id=order-1042. This tag identifies the request; it is not the trace ID. If you know only the service or function, select Show All Traces from the home screen, then use Service, Root function or Function anywhere in the filter rail. A function filter matches the full function name. Its autocomplete offers names from observed execution.
Function anywhere set to order_service.line_total in the search filter rail.

Filter recordings by an exact function name.

Open the full-size screenshot.

​
Filter recorded executions

Choose a time range and service before adding more specific conditions. Filter changes rerun the search and return to its first page. The fuller checkout in Explore execution graphs returns normally even though its first payment attempt fails. A search with Root status set to error excludes it. Error presence: has error includes it.
Trace results narrowed by service, complete recording, ok root status and has error.

A normally returned checkout that contains a recovered payment error.

Open the full-size screenshot. Custom time ranges use the browser’s local time and cannot span more than seven days. The bounds include both endpoints and filter when the server first received a trace, not the SDK start time displayed under Started. Delayed delivery can put these times in different incident windows. Select one completeness state at a time: checking several states removes completeness narrowing rather than combining them. The UI displays a notice when several are checked. Use Clear all to restore the filter defaults.

​
Work with search results

Results include Trace ID, Service, Entry point, Status, Tags, Started and Duration. The server orders trace search by last-seen time, newest first. Selecting a sortable column changes the order of the current page only; it does not globally reorder all matching traces. The primary status badge shows the root result when it is available. Before the root completion arrives, it shows running or abandoned. Recording loss has a separate coverage indicator, so an ok badge alone does not establish a complete recording.
  • Open a result by selecting its row. A focused row also opens with Enter or Space. The copy icon beside the trace ID copies the ID without opening the trace.
  • Use Next, Previous and rows per page to navigate results.
  • Use the Column visibility icon beside the download control to choose visible columns.
  • Use Download this page, then Download as CSV or Download as JSON, to export the current page’s trace summaries. Export does not fetch all matching results or full traces.
Custom Since and Until fields beside result column visibility options.

Custom time bounds and the Column visibility menu.

Open the full-size screenshot. The filter and pagination state is mirrored in the URL. A bookmarked search restores that state when opened; team and environment remain controls in the application bar.

​
Read search coverage and freshness

A loss banner names services represented in the current results that reported lost or shed records. Service counts in the filter are team-scoped counts over 24 hours, not counts for the current search window. If coverage cannot be loaded, the UI reports that service options, environments and the loss banner can be incomplete. The list refreshes the statuses of visible running traces every five seconds. This updates those rows; it does not continuously fetch a new search result set. An empty search establishes only that nothing matched the chosen scope and filters. Check the team, environment, service and time range before treating absence as missing instrumentation. Once you have the relevant trace, continue with Explore execution graphs. For data that should be present but is not visible, use Troubleshooting. Exact HTTP filters are in HTTP search and metadata.