Copy as Markdown[Open in ChatGPT](https://chatgpt.com/?q=Read%20https%3A%2F%2Fcoralogix.com%2Fdocs%2Fuser-guides%2Fdata_exploration%2Fspans%2Fuse-cases%2Funinstrumented-services.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)[Open in Claude](https://claude.ai/new?q=Read%20https%3A%2F%2Fcoralogix.com%2Fdocs%2Fuser-guides%2Fdata_exploration%2Fspans%2Fuse-cases%2Funinstrumented-services.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)

# Identify uninstrumented services

Not every service in a request emits telemetry. A service appears as **uninstrumented** in the dependency map when Coralogix has no spans from it, even though other services in the trace call it. This happens in two distinct situations: the service has no [OpenTelemetry instrumentation](https://opentelemetry.io/docs/concepts/instrumentation/) at all, or it's instrumented but its telemetry never reaches Coralogix. Either way, the service still took part in the request but has no spans of its own to represent it.

Rather than drop these services and show a broken call path, the **Dependencies** view reconstructs them from the spans of the instrumented services around them and marks them as **uninstrumented**. This keeps architectural blind spots visible instead of silently missing from the investigation.

## How an uninstrumented service appears[​](#how-an-uninstrumented-service-appears "Direct link to How an uninstrumented service appears")

Uninstrumented services appear in the **Dependencies** view's **Service view**. They're inferred from the spans of instrumented services that reference them, so you can see where a request went even when the destination emits nothing itself.

* **Dashed border and generic icon**: the node renders with a dashed border and a generic globe icon, in contrast to the solid border and service-specific icon of instrumented services. This applies at both node sizes—the compact circle and the expanded card.
* **Requests count, but `N/A` for Errors and duration**: the node still shows a **Requests** value—the calls made *to* it, counted from the instrumented caller's spans. **Errors** and **Avg. duration** show `N/A`, because those require the service's own spans, which Coralogix never received.
* **Tooltip**: hovering the node shows `Uninstrumented service. No spans were received for operations triggered by this service.`
* **Not selectable for drilldown**: the node can't be opened for drilldown—there are no spans, logs, or metrics of its own to inspect.

[![How an uninstrumented service appears](/docs/assets/images/uninsrumented-service-54751690cf8bffa1b92003c48ddc6471.webp)](https://coralogix.com/docs/docs/assets/images/uninsrumented-service-54751690cf8bffa1b92003c48ddc6471.webp)

## Why it appears only in Service view[​](#why-it-appears-only-in-service-view "Direct link to Why it appears only in Service view")

**Service view** maps the request as a service-to-service graph, so it can place a service on the map using only the references other services make to it. **Span view** and the **Flame** and **Gantt** views represent individual spans—and an uninstrumented service has none—so it has no node to show there. To see uninstrumented services, stay in **Dependencies → Service view**.

## Why a service is uninstrumented[​](#why-a-service-is-uninstrumented "Direct link to Why a service is uninstrumented")

A service shows as uninstrumented for one of two distinct reasons—worth telling apart, because they call for different fixes:

* **Truly uninstrumented**: the service has no OpenTelemetry SDK or agent installed at all, so it emits no spans, logs, or metrics to any backend. This is the strict OpenTelemetry definition of *uninstrumented*. Third-party or managed dependencies (for example, a managed database or SaaS API) usually fall here, since you can't instrument them directly.
* **Instrumented, but data isn't received**: the service *is* instrumented, but its telemetry never reaches Coralogix—for example, a misconfigured exporter, a network failure, or a Collector drop. The service is technically instrumented; Coralogix just isn't getting its data.

**Use it to**

* Reveal architectural blind spots—services in the call path that you have no visibility into.
* Decide where to add instrumentation next, based on which uninstrumented services sit on critical paths.

## What to do next[​](#what-to-do-next "Direct link to What to do next")

To gain full visibility into this service, add OpenTelemetry instrumentation—an SDK or agent that emits spans, logs, and metrics. See the [OpenTelemetry getting started guide](https://coralogix.com/docs/docs/opentelemetry/getting-started/.md) for setup instructions.

If the service is already instrumented but its data isn't arriving, check its export pipeline instead: the exporter configuration, the network path, and any Collector between the service and Coralogix.

Either way, once the service's spans reach Coralogix it renders as a normal instrumented node with live metrics instead of a dashed placeholder.

## Related resources[​](#related-resources "Direct link to Related resources")

* [Visualize spans and traces](https://coralogix.com/docs/docs/user-guides/data_exploration/spans/visualize/.md)
* [Root span states and incomplete traces](https://coralogix.com/docs/docs/user-guides/data_exploration/spans/use-cases/root-span-states-and-incomplete-traces/.md)
* [Understanding traces and spans](https://coralogix.com/docs/docs/user-guides/data_exploration/spans/trace-span-concepts/.md)