> ## Documentation Index
> Fetch the complete documentation index at: https://docs.honeycomb.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Common Issues with Visualization

> Troubleshoot common problems with Honeycomb Home, Board Templates, Service Map, and other visualization features not displaying data as expected.

If you need to troubleshoot your visualizations, explore these solutions to common issues.

<Tip>
  To ask questions and learn more, visit our [Support Knowledge Base](https://support.honeycomb.io/) or [join our Pollinators Community](/troubleshoot/community/).
</Tip>

## Home

Troubleshoot visualizations in [Honeycomb Home](/observe/honeycomb-home/).

### Traces View

Troubleshoot visualizations on the **Traces** view in [Honeycomb Home](/observe/honeycomb-home/).

#### Traces view is empty

If your dataset is not a tracing dataset, then the **Traces** view will not populate.

To ensure the **Traces** view is populated, either:

* send a source field named `trace.trace_id` to Honeycomb, which will let Honeycomb detect and map dataset fields automatically, or
* manually map a source field to the **Trace ID** dataset field when you [map your data](/send-data/standardize/map-data/)

#### Empty Span Visualizations

"Total Spans", "Span Volume", "Spans by Type", "p95 of Span Duration", and "Top Spans" rely on a source field being mapped to the **Span Id** dataset field.

To ensure the visualizations are populated, either:

* send a source field named `span.id` to Honeycomb, which will let Honeycomb detect and map dataset fields automatically, or
* manually map a source field to the **Span Id** dataset field when you [map your data](/send-data/standardize/map-data/)

#### Empty Duration Visualizations

The "P95 of Span Duration" visualization relies on a source field being mapped to the `duration` dataset field.

To ensure the visualizations are populated, either:

* send a source field named `duration_ms` to Honeycomb, which will let Honeycomb detect and map dataset fields automatically, or
* manually map a source field to the **Span Duration** dataset field when you [map your data](/send-data/standardize/map-data/)

#### Empty Total Exceptions and Top Exceptions Visualizations

"Total Exceptions" and "Top Exceptions" visualizations rely on the `exception.message` field being available.
To learn how to record `exception` with OpenTelemetry, visit [OpenTelemetry's documentation on exceptions](https://opentelemetry.io/docs/specs/otel/trace/exceptions/).

#### Empty Exception Volume By Type Visualizations

"Exception Volume By Type" relies on the `exception.type` field being available.
To learn how to record `exception` with OpenTelemetry, visit [OpenTelemetry's documentation on exception spans](https://opentelemetry.io/docs/specs/semconv/exceptions/exceptions-spans/).

### Logs View

Troubleshoot visualizations on the **Logs** view in [Honeycomb Home](/observe/honeycomb-home/).

#### Logs view is empty

If your dataset is not a logs dataset, the **Logs** view will not populate.

To ensure the **Logs** view is populated, either:

* send a source field named `body` to Honeycomb, which will let Honeycomb detect and map dataset fields automatically, or
* manually map a source field to the **Logs: Message** dataset field when you [map your data](/send-data/standardize/map-data/)

#### Severity visualizations are empty

Severity visualizations rely on a source field being mapped to the **Logs: Severity** dataset field.

To ensure the Severity visualizations are populated, either:

* send a source field named `severity` to Honeycomb, which will let Honeycomb detect and map dataset fields automatically, or
* manually map a source field to the **Logs: Severity** dataset field when you [map your data](/send-data/standardize/map-data/)

#### "Logs by Severity" chart shows only non-standard (Other) severities

The Logs by Severity Chart supports standard severities, which include `fatal`, `error`, `warn`, `info`, `trace`, `debug`, and `unspecified`.
If you are sending non-standard severities, the chart will label them as `Other`.

To ensure the "Logs by Severity" chart shows your severities, use Calculated Fields to [parse your severity values into Honeycomb standard severity values](/send-data/standardize/transform-data/#transform-source-severities-into-honeycomb-standard-severities).

### Explore Data View

#### Log lines are not color-coded by severity

Severity visualizations rely on a source field being mapped to the **Logs: Severity** dataset field.

To ensure the Severity visualizations are populated, either:

* send a source field named `severity` to Honeycomb, which will let Honeycomb detect and map dataset fields automatically, or
* manually map a source field to the **Logs: Severity** dataset field when you [map your data](/send-data/standardize/map-data/)

In addition, if you are using non-standard severities, use Calculated Fields to [parse your severity values into Honeycomb standard severity values](/send-data/standardize/transform-data/#transform-source-severities-into-honeycomb-standard-severities).

## Board Templates

Troubleshoot visualizations in [Board Templates](/observe/boards/templates/).

### A Board template is missing a query

Visualizations in board templates depend on specific fields being available in your data.
Add additional insights and eliminate missing queries by configuring or sending the required fields.
Sending the necessary data populates the templates with more queries.
You can also choose to select different fields to populate each query within the **Setup** view.
For more information, refer to our [available templates](/observe/boards/templates/#board-templates-at-a-glance) and their required fields.

## Service Map

Troubleshoot visualizations in [Service Map](/observe/service-map/).

### My map is empty

1. Confirm that your [Dataset fields in Dataset Definitions](/configure/datasets/definitions/) are defined with Field name values.

   Service Map generates automatically from trace data sent to Honeycomb and, with the exception of **timestamp**, is based on these defined Tracing fields:

   | Role           | OpenTelemetry/Honeycomb field names           | Description                                                                                                                                                                                                                                                                                            |
   | -------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
   | Service Name   | `service.name`, `serviceName`, `service_name` | Name of the instrumented service. Becomes the map node identity.                                                                                                                                                                                                                                       |
   | Span ID        | `trace.span_id`, `id`                         | Unique identifier of the span.                                                                                                                                                                                                                                                                         |
   | Timestamp      | `time` (not mapped via Dataset Definitions)   | Start time of the span. Places the dependency in the selected time range. With OpenTelemetry, your SDK sets this automatically. If a span arrives without a timestamp, Honeycomb defaults to the time of arrival.                                                                                      |
   | Span Duration  | `duration_ms`, `durationMs`                   | Amount of time in milliseconds that the span took to complete. Used for latency display. With OpenTelemetry, Honeycomb usually populates `duration_ms` from the span's start and end timestamps during ingest. If you send spans through another path, confirm a duration field is present and mapped. |
   | Parent Span ID | `trace.parent_id`, `parentId`                 | Unique identifier of the span's parent span or the call location the current span was called from. Any child span must include a parent ID to be mapped properly; a span with no parent ID is treated as a root span rather than dropped.                                                              |
   | Trace ID       | `trace.trace_id`, `traceId`                   | Unique identifier of the trace that the span belongs to. Groups spans into one trace.                                                                                                                                                                                                                  |

   If any of this data is missing or undefined, the map will not display.

2. Check back in a few minutes to confirm if the Service Map has generated.
   Service Map may take up to a few minutes to generate after you start sending data to Honeycomb.

### My map contains only one disconnected service

Make sure you are sending traces that include more than one service.

Service Map generates based on trace data sent to Honeycomb and visualize edge connections between services.
If your trace includes only one service, that singular service will display as one disconnected node.

### My map contains multiple services, but one service is disconnected

Disconnected services have little or no cross-service dependency in the selected window.
Common causes:

| Cause                     | What to check                                                                 |
| ------------------------- | ----------------------------------------------------------------------------- |
| Incomplete traces         | Child spans reference a `trace.parent_id` whose parent span never arrived     |
| Missing parent IDs        | Non-root spans lack `trace.parent_id`, so Honeycomb can't join the call chain |
| Same-service-only traffic | Parent and child share the same `service.name`, so no edge is created         |
| Sampling                  | Quiet paths weren't selected into the dependency sample                       |
| Gateway collapse          | Intermediate services are folded into gateway hops                            |
| Narrow time range         | Cross-service calls happened outside the selected window                      |

The diagrams below illustrate the most common cause: an incomplete trace.
In a complete trace, each span's `trace.parent_id` resolves to a real parent span, so Honeycomb can walk the full chain and record the cross-service edges.
In an incomplete trace, a child span's `trace.parent_id` points to a parent span that never arrived.
Honeycomb can't join that child to its parent, so the child appears disconnected, an island, instead of connected to the rest of the trace.

Complete trace:

```mermaid theme={}
graph TD
    P[Parent span - Service A] --> C[Child span - Service B]
    C --> GC[Grandchild span - Service C]
```

Incomplete trace, missing parent:

```mermaid theme={}
graph TD
    M[Missing parent span - never arrived]
    C2[Child span - Service B] -.->|trace.parent_id points here| M
    C2 --> GC2[Grandchild span - Service C]
```

#### Validating parent-child linkage in your traces

In Query Builder or your own scripts, investigate:

* **Required fields present.** Count spans missing `service.name`, `trace.trace_id`, `trace.span_id`, or `duration_ms`.
* **Orphaned children.** Spans with `trace.parent_id` set where no span in the same `trace.trace_id` has that ID as `trace.span_id`.
* **Cross-service children.** For services that should be connected, confirm child spans exist whose parent span has a different `service.name`.
* **Roots that never call out.** Root spans with no different-service descendants appear as disconnected or entry-only nodes.

### A service is missing from my map

Confirm the service has spans in the time range.
In [Query Builder](/investigate/query/build/), run:

```
VISUALIZE COUNT
WHERE service.name = <service name>
```

If the returned count is 0, the map is correctly omitting it for that window.
If the returned count is greater than zero:

* Wait a few minutes for recently ingested traffic to appear

* Confirm Dataset Definitions for service name, trace ID, span ID, parent span ID, and duration

* Expand the time range to view a larger sample; sampling may hide low-volume services

* Check whether the service is classified as a gateway (`net.component: proxy` or `component: proxy` attributes).
  In [Query Builder](/investigate/query/build/), run:

  ```
  VISUALIZE COUNT
  WHERE service.name = <service name>
  GROUP BY `component:proxy`, `net.component:proxy`
  ```

* Confirm the span's timestamp reflects when the call actually happened; clock skew or delayed export can push a span outside the selected time range even though the service has current trace volume

### My instrumented gateways do not appear on my map

If you [instrumented gateways](/observe/service-map/#instrumenting-for-gateways) and they still do not appear on your map, your gateway requests may not occur between known services.
Service Map only displays gateways on an edge, which is formed when one service send requests to another service.
If an edge does not exist, either because a service does not send requests to another service or because the service sends requests to another service through multiple gateways, then gateways may not display on your map.

If either of these scenarios are common in your architecture, join #discuss-service-map in our [Pollinators Community Slack](/troubleshoot/community/#join-pollinators-community-slack) and let us know.

### All services point to the gateway service

Make sure you have [instrumented for gateways](/observe/service-map/#instrumenting-for-gateways), so Service Map can represent them appropriately.

### The map shows too many services

Apply service filters, isolate a service, or filter traces to a journey attribute.
If you routinely exceed hundreds of distinct service names, revisit how `service.name` is assigned in instrumentation.

### My map is dense and hard to read

Narrow your map to a specific set of services using the [**Services**](/reference/honeycomb-ui/service-map/#select-services) or [**Filter Traces**](/reference/honeycomb-ui/service-map/#filter-traces) dropdowns.
After narrowing down to a smaller diagram, hover over a specific service on the map and select **Isolate** to display all dependencies (incoming and outgoing services) for the selected service.

### When I apply filters, an expected service or path does not display

When filter parameters are applied to the Service Map, the results return a maximum of 10,000 traces.
These traces are then displayed on the Service Map when using Filters and/or selectively displayed when using the Service Filter.

Because of the applied limit, sometimes very low volume traces may not be represented in the returned sample.

### When I filter my map, a "No Service Map data found" error appears, but I found a trace that matches the filter set

Filters find traces with at least one span that matches all filters you have entered.
For example, if the filters of `app.cart.items &gt; 5` AND `app.user.currency = USD` are set in [**Filter Traces**](/reference/honeycomb-ui/service-map/#filter-traces), then the map displays traces that have at least one span that matches both filters.
If the fields used in your filters exist across different spans in a trace, a result is not returned.
If possible, try propagating context throughout your traces to enable filters to return matching results.

### Sample traces are empty when I select a service

The right panel's sample traces for a service are based on dependencies where that service appears as the callee (child) of an edge.

You may see a node with no sample traces when:

* The service only appears as a caller in the selected window; it calls others, but nothing calls it in the sampled dependencies
* Active UI filters exclude all matching traces
* Sampling or time range left no child-side dependencies for that service

Try:

* Clearing trace filters
* Widening the time range
* Selecting an edge into or out of the service and inspecting edge sample traces
* Using Isolate on the service to inspect neighbors

### p95 latency for services and edges in Service Map do not match p95(duration\_ms) in Query Builder

This difference is expected.
Service Map calculates the `p95` duration for services and edges differently from the `p95(duration_ms)` query in Query Builder.

Service Map latency calculations include synchronous spans, which communicate between services.
Query Builder latency calculations includes both synchronous and asynchronous, or internal, spans.