A request succeeds in the frontend but times out through the API and worker path. How would you use the Aspire dashboard and telemetry to diagnose it?

Debug a distributed request with the Aspire dashboard

Uses resource state, structured logs, traces, metrics, health, and configuration evidence to isolate a cross-service failure.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I start in the resource view to confirm which projects and containers are running, healthy, and exposing the expected endpoints. Then I reproduce one request with a correlation or trace context and open its distributed trace. The span timeline shows whether time was spent in the frontend, API, database, outgoing HTTP call, or worker handoff. I inspect the failing or longest span, then use its trace id to view the related structured logs and exception details. Metrics tell me whether this is one request or a broader latency, error, saturation, or queue-backlog pattern. I also compare configuration and endpoint values shown for the affected resource, while keeping secrets hidden. The fix follows the evidence rather than restarting every resource or raising every timeout.

Full answer below

Practice focus

OpenTelemetry correlation, resource state, logs, traces, metrics, dependency latency, queue boundaries, health, and evidence-driven debugging.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
The dashboard is valuable when it connects symptoms across resources, not when it becomes another place to scroll through unfiltered logs. A disciplined investigation moves from user impact to one correlated operation and then to the responsible dependency or resource.
I start in the resource view to confirm which projects and containers are running, healthy, and exposing the expected endpoints. Then I reproduce one request with a correlation or trace context and open its distributed trace. The span timeline shows whether time was spent in the frontend, API, database, outgoing HTTP call, or worker handoff. I inspect the failing or longest span, then use its trace id to view the related structured logs and exception details. Metrics tell me whether this is one request or a broader latency, error, saturation, or queue-backlog pattern. I also compare configuration and endpoint values shown for the affected resource, while keeping secrets hidden. The fix follows the evidence rather than restarting every resource or raising every timeout.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Searching every service log by timestamp without following one trace.
Treating a missing child span as proof the downstream operation never happened.
Raising timeouts before locating where the request budget was spent.
Logging payloads, credentials, or connection strings to make local debugging easier.

A request succeeds in the frontend but times out through the API and worker path. How would you use the Aspire dashboard and telemetry to diagnose it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Technologies

Tech stacks

Skill areas

Suggest an improvement