How to Find Failed Services and Missing Traces in the .NET Aspire Dashboard

When you run a distributed application with .NET Aspire, the dashboard gives you a central place to inspect services, logs, traces, and other diagnostic information. But sometimes a service appears unhealthy, a request fails, or a trace is missing even though the application seems to be running.

These problems can be confusing when your application contains several projects, such as an ASP.NET Core API, a background worker, and a database. A failure in one service can affect another service, and the dashboard may show only part of the information you need.

The best way to investigate these issues is to check service status, follow the request through its traces, and verify that telemetry is configured correctly.

In this article, we will look at how to use the .NET Aspire dashboard to find failed services, investigate missing traces, and troubleshoot common problems in distributed .NET applications.

What the .NET Aspire Dashboard Shows

The .NET Aspire dashboard helps developers inspect the services and resources that make up a distributed application.

Depending on the application configuration and available telemetry, the dashboard can show:

• Resources such as APIs, workers, databases, and other dependencies.
• Resource states, including whether a resource is running or has encountered a problem.
• Structured application logs.
• Distributed traces that show how a request moves between services.
• Trace spans that represent individual operations within a request.

For example, an API might receive an HTTP request, call a business service, and then query a database. Distributed tracing can help you understand how those operations relate to one another.

However, the dashboard does not automatically guarantee that every operation will appear as a trace. Instrumentation, sampling, context propagation, and telemetry configuration all affect what you can see.

Step 1: Check the Status of Your Services

Start by opening the Aspire dashboard and reviewing the Resources view.

Look for the service associated with the failed request. Check whether it is running, starting, or reporting an error.

A service that fails to start may have a configuration problem, a missing dependency, or an application startup exception.

For example, consider an application containing these resources:

OrderApp
├── order-api
├── order-worker
├── sql-database
└── redis-cache

If the order API is running but the worker is unhealthy, requests handled by the API may still succeed while background processing fails.

Do not assume that a running service is necessarily healthy. A process can start successfully and later fail when it tries to connect to a database or another dependency.

Check the Resource Logs

Select the relevant resource and inspect its logs.

Look for errors related to:

• Application startup.
• Missing configuration values.
• Connection failures.
• Authentication or authorization problems.
• Exceptions thrown while handling requests.

The first useful error often provides more information than the final failure message. For example, a database connection error may explain why a background worker cannot process messages.

If the dashboard does not show enough information, inspect the application's console output or the logs collected by your configured logging provider.

Step 2: Understand the Difference Between Logs and Traces

Logs and traces provide different kinds of information.

Logs describe individual events, such as an exception, a validation failure, or a message received by a worker.

Traces connect operations that belong to the same request or distributed workflow. Each operation is represented by a span, which may contain timing information, attributes, and status details.

Consider this request flow:

Client
  |
  v
Order API
  |
  v
Payment Service
  |
  v
Database

A trace can show how the request moves through these components, provided the relevant operations are instrumented and trace context is propagated correctly.

A log entry can exist without a corresponding visible trace. Likewise, a trace may be available without containing every database or HTTP operation.

This distinction is important when investigating missing telemetry.

Step 3: Find Failed Requests in the Traces View

Open the Traces view in the Aspire dashboard.

If tracing is configured correctly and the relevant data has been collected, you can inspect traces associated with incoming requests and downstream operations.

Look for requests that have failed or taken longer than expected.

Open a trace and examine its spans. A failed span may contain a status indicating an error, along with attributes or events that help explain the failure.

For example, an API request may have a successful incoming HTTP span but a failed outgoing HTTP span when it calls another service.

This tells you that the API received the request, but an operation further down the request path encountered a problem.

When inspecting a trace, ask these questions:

1. Did the incoming request create a trace?
2. Are downstream operations present?
3. Which span first reports an error?
4. Does the span contain useful attributes or events?
5. Do the timestamps and durations help identify where the request slowed down?

A failed trace does not necessarily mean every span failed. Some operations may have succeeded before another operation caused the request to fail.

Step 4: Investigate Missing Traces

A service can appear in the dashboard while its requests are missing from the Traces view.

Several issues can cause this behavior.

OpenTelemetry Instrumentation Is Missing

A running application does not automatically produce detailed spans for every operation.

For example, an ASP.NET Core application may need the appropriate ASP.NET Core instrumentation to create spans for incoming HTTP requests. Outgoing HTTP requests and database operations may require their own instrumentation.

In a typical Aspire application, telemetry configuration may be defined in a shared service-defaults project.

A simplified example looks like this:

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using OpenTelemetry;
using OpenTelemetry.Trace;

var builder = Host.CreateApplicationBuilder(args);

builder.Services
    .AddOpenTelemetry()
    .WithTracing(tracing =>
    {
        tracing
            .AddSource("OrderApp")
            .AddHttpClientInstrumentation();
    });

var app = builder.Build();

await app.RunAsync();

This example illustrates registering a custom activity source and outgoing HTTP client instrumentation. It is not a complete Aspire service-defaults configuration. A real application must also configure the relevant exporters or telemetry pipeline and register instrumentation for the operations it needs to observe.

In Aspire applications, prefer the standard service-defaults setup where appropriate instead of creating separate, conflicting telemetry configurations in every project.

Trace Context Is Not Propagated

Distributed tracing relies on context information to connect operations across service boundaries.

When one service calls another using supported HTTP instrumentation, trace context can usually be propagated automatically. Custom messaging systems and manually created operations may require additional configuration.

If the API creates a trace but the downstream worker creates an unrelated trace, check whether the trace context is being carried across the boundary.

For message-based applications, verify that the producer and consumer correctly propagate and extract the trace context from message headers.

Sampling Excludes Some Traces

OpenTelemetry supports sampling to reduce telemetry volume.

If sampling is enabled, some requests may not be recorded. This can make a trace appear to be missing even though the application processed the request successfully.

Check the sampling configuration before concluding that instrumentation is broken.

For troubleshooting, use a suitable development configuration that records the requests you need to inspect. Avoid enabling unrestricted trace collection in production without considering the volume and cost of telemetry.

Step 5: Add Custom Traces for Important Operations

Automatic instrumentation is useful, but it may not describe the business operations that matter most to your application.

You can create custom activities to trace operations such as processing an order or validating a payment.

For example:

using System.Diagnostics;

public static class OrderDiagnostics
{
    public static readonly ActivitySource ActivitySource =
        new("OrderApp");
}

public class OrderService
{
    public async Task ProcessOrderAsync(
        CancellationToken cancellationToken)
    {
        using var activity =
            OrderDiagnostics.ActivitySource.StartActivity(
                "ProcessOrder");

        activity?.SetTag("order.operation", "process");

        await ValidateOrderAsync(cancellationToken);
    }

    private static Task ValidateOrderAsync(
        CancellationToken cancellationToken)
    {
        cancellationToken.ThrowIfCancellationRequested();

        return Task.CompletedTask;
    }
}

The custom activity identifies the order-processing operation. The tag adds context that can help when inspecting the span.

For this activity to appear in collected traces, the OpenTelemetry configuration must subscribe to the same activity source name, such as through AddSource("OrderApp"), and the telemetry pipeline must export the resulting data to the dashboard or configured backend.

Avoid adding customer names, passwords, access tokens, or other sensitive information to span attributes. Telemetry is diagnostic data, and it may be accessible to more people or systems than the underlying application database.

Step 6: Troubleshoot Common Aspire Dashboard Problems

When troubleshooting, change one setting at a time and repeat the same request. This makes it easier to identify which change affects the telemetry.

Also verify that you are inspecting the dashboard connected to the application instance you are testing. Multiple local application instances or separate telemetry destinations can make valid data appear to be missing.

Best Practices for Reliable Observability

A few practices make distributed application troubleshooting much easier.

First, configure shared telemetry consistently across services. If every project uses a different tracing setup, diagnosing missing spans becomes more difficult.

Second, include useful error details in logs while avoiding sensitive information. A trace can show where a request failed, while the associated logs may explain why.

Third, use consistent trace context propagation across HTTP and messaging boundaries. Without it, one distributed operation may appear as several unrelated traces.

Fourth, test telemetry as part of development and deployment checks. Send a known request, verify that the expected spans appear, and confirm that failures produce useful diagnostic information.

Finally, monitor telemetry export failures and sampling settings. Missing traces are not always caused by application bugs; they can also result from collection and export configuration.

Advantages and Limitations of the Aspire Dashboard

The Aspire dashboard brings resource status, logs, and distributed traces into one place. This reduces the need to inspect every service separately during local development and makes it easier to follow requests across service boundaries.

However, the dashboard can display only the telemetry that the application collects and sends to it. Missing instrumentation, sampling, broken context propagation, and exporter failures can all limit visibility.

The dashboard should therefore be used alongside application logs, configuration checks, and appropriate tests rather than as the only source of diagnostic information.

Summary

When a service fails or a trace is missing in the .NET Aspire dashboard, start by checking resource status and logs. Then inspect the Traces view to identify failed spans and determine where a request stopped behaving as expected.

If traces are missing, verify OpenTelemetry instrumentation, activity source registration, context propagation, sampling, and export configuration.

The key is to distinguish an application failure from a telemetry collection problem. With consistent instrumentation and a repeatable troubleshooting process, you can identify issues across distributed .NET applications without relying on guesswork.