Aspire Monitoring

Name: Aspire Monitoring
Author: microsoft

microsoft/aspire-skills

124 installs
74 repo stars
Updated July 27, 2026
microsoft/aspire-skills

aspire-monitoring is an agent skill that observes Aspire apps via CLI logs, OpenTelemetry traces, resource state, and dashboard telemetry with deployed diagnostics routing.

About

The aspire-monitoring skill observes Aspire applications through logs, traces, metrics, resource state, telemetry export, browser telemetry, and the standalone dashboard. It routes between local Aspire CLI commands and deployed platform diagnostics including kubectl for AKS workloads, azure-diagnostics for Azure resources, and docker for Compose containers. Local investigation follows describe resource state, structured aspire otel logs, console aspire logs, distributed traces, and aspire export for zipped telemetry snapshots. Commands cover aspire logs, aspire otel logs, aspire otel traces, aspire otel spans, aspire describe with optional --include-hidden for proxies and helper containers, aspire ps, and aspire dashboard run for OTLP-emitting apps without an AppHost. Agents should use --format Json for machine parsing, retry with --include-hidden when resources are missing, and run aspire dashboard run asynchronously because it blocks until stopped. Browser telemetry from Aspire.Hosting.Browsers surfaces console logs and network data when WithBrowserLogs is wired, while AppHost edits route to aspireify. Handoffs send lifecycle commands to aspire-orchestration, deployment to aspir.

Diagnostics bridge table routes local CLI versus deployed platform tools.
Five-step investigation workflow from describe through telemetry export.
Supports aspire otel logs, traces, spans, and --include-hidden resources.
Documents standalone aspire dashboard run with OTLP and async agent usage.
Handoffs lifecycle, deployment, and AppHost authoring to sibling skills.

Aspire Monitoring by the numbers

124 all-time installs (skills.sh)
Ranked #500 of 1,453 DevOps & CI/CD skills by installs in the Skillselion catalog
Data as of Jul 28, 2026 (Skillselion catalog sync)

At a glance

aspire-monitoring capabilities & compatibility

Capabilities: local versus deployed diagnostics routing bridge · aspire cli logs traces spans and describe comman · hidden resource discovery with include hidden fl · standalone dashboard run and otlp connection · browser telemetry inspection and handoff rules
Works with: azure · kubernetes · docker
Use cases: devops · debugging

npx skills add https://github.com/microsoft/aspire-skills --skill aspire-monitoring

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

[![Listed on Skillselion](https://skillselion.com/badge/skills/microsoft/aspire-skills/aspire-monitoring.svg)](https://skillselion.com/skills/microsoft/aspire-skills/aspire-monitoring)

Installs	124
repo stars	★ 74
Last updated	July 27, 2026
Repository	microsoft/aspire-skills ↗

How do I inspect Aspire app logs, traces, and resource health locally or on deployed Azure and AKS platforms?

Observe Aspire apps locally via CLI logs, traces, metrics, and dashboard telemetry with routing to deployed platform tools.

Who is it for?

Developers debugging running Aspire apps who need logs, OTEL traces, describe output, or dashboard telemetry inspection.

Skip if: Skip for aspire start/stop lifecycle, AppHost code edits, or Azure provisioning workflows.

When should I use this skill?

User asks for aspire logs, aspire otel traces, aspire describe, aspire dashboard run, or browser logs in dashboard.

What you get

Structured telemetry from Aspire CLI or routed platform tools with resource state and exportable snapshots.

Files

SKILL.mdMarkdownGitHub ↗

Aspire Monitoring

Aspire CLI provides full observability locally. For deployed apps, route to platform-specific tools.

Diagnostics Bridge — Where To Look

Need	Environment	Tool	Command / Route
Console logs	Local dev	Aspire CLI	`aspire logs <resource>`
Structured logs	Local dev	Aspire CLI	`aspire otel logs [resource]`
Distributed traces	Local dev	Aspire CLI	`aspire otel traces [resource]`
Span detail	Local dev	Aspire CLI	`aspire otel spans [resource]`
Resource state	Local dev	Aspire CLI	`aspire describe` (add `--include-hidden` if a resource is missing)
Telemetry export	Local dev	Aspire CLI	`aspire export [resource]`
Standalone dashboard	Any (no AppHost)	Aspire CLI	`aspire dashboard run` (foreground/blocking — see below)
Browser console / network / screenshots	Local dev (frontend)	Aspire dashboard	Surfaced via `Aspire.Hosting.Browsers` + `WithBrowserLogs()`
AppHost / deployment definition	Authoring	aspire-deployment skill	→ `aspire-deployment` skill
AKS workload (pod logs, pod state)	Deployed AKS	kubectl + Container Insights	`kubectl logs <pod>`, `kubectl describe pod <pod>`, Container Insights in Azure Monitor
Azure resource health (App Insights, Front Door, NSP, private endpoint)	Deployed Azure	azure-diagnostics	→ `azure-diagnostics` skill
App Service / Container Apps logs	Deployed Azure	azure-diagnostics	→ `azure-diagnostics` skill
Logs/state	Deployed Docker / Compose	Docker CLI	`docker logs <container>`, `docker compose logs <service>`

Decision tree:

1. Is this about AppHost code or deployment definition? → aspire-deployment skill. 2. Is the app running locally via aspire start? → Aspire CLI. 3. Is it deployed to AKS? → kubectl + Container Insights for workload; azure-diagnostics for the cluster's Azure resources. 4. Is it deployed to other Azure (App Service, Container Apps)? → azure-diagnostics. 5. Is it deployed to Docker / Compose? → docker / docker compose CLI.

See diagnostics-bridge.md for detailed routing.

Investigation Workflow

When something is wrong, investigate before editing code:

1. aspire describe — check resource state and endpoints 2. aspire otel logs <resource> — structured logs first 3. aspire logs <resource> — console output as secondary view 4. aspire otel traces <resource> — cross-service activity 5. aspire export — zipped telemetry snapshot for deeper analysis

Local Commands Reference

Command	Purpose	Example
`aspire logs <resource>`	Console stdout/stderr	`aspire logs apiservice`
`aspire logs --follow`	Stream logs in real-time	`aspire logs apiservice --follow`
`aspire otel logs`	Structured OpenTelemetry logs	`aspire otel logs`
`aspire otel traces`	Distributed trace data	`aspire otel traces`
`aspire otel spans`	Individual span detail	`aspire otel spans`
`aspire otel logs --trace-id <id>`	Logs correlated to trace (⚠️ verify flag)	`aspire otel logs --trace-id abc123`
`aspire otel logs --dashboard-url`	Query a standalone dashboard (login URL or base URL + `--api-key`)	`aspire otel logs --dashboard-url "http://localhost:18888/login?t=TOKEN" --follow`
`aspire otel traces --dashboard-url`	Query a standalone dashboard	`aspire otel traces --dashboard-url "http://localhost:18888/login?t=TOKEN"`
`aspire describe`	Resource state, endpoints, health	`aspire describe --format Json`
`aspire describe --include-hidden`	Include proxies, helper containers, migrations	`aspire describe --include-hidden --format Json`
`aspire ps --format Json`	Resource list with state (filtered)	`aspire ps --format Json`
`aspire ps --include-hidden --format Json`	Resource list with hidden resources	`aspire ps --include-hidden --format Json`
`aspire export`	Portable telemetry bundle	`aspire export`
`aspire dashboard run`	Standalone dashboard (foreground/blocking)	`aspire dashboard run`

Hidden resources are filtered by default

aspire ps, aspire describe, and other CLI commands filter out resources marked hidden in the AppHost (proxies, helper containers, migrations). The default output is correct for normal app inspection. Add --include-hidden when:

Debugging proxies, sidecar/helper containers, or migration jobs.
An expected resource is "missing" from aspire ps / aspire describe.
Triaging connectivity or wiring issues that may involve infrastructure resources.

Tips for Agents

# ✅ Use --format Json for machine parsing (supported: ps, describe, start)
aspire describe --format Json

# ✅ When a resource you expect is missing, retry with --include-hidden
aspire ps --include-hidden --format Json | jq '.[] | {name, displayName, state, hidden}'

# ✅ Get endpoints from describe, not guessing ports
ENDPOINT=$(aspire describe apiservice --format Json | jq -r '.endpoints[0].url')

# ✅ Use --apphost <path> when multiple AppHosts exist
aspire describe --apphost ./src/MyApp.AppHost/

Known Diagnostics Issues

Issue	Symptom	Workaround
TS AppHost DNS failure (#15782)	`aspire otel` "No such host" for `*.dev.localhost`	Use `--dashboard-url localhost:PORT`
`--isolated` mode telemetry (#16107)	OTEL port not randomized in isolated mode	Avoid `--isolated` if telemetry is needed
Resource missing from `aspire ps` / `aspire describe`	Hidden-by-default resources such as proxies, helpers, or migrations	Re-run with `--include-hidden`

Resolved in 13.3: The standalone-dashboard workaround for #16236 is obsolete — use aspire dashboard run (see below).

Standalone Dashboard (`aspire dashboard run`)

aspire dashboard run launches the Aspire Dashboard without an AppHost, so any OTLP-emitting application (Aspire or not) can stream telemetry into it.

aspire dashboard run
# Dashboard:  http://localhost:18888/login?t=<TOKEN>
# OTLP/gRPC:  http://localhost:4317
# OTLP/HTTP:  http://localhost:4318

⚠️ Foreground / blocking. aspire dashboard run does not return until you stop it (Ctrl-C). Agents must treat it as a long-running background process — start it with the bash tool's mode="async", capture the dashboard URL and token from initial output, and leave it running. Do not invoke it as a one-shot synchronous command, and do not wait for it to "finish".

Connect the Aspire CLI to a standalone dashboard

aspire otel logs and aspire otel traces accept --dashboard-url. The simplest form passes the full login URL printed by aspire dashboard run — the CLI normalizes it automatically:

# Stream structured logs from a standalone dashboard (login URL form)
aspire otel logs --dashboard-url "http://localhost:18888/login?t=TOKEN" --follow

# Search recent traces
aspire otel traces --dashboard-url "http://localhost:18888/login?t=TOKEN"

For dashboards configured with API-key authentication (e.g., the standalone container image with a separate API key), pass --api-key alongside the base --dashboard-url:

aspire otel logs --dashboard-url https://my-dashboard.example.com --api-key "$DASHBOARD_API_KEY" --follow

The container-image standalone dashboard still works for environments where the CLI isn't available.

Browser Telemetry (`Aspire.Hosting.Browsers`)

The Aspire.Hosting.Browsers integration captures browser console logs, network requests, and screenshots from frontend resources during local development and surfaces them in the dashboard alongside server-side telemetry. Frontend resources opt in via WithBrowserLogs().

Need	Action
Inspect browser telemetry that is already wired	Open the dashboard; browser logs / network / screenshots appear next to server telemetry for the resource
Confirm a frontend has it enabled	Check the AppHost for `.WithBrowserLogs()` on the resource (e.g., `AddViteApp("frontend").WithBrowserLogs()`)
Add `WithBrowserLogs()` to a resource	→ `aspireify` skill (AppHost authoring) — do not edit the AppHost from this skill

When parsing telemetry programmatically, browser logs surface as additional OTLP log records associated with the frontend resource — aspire otel logs <frontend-resource> returns them alongside server logs.

Dashboard UX Features

Agents inspecting a running dashboard should know:

Notification center (bell icon, top-right) — surfaces results of resource commands and lifecycle events. Inline command responses appear here instead of being scraped from the logs panel.
Rebuild command — available on container and project resources; rebuilds the image and restarts the resource without restarting the whole AppHost. Result lands in the notification center.
Structured command results — custom resource commands return ExecuteCommandResult with a Message payload that the dashboard renders inline; HTTP commands set HttpCommandResultMode.Auto | Json | Text | None to control how the response body is shown.

Authoring custom commands or WithBrowserLogs() calls is AppHost work — route to `aspireify`. This skill is for observing what those features surface in the dashboard.

Why Aspire CLI Can't Do Remote Diagnostics

The Aspire CLI talks to a running AppHost through a local backchannel socket at ~/.aspire/backchannels/. This is by design — there is no remote backchannel. For deployed apps, route to platform-specific tools (azure-diagnostics, kubectl, docker).

Exception: if a Dashboard is reachable (deployed alongside the app, or running standalone), aspire otel logs and aspire otel traces can query it via --dashboard-url (login URL form) and optional --api-key (see the Standalone Dashboard section above). This does not apply to aspire logs or aspire describe.

Handoff Rules

Scenario	Route To
Start/stop/wait/rebuild lifecycle	→ `aspire-orchestration` skill
Deploy, publish, pipeline steps, AppHost compute environment binding	→ `aspire-deployment` skill
AppHost code changes (`WithBrowserLogs()`, custom commands, `WithHttpCommand`)	→ `aspireify` skill
Deployed Azure resource health (App Insights, Front Door, NSP, private endpoint, ACA, App Service)	→ `azure-diagnostics` skill (azure-skills)
AKS workload diagnostics (pod logs, pod state, Container Insights)	→ `kubectl` + Azure Monitor Container Insights
Docker / Compose container logs	→ `docker logs` / `docker compose logs`

Project-Local Skill Routing

If .agents/skills/aspire/SKILL.md exists (from aspire agent init), see its references/monitoring.md for deeper telemetry workflow guidance.

References

diagnostics-bridge.md — Local vs deployed routing detail
monitoring.md — Telemetry inspection and export patterns
playwright-handoff.md — Find the correct Aspire frontend URL before browser testing

name: aspire-monitoring-eval
description: Evaluates the aspire-monitoring skill for correct diagnostics routing between local
  Aspire CLI and deployed platform-specific tools. Tests the bridge logic that is the skill's
  primary value.
version: "1.0"
type: capability
tags:
  skill: aspire-monitoring
defaults:
  runs: 3
  timeout: 120s
  executor: copilot-sdk
  model: gpt-5-mini
stimuli:
  - name: mon-browser-logs-001
    prompt: I want to see browser console logs and network requests from my Vite frontend in the Aspire
      Dashboard alongside the API server logs. How does that work?
    tags:
      priority: p1
      area:
        - browser-logs
        - dashboard
        - 13-3
        - routing
    environment:
      files:
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
          dest: csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/Program.cs
          dest: csharp-apphost/MyApp.AppHost/Program.cs
        - src: ../../../evals/csharp-apphost/aspire.config.json
          dest: csharp-apphost/aspire.config.json
    graders:
      - type: prompt
        name: knows_browsers_integration
        config:
          prompt: Does the assistant's response identify the `Aspire.Hosting.Browsers` integration (or
            equivalent description) as the mechanism that captures browser console logs, network
            requests, and screenshots into the dashboard, and `WithBrowserLogs()` as the opt-in call
            on a frontend resource? Answer based on intent.
      - type: prompt
        name: routes_code_change_to_aspireify
        config:
          prompt: Does the assistant's response route the actual code edit (adding `WithBrowserLogs()` to the
            AppHost) to the `aspireify` skill (or otherwise indicate that AppHost authoring is out
            of scope for this monitoring skill)? Answer based on intent — direct AppHost edits from
            the monitoring skill should be discouraged.
      - type: prompt
        name: explains_dashboard_surface
        config:
          prompt: Does the assistant's response explain that once `WithBrowserLogs()` is wired, the browser
            telemetry surfaces in the dashboard alongside server-side telemetry (and is also visible
            via `aspire otel logs <frontend>`)?
      - type: output-contains
        config:
          substring: WithBrowserLogs
  - name: mon-dashboard-run-001
    prompt: I want to view OTLP telemetry from a non-Aspire service in the Aspire Dashboard without
      booting an AppHost. How do I do that and how do I query it from the CLI?
    tags:
      priority: p1
      area:
        - dashboard
        - standalone
        - 13-3
    graders:
      - type: prompt
        name: knows_dashboard_run
        config:
          prompt: Does the assistant's response recommend `aspire dashboard run` as the way to launch the
            Aspire Dashboard standalone (without an AppHost) and capture OTLP from any source?
            Answer based on intent.
      - type: prompt
        name: warns_foreground_blocking
        config:
          prompt: Does the assistant's response warn that `aspire dashboard run` is foreground / blocking and
            must be treated as a long-running background process by agents (e.g., bash mode="async",
            capture the printed dashboard URL and token, do not wait for it to "finish")? This is
            the critical safety note. Answer based on intent.
      - type: prompt
        name: connects_cli_via_dashboard_url
        config:
          prompt: Does the assistant's response show how to connect the Aspire CLI to a standalone dashboard
            using `--dashboard-url` on `aspire otel logs` and/or `aspire otel traces`? The simplest
            form passes the full login URL printed by `aspire dashboard run` (which contains the
            `t=` token) to `--dashboard-url` — login URLs are normalized automatically. `--api-key`
            is only required when the dashboard is configured with API-key auth. Either approach is
            acceptable.
      - type: output-not-contains
        config:
          substring: issue 16236
        name: not_obsolete_workaround
      - type: output-not-contains
        config:
          substring: "#16236"
      - type: output-not-contains
        config:
          substring: may not exist in your version
      - type: output-not-contains
        config:
          substring: verify aspire dashboard command exists
      - type: output-contains
        config:
          substring: aspire dashboard run
      - type: output-contains
        config:
          substring: --dashboard-url
  - name: mon-azure-001
    prompt: My app is deployed to Azure Container Apps with Front Door in front and I'm seeing 500
      errors. Help me debug.
    tags:
      priority: p0
      area:
        - routing
        - deployed
    environment:
      files:
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
          dest: csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/Program.cs
          dest: csharp-apphost/MyApp.AppHost/Program.cs
        - src: ../../../evals/csharp-apphost/aspire.config.json
          dest: csharp-apphost/aspire.config.json
    graders:
      - type: prompt
        name: routes_to_azure_diagnostics
        config:
          prompt: Does the assistant's response route the user to azure-diagnostics, App Insights, or
            platform-specific Azure monitoring tools for the deployed app? It should cover both the
            workload (Container Apps logs) and Azure resource health in front of it (Front Door, App
            Insights, NSP, private endpoint) where relevant. Answer based on the intent, not exact
            string matching.
      - type: output-not-contains
        config:
          substring: aspire logs
        name: no_local_commands
      - type: output-not-contains
        config:
          substring: aspire describe
      - type: prompt
        name: explains_why
        config:
          prompt: The assistant's response should explain that the Aspire CLI uses a local backchannel and
            cannot reach deployed apps directly, then route to azure-diagnostics or App Insights. It
            may mention `aspire otel logs --dashboard-url --api-key` as the only remote-capable
            Aspire CLI surface (and only when a Dashboard is reachable).
      - type: output-contains
        config:
          substring: azure-diagnostics
      - type: output-not-contains
        config:
          substring: aspire logs
      - type: output-not-contains
        config:
          substring: aspire describe
  - name: mon-docker-001
    prompt: Check the logs for my service running in Docker Compose
    tags:
      priority: p1
      area:
        - routing
        - deployed
    environment:
      files:
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
          dest: csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/Program.cs
          dest: csharp-apphost/MyApp.AppHost/Program.cs
        - src: ../../../evals/csharp-apphost/aspire.config.json
          dest: csharp-apphost/aspire.config.json
    graders:
      - type: prompt
        name: uses_docker
        config:
          prompt: Does the assistant's response recommend using Docker CLI commands (docker logs, docker
            compose logs, etc.) to check logs for a service running in Docker Compose? Answer based
            on the intent, not exact string matching.
      - type: output-not-contains
        config:
          substring: aspire logs
        name: not_aspire_cli
      - type: output-contains
        config:
          substring: docker
  - name: mon-bridge-001
    prompt: How do I check what's going on with my application?
    tags:
      priority: p0
      area: routing
    environment:
      files:
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
          dest: csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/Program.cs
          dest: csharp-apphost/MyApp.AppHost/Program.cs
        - src: ../../../evals/csharp-apphost/aspire.config.json
          dest: csharp-apphost/aspire.config.json
    graders:
      - type: prompt
        name: explains_three_way_routing
        config:
          prompt: |-
            The assistant's response should ask or determine where the app is running and route to the correct tooling. Specifically it should distinguish at least three deployed targets: (1) local dev → aspire CLI (aspire describe, aspire logs, aspire otel), (2) AKS / Kubernetes workload → kubectl + Container Insights for pod
                logs and workload state,
            (3) other Azure resource health → azure-diagnostics (App Insights,
                Front Door, NSP, private endpoint, App Service / Container Apps),
            and ideally also Docker/Compose → docker logs. AppHost code or deployment definition questions should route to aspire-deployment (and aspireify for code edits). AKS should be a distinct bucket — not collapsed into a generic "Azure" answer.
      - type: output-not-contains
        config:
          substring: aspire logs <pod>
        name: no_local_for_deployed
  - name: mon-export-001
    prompt: I need to share the diagnostic data with another team member
    tags:
      priority: p1
      area: local-diagnostics
    environment:
      files:
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
          dest: csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/Program.cs
          dest: csharp-apphost/MyApp.AppHost/Program.cs
        - src: ../../../evals/csharp-apphost/aspire.config.json
          dest: csharp-apphost/aspire.config.json
    graders:
      - type: prompt
        name: uses_export
        config:
          prompt: Does the assistant's response recommend using 'aspire export' (or an equivalent Aspire CLI
            command for creating portable diagnostics bundles) to share diagnostic data? Answer
            based on the intent, not exact string matching.
      - type: output-contains
        config:
          substring: aspire export
  - name: mon-include-hidden-001
    prompt: I expected to see a 'db-migrator' resource in `aspire ps` but it's not showing up. The
      AppHost definitely registers it. What's going on?
    tags:
      priority: p1
      area:
        - include-hidden
        - 13-3
        - debugging
    environment:
      files:
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
          dest: csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/Program.cs
          dest: csharp-apphost/MyApp.AppHost/Program.cs
        - src: ../../../evals/csharp-apphost/aspire.config.json
          dest: csharp-apphost/aspire.config.json
    graders:
      - type: prompt
        name: suggests_include_hidden
        config:
          prompt: Does the assistant's response recommend re-running `aspire ps` (and/or `aspire describe`)
            with `--include-hidden` to surface hidden-by-default resources such as proxies, helper
            containers, and migrations? Answer based on intent.
      - type: prompt
        name: explains_default_behavior
        config:
          prompt: Does the assistant's response explain that Aspire 13.3 filters hidden resources by default
            and that the filtered output is correct for normal app inspection — `--include-hidden`
            is for debugging missing resources, proxies, helper containers, or migrations?
      - type: output-not-contains
        config:
          substring: restart your app
        name: not_misleading_workaround
      - type: output-not-contains
        config:
          substring: reinstall aspire
      - type: output-not-contains
        config:
          substring: delete the modules
      - type: output-contains
        config:
          substring: --include-hidden
  - name: mon-investigate-001
    prompt: Something is wrong with my app, requests are failing
    tags:
      priority: p0
      area: workflow
    environment:
      files:
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
          dest: csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/Program.cs
          dest: csharp-apphost/MyApp.AppHost/Program.cs
        - src: ../../../evals/csharp-apphost/aspire.config.json
          dest: csharp-apphost/aspire.config.json
    graders:
      - type: prompt
        name: investigates_first
        config:
          prompt: "The assistant's response should follow an investigation workflow before suggesting code
            changes: 1. Check resource state with 'aspire describe' 2. Check structured logs with
            'aspire otel logs' 3. Check console logs with 'aspire logs' 4. Check traces with 'aspire
            otel traces' Investigation must come before any proposed code edit. Answer based on
            intent."
      - type: prompt
        name: uses_aspire_commands
        config:
          prompt: Does the assistant's response recommend using Aspire CLI diagnostic commands (such as aspire
            describe, aspire logs, aspire otel) to investigate the issue before suggesting code
            changes? Answer based on the intent, not exact string matching.
  - name: mon-logs-001
    prompt: Show me what the API service is logging
    tags:
      priority: p0
      area: local-diagnostics
    environment:
      files:
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
          dest: csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/Program.cs
          dest: csharp-apphost/MyApp.AppHost/Program.cs
        - src: ../../../evals/csharp-apphost/aspire.config.json
          dest: csharp-apphost/aspire.config.json
    graders:
      - type: prompt
        name: uses_aspire_logs
        config:
          prompt: Does the assistant's response recommend using 'aspire logs' (or an equivalent Aspire CLI log
            viewing command) to view application logs locally? Answer based on the intent, not exact
            string matching.
      - type: output-not-contains
        config:
          substring: cat
        name: not_manual_logs
      - type: output-not-contains
        config:
          substring: tail -f
      - type: output-not-contains
        config:
          substring: docker logs
      - type: output-contains
        config:
          substring: aspire logs
  - name: mon-otel-001
    prompt: I need to trace a request across my services to find the bottleneck
    tags:
      priority: p0
      area: local-diagnostics
    environment:
      files:
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
          dest: csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/Program.cs
          dest: csharp-apphost/MyApp.AppHost/Program.cs
        - src: ../../../evals/csharp-apphost/aspire.config.json
          dest: csharp-apphost/aspire.config.json
    graders:
      - type: prompt
        name: uses_otel_traces
        config:
          prompt: Does the assistant's response recommend using 'aspire otel traces' (or an equivalent Aspire
            CLI distributed tracing command) for cross-service trace analysis? Answer based on the
            intent, not exact string matching.
      - type: prompt
        name: structured_first
        config:
          prompt: The assistant's response should prefer structured telemetry (aspire otel traces) over raw
            console logs (aspire logs). It should recommend checking traces first for cross-service
            analysis, then logs for detail.
      - type: output-contains
        config:
          substring: aspire otel traces
  - name: mon-tsbug-001
    prompt: |-
      I'm running a TypeScript AppHost and when I try 'aspire otel traces' I get:
      "No such host is known" for some *.dev.localhost URL
    tags:
      priority: p1
      area:
        - known-bug
        - issue-15782
    environment:
      files:
        - src: ../../../evals/ts-apphost/apphost.ts
          dest: ts-apphost/apphost.ts
        - src: ../../../evals/ts-apphost/package.json
          dest: ts-apphost/package.json
        - src: ../../../evals/ts-apphost/aspire.config.json
          dest: ts-apphost/aspire.config.json
    graders:
      - type: prompt
        name: knows_bug
        config:
          prompt: "The assistant's response should recognize this as a known issue with TypeScript AppHosts
            (issue #15782) where *.dev.localhost URLs don't resolve. It should suggest using
            --dashboard-url with localhost:PORT as a workaround."
      - type: prompt
        name: suggests_workaround
        config:
          prompt: Does the assistant's response suggest using localhost with a specific port (e.g.
            --dashboard-url localhost:PORT) as a workaround for the DNS resolution issue? Answer
            based on the intent, not exact string matching.
  - name: should_trigger_01
    description: "Reason: aspire logs is monitoring"
    prompt: Show me the aspire logs for the API service
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: invokes_aspire_monitoring
        config:
          required:
            - aspire-monitoring
  - name: should_trigger_02
    description: "Reason: aspire otel traces is monitoring"
    prompt: Run aspire otel traces to view distributed traces
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: invokes_aspire_monitoring
        config:
          required:
            - aspire-monitoring
  - name: should_trigger_03
    description: "Reason: Resource state via aspire describe is monitoring"
    prompt: Run aspire describe to see resource state
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: invokes_aspire_monitoring
        config:
          required:
            - aspire-monitoring
  - name: should_trigger_04
    description: "Reason: Telemetry export is monitoring"
    prompt: Run aspire export to bundle telemetry
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: invokes_aspire_monitoring
        config:
          required:
            - aspire-monitoring
  - name: should_trigger_05
    description: "Reason: App Insights query routes through monitoring bridge"
    prompt: Query App Insights for my deployed Aspire app
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: invokes_aspire_monitoring
        config:
          required:
            - aspire-monitoring
  - name: should_trigger_06
    description: "Reason: OTEL spans are monitoring"
    prompt: Show me the OpenTelemetry spans with aspire otel spans
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: invokes_aspire_monitoring
        config:
          required:
            - aspire-monitoring
  - name: should_trigger_07
    description: "Reason: Deployed container app logs route through monitoring bridge"
    prompt: Tail the container app logs for my deployed Aspire service
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: invokes_aspire_monitoring
        config:
          required:
            - aspire-monitoring
  - name: should_trigger_08
    description: "Reason: aspire dashboard run is a monitoring concern"
    prompt: Run aspire dashboard run to open a standalone dashboard
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: invokes_aspire_monitoring
        config:
          required:
            - aspire-monitoring
  - name: should_trigger_09
    description: "Reason: Aspire.Hosting.Browsers / WithBrowserLogs surfaces in dashboard"
    prompt: View browser console logs in the Aspire dashboard
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: invokes_aspire_monitoring
        config:
          required:
            - aspire-monitoring
  - name: should_trigger_10
    description: "Reason: Hidden-by-default in 13.3; requires --include-hidden"
    prompt: I can't find my proxy resource in aspire ps — try --include-hidden
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: invokes_aspire_monitoring
        config:
          required:
            - aspire-monitoring
  - name: should_trigger_11
    description: "Reason: AKS pod log routing lives in monitoring"
    prompt: Tail AKS pod logs for my deployed Aspire service
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: invokes_aspire_monitoring
        config:
          required:
            - aspire-monitoring
  - name: should_not_trigger_01
    description: "Reason: Start routes to aspire-orchestration"
    prompt: Start my Aspire app
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: does_not_invoke_aspire_monitoring
        config:
          disallowed:
            - aspire-monitoring
  - name: should_not_trigger_02
    description: "Reason: Deploy routes to aspire-deployment"
    prompt: Deploy my Aspire app to Azure
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: does_not_invoke_aspire_monitoring
        config:
          disallowed:
            - aspire-monitoring
  - name: should_not_trigger_03
    description: "Reason: Resource restart routes to aspire-orchestration"
    prompt: Restart the Redis resource
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: does_not_invoke_aspire_monitoring
        config:
          disallowed:
            - aspire-monitoring
  - name: should_not_trigger_04
    description: "Reason: Adding integrations routes to aspireify"
    prompt: Add PostgreSQL to my Aspire AppHost
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: does_not_invoke_aspire_monitoring
        config:
          disallowed:
            - aspire-monitoring
  - name: should_not_trigger_05
    description: "Reason: Non-Aspire Azure work"
    prompt: Create an Azure storage account
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: does_not_invoke_aspire_monitoring
        config:
          disallowed:
            - aspire-monitoring
  - name: should_not_trigger_06
    description: "Reason: Not monitoring related"
    prompt: Write unit tests for my service
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: does_not_invoke_aspire_monitoring
        config:
          disallowed:
            - aspire-monitoring
  - name: should_not_trigger_07
    description: "Reason: aspire destroy routes to aspire-deployment"
    prompt: Tear down my Aspire deployment with aspire destroy
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: does_not_invoke_aspire_monitoring
        config:
          disallowed:
            - aspire-monitoring
  - name: should_not_trigger_08
    description: "Reason: AppHost code edits route to aspireify (monitoring only observes)"
    prompt: Add WithBrowserLogs() to my Vite app in the AppHost
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: does_not_invoke_aspire_monitoring
        config:
          disallowed:
            - aspire-monitoring

Diagnostics Bridge — Local vs Deployed

Purpose: Route diagnostics requests to the correct tool based on where the application is running.

Decision Flowchart

Is the request about AppHost code or deployment definition?
│
├── YES → Route to aspire-deployment skill (and aspireify for code edits)
│
└── NO → Is the app running locally (via aspire start)?
    │
    ├── YES → Use Aspire CLI
    │   ├── Console logs       → aspire logs <resource>
    │   ├── Structured logs    → aspire otel logs
    │   ├── Traces             → aspire otel traces
    │   ├── Spans              → aspire otel spans
    │   ├── Resource state     → aspire describe   (add --include-hidden if missing)
    │   ├── Export telemetry   → aspire export
    │   ├── Filter by trace    → aspire otel logs --trace-id <id> (verify flag)
    │   └── Standalone dash    → aspire dashboard run  (foreground/blocking)
    │
    └── NO (deployed) → Route by target
        ├── Azure Kubernetes Service (AKS)
        │   ├── Pod logs           → kubectl logs <pod>
        │   ├── Pod / workload state → kubectl describe pod <pod>, kubectl get pods
        │   ├── Cluster Azure resources → azure-diagnostics skill
        │   └── Cluster-wide telemetry → Azure Monitor Container Insights
        │
        ├── Other Azure (App Service, Container Apps) → azure-diagnostics skill
        │   ├── App logs           → az containerapp logs show / az webapp log tail
        │   ├── Metrics            → az monitor metrics list
        │   ├── App Insights       → az monitor app-insights query
        │   ├── Resource health    → az resource show / AppLens
        │   └── Front Door / NSP / private endpoint → azure-diagnostics
        │
        └── Docker / Compose → Use Docker tooling
            ├── Container logs     → docker logs <container>
            ├── Service logs       → docker compose logs <service>
            └── Resource state     → docker ps / docker compose ps

---

Local Development — Full Aspire CLI Support

When the app is running locally via aspire start, the Aspire CLI provides complete observability:

How It Works

The Aspire CLI communicates with the running AppHost through a backchannel socket at ~/.aspire/backchannels/. This is a local-only IPC mechanism — it cannot connect to remote instances.

Available Commands

Command	Purpose	Example
`aspire logs <resource>`	Console stdout/stderr from a resource	`aspire logs apiservice`
`aspire logs --follow`	Stream logs in real-time	`aspire logs apiservice --follow`
`aspire otel logs`	Structured OpenTelemetry log records	`aspire otel logs`
`aspire otel traces`	Distributed trace data	`aspire otel traces`
`aspire otel spans`	Individual span-level detail	`aspire otel spans`
`aspire otel logs --trace-id <id>`	Logs correlated to a specific trace (⚠️ verify flag in your version)	`aspire otel logs --trace-id abc123`
`aspire otel logs --dashboard-url`	Query a standalone or deployed dashboard	`aspire otel logs --dashboard-url "https://localhost:18888/login?t=TOKEN"`
`aspire describe`	Resource state, endpoints, health (filtered)	`aspire describe --format Json`
`aspire describe --include-hidden`	Include hidden resources (proxies, helpers, migrations)	`aspire describe --include-hidden --format Json`
`aspire ps --include-hidden --format Json`	Resource list including hidden resources	`aspire ps --include-hidden --format Json`
`aspire export`	Export portable telemetry bundle	`aspire export`
`aspire dashboard run`	Run the Aspire Dashboard standalone (foreground/blocking)	`aspire dashboard run`

Tips for Agents

# ✅ Always use --format Json for machine parsing
aspire describe --format Json

# ✅ When an expected resource is missing, retry with --include-hidden
#    Hidden-by-default resources (proxies, helper containers, migrations)
aspire ps --include-hidden --format Json

# ✅ Get endpoints from describe, not guessing ports
ENDPOINT=$(aspire describe apiservice --format Json | jq -r '.endpoints[0].url')

# ✅ Correlate logs to a specific request
aspire otel logs --trace-id <trace-id-from-otel-traces>

---

Standalone Dashboard — `aspire dashboard run`

aspire dashboard run runs the Aspire Dashboard without an AppHost — point any OTLP-emitting application at it (Aspire or not) and telemetry shows up live.

aspire dashboard run
# Dashboard:  http://localhost:18888/login?t=<TOKEN>
# OTLP/gRPC:  http://localhost:4317
# OTLP/HTTP:  http://localhost:4318

⚠️ Foreground / blocking. This command does not return until you stop it (Ctrl-C). Agents must start it as a long-running background process (e.g., bash mode="async"), capture the dashboard URL and t= token from initial output, and leave it running. Do not treat it as a one-shot synchronous command.

Connect the CLI to a standalone dashboard

The aspire otel logs and aspire otel traces commands accept --dashboard-url (and --api-key when the dashboard is configured with API-key auth) so the CLI can query a standalone dashboard without an AppHost.

The simplest form passes the full login URL printed by aspire dashboard run — the CLI normalizes login URLs automatically:

# Stream structured logs (login URL form — token in URL)
aspire otel logs --dashboard-url "http://localhost:18888/login?t=TOKEN" --follow

# Search recent traces
aspire otel traces --dashboard-url "http://localhost:18888/login?t=TOKEN"

For dashboards that use a separate API key (e.g., the standalone container image with API-key auth configured), pass --api-key alongside the base URL:

aspire otel logs --dashboard-url https://my-dashboard.example.com --api-key "$DASHBOARD_API_KEY" --follow

The container-image standalone dashboard is still available where the CLI isn't an option.

---

Browser Telemetry (`Aspire.Hosting.Browsers`)

The Aspire.Hosting.Browsers integration captures browser console logs, network requests, and screenshots from frontend resources during local development. Frontend resources opt in by calling WithBrowserLogs() in the AppHost. The data shows up in the dashboard alongside server-side telemetry.

Need	Action
Inspect existing browser telemetry	Open the dashboard or run `aspire otel logs <frontend-resource>`
Check whether a frontend has it enabled	Look for `.WithBrowserLogs()` in the AppHost
Add `WithBrowserLogs()` to a resource	→ `aspireify` skill (AppHost authoring)

---

Deployed Applications — Routing

Why Aspire CLI Cannot Help Directly

The Aspire CLI's aspire logs, aspire describe, and other backchannel commands use the local backchannel socket at ~/.aspire/backchannels/. This is by design — there is no remote backchannel. When an app is deployed, the Aspire CLI cannot reach it directly.

Exception: if a Dashboard is reachable (deployed alongside the app, or running standalone), aspire otel logs --dashboard-url and aspire otel traces --dashboard-url (with --api-key when the dashboard requires it) can query it remotely. This does not extend to aspire logs or aspire describe.

# Limited remote support via deployed Dashboard — login URL form
aspire otel logs --dashboard-url "https://my-dashboard.azurecontainerapps.io/login?t=TOKEN"
aspire otel traces --dashboard-url "https://my-dashboard.azurecontainerapps.io/login?t=TOKEN"

# Or with separate API-key auth
aspire otel logs --dashboard-url https://my-dashboard.azurecontainerapps.io --api-key "$DASHBOARD_API_KEY"

Three-way deployed routing

Target	Use	Examples
AKS workload (pod logs, pod state, container insights)	`kubectl` + Azure Monitor Container Insights	`kubectl logs <pod>`, `kubectl describe pod <pod>`, Container Insights queries
Azure resource health (App Insights, Front Door, NSP, private endpoint, ACA, App Service)	`azure-diagnostics` skill (azure-skills)	`az containerapp logs show`, `az monitor app-insights query`, AppLens
Docker / Compose	Docker CLI	`docker logs <container>`, `docker compose logs <service>`

azure-diagnostics — quick reference

Need	azure-diagnostics Approach
Application logs	`az containerapp logs show --name APP -g RG --follow`
Metrics	`az monitor metrics list --resource RESOURCE_ID`
App Insights queries	`az monitor app-insights query --analytics-query "KQL"`
Resource health	AppLens MCP tool or `az resource show`
Activity log	`az monitor activity-log list -g RG`
Front Door / NSP / private endpoint	`az network front-door`, `az network perimeter`, AppLens

Production Telemetry — Automatic Configuration

Aspire auto-configures Application Insights when AddAzureApplicationInsights() is used in the AppHost. Deployed apps export OpenTelemetry data to App Insights automatically, providing:

Request traces and dependency tracking
Exception logging
Performance metrics
Live Metrics stream
Application Map (service topology)

No additional configuration is needed — Aspire wires the connection string during deployment.

Known Diagnostics Issues

Issue	Symptom	Workaround
TS AppHost DNS failure (#15782)	`aspire otel` returns "No such host" for `*.dev.localhost`	Use `--dashboard-url localhost:PORT` directly
`--isolated` mode telemetry (#16107)	OTEL port not randomized in isolated mode	Avoid `--isolated` if telemetry is needed
Resource missing from `aspire ps` / `aspire describe`	Hidden-by-default resources such as proxies, helpers, or migrations	Re-run with `--include-hidden`

Resolved in 13.3: The standalone-dashboard workaround for #16236 is obsolete — aspire dashboard run ships in-box (see Standalone Dashboard section above).

---

Summary: Where to Look

Question	Local Dev	Deployed
"What's the status of my resources?"	`aspire describe` (try `--include-hidden` if missing)	Azure Portal / `az containerapp show` / `kubectl describe pod`
"Show me the logs"	`aspire logs <resource>`	`az containerapp logs show` / `kubectl logs <pod>` / `docker logs`
"Show me distributed traces"	`aspire otel traces`	App Insights → Transaction Search
"Why is this resource unhealthy?"	`aspire describe` + `aspire logs`	AppLens / azure-diagnostics / `kubectl describe pod`
"What metrics are available?"	Aspire Dashboard (auto-launched or `aspire dashboard run`)	Azure Monitor / App Insights / Container Insights
"Export telemetry for analysis"	`aspire export`	App Insights export / KQL query
"Browser console / network logs"	Dashboard (with `WithBrowserLogs()` enabled) — N/A in production

Monitoring

Use this when the task is about inspecting app state, logs, traces, endpoints, or sharable diagnostics.

Scenario: I Need To Know What Is Running And Where The Endpoints Are

Use these commands when the first job is to inspect current resource state, find URLs, or hand machine-readable app state to another tool.

aspire describe
aspire resources
aspire describe --apphost <path>
aspire describe --apphost <path> --format Json

Keep these points in mind:

Use aspire describe first when you need the current state of the running app before deciding what to do next.
Use --apphost <path> when the workspace has multiple AppHosts or discovery is ambiguous.
Prefer --format Json when another tool or script needs to consume the result, such as a Playwright handoff or endpoint extraction.

Scenario: Something Is Wrong, But Investigate Before Editing Code

Use these commands when the task is to diagnose behavior in the live app before making code changes.

aspire otel logs [resource] --format Json
aspire otel traces [resource] --format Json
aspire otel spans [resource] --format Json
aspire otel logs --trace-id <id> --format Json
aspire otel logs [resource] --search "connection timeout"
aspire otel traces [resource] --search "/api/products"
aspire otel logs [resource] --search "severity:error"
aspire otel spans [resource] --search "@http.method:GET duration:>100"
aspire logs [resource]
aspire logs [resource] --search "error"

Keep these points in mind:

Prefer structured telemetry before raw console logs when possible.
Use aspire logs as a secondary console-output view after checking structured telemetry.
Use the trace-filtered log command when you already have a trace id and want the related log slice.
Use --search to filter results by a case-insensitive text match across all fields (messages, attribute keys/values, trace/span IDs, resource names, severity, scope names). This is the fastest way to narrow output when you know what you're looking for.
Prefer --format Json when another tool or script needs to consume the result, such as a Playwright handoff or endpoint extraction.
[resource] is optional. Include it to filter results to a single resource; omit it to see all resources.
--search can be combined with other options like --format Json, --trace-id, --limit, and resource filtering.

Filtering

The --search option filters output by matching text against log content and trace/span content.

Multiple words are AND'd — all fragments must match.
Use "quoted phrases" for multi-word fragments: --search "\"connection timeout\"".
Qualifiers support quoted values: --search "message:\"connection failed\"".

Console Logs (`aspire logs --search`)

Matches against log line text content and resource name. Only free-text is supported (no structured qualifiers).

aspire logs redis --search "timeout"
aspire logs --follow --search "\"connection error\""

Structured Telemetry (`aspire otel logs/traces/spans --search`)

Supports free-text and structured qualifiers in a single query.

Free-text matches against message, resource name, scope, trace/span IDs, severity/status, and all attribute keys/values.

Structured qualifiers filter on specific fields with key:value syntax:

Log keys: severity, resource, scope, message, trace-id, span-id, event
Span/Trace keys: name, resource, scope, status, kind, trace-id, span-id, duration
Custom attributes: @http.method:GET, @db.system:redis
Negation: -severity:debug, -@db.system:redis
Comparison: duration:>100, duration:>=50

aspire otel logs --search "severity:error \"connection failed\""
aspire otel spans --search "@http.method:GET duration:>100 status:error"
aspire otel logs --search "resource:api -severity:debug"

Scenario: I Need A Sharable Diagnostics Bundle

Use this command when you need a portable handoff artifact for deeper analysis or for another person to inspect offline.

aspire export [resource]

Keep these points in mind:

Use aspire export when you need a sharable bundle of telemetry and resource state.
[resource] is optional. Include it to filter the export to a single resource; omit it to export all resources.
The output is a zip archive (default name aspire-export-<timestamp>.zip) containing up to four directories:
resources/ — one JSON file per resource with resource details (name, type, state, endpoints, environment variables, etc.).
consolelogs/ — one plain-text file per resource with raw console output lines.
structuredlogs/ — one JSON file per resource with structured log entries in OTLP format.
traces/ — one JSON file per resource with distributed traces and spans in OTLP format.
When extracting the export for analysis, look at resources/ first for an overview, then drill into consolelogs/, structuredlogs/ and traces/ for detailed diagnostics.

Dashboard Links

Commands like aspire describe, aspire otel logs, aspire otel traces, and aspire otel spans may include dashboard URLs in their JSON output. Only use URLs that are explicitly returned by these commands — do not construct dashboard URLs yourself.

When a dashboard link is returned alongside a resource or telemetry entry, make the resource name, trace ID, or span ID a clickable markdown link using the returned URL.

Displaying Resources

When showing resource state to the user, display the state text with a circle emoji prefix:

🟢 Running, healthy
🟡 Starting, waiting
🔴 Failed, error, unhealthy
⚪ Stopped, exited

Link resource names to their dashboard page when the dashboard URL is known.

Displaying Telemetry

When showing structured logs, prefix each entry with an emoji matching the log level:

🔴 Error / Critical
🟡 Warning
🔵 Information
⚪ Debug / Trace

Link resource names to their dashboard resource page. When trace IDs are present, display the first 7 characters and link that value to the full trace detail page.

When showing traces or spans, use 🟢 for success/unset status and 🔴 for error status. Display only the first 7 characters of trace and span IDs, and link those values to their dashboard detail pages.

Production Monitoring Strategy (Azure)

Aspire auto-configures Application Insights when AddAzureApplicationInsights() is used in the AppHost. Deployed Azure apps export OpenTelemetry to App Insights automatically:

Request traces and dependency tracking
Exception logging
Performance metrics
Live Metrics stream
Application Map (service topology)

No additional configuration is needed for Azure once the AppHost and deployment target wire the connection strings during deployment.

Docker Compose / Kubernetes: Auto-configured App Insights does not apply. These targets require platform-native observability (Prometheus, Grafana, ELK, etc.) unless the app is explicitly configured to export OTEL to an external collector.

Deployed App Monitoring — Route by Target

Target	Tool	Commands
Azure Container Apps / App Service	azure-diagnostics	`az containerapp logs show`, `az webapp log tail`, App Insights
Azure resource health (Front Door, NSP, private endpoint, App Insights)	azure-diagnostics	AppLens, `az monitor app-insights query`
AKS workload (pods, workloads)	kubectl + Container Insights	`kubectl logs <pod>`, `kubectl describe pod <pod>`, Azure Monitor Container Insights
Docker / Compose	Docker CLI	`docker logs <container>`, `docker compose logs <service>`

Standalone Dashboard (`aspire dashboard run`)

aspire dashboard run launches the Aspire Dashboard without an AppHost, so any OTLP-emitting application can stream telemetry into it.

aspire dashboard run
# Dashboard:  http://localhost:18888/login?t=<TOKEN>
# OTLP/gRPC:  http://localhost:4317
# OTLP/HTTP:  http://localhost:4318

Foreground / blocking. aspire dashboard run does not return until stopped. Agents must treat it as a long-running background process, capture the dashboard URL and token from initial output, and leave it running. Do not invoke it as a one-shot synchronous command, and do not wait for it to "finish".

Connect the Aspire CLI to a standalone dashboard

aspire otel logs and aspire otel traces accept --dashboard-url. The simplest form passes the full login URL printed by aspire dashboard run; the CLI normalizes it automatically:

aspire otel logs --dashboard-url "http://localhost:18888/login?t=TOKEN" --follow
aspire otel traces --dashboard-url "http://localhost:18888/login?t=TOKEN"

For dashboards configured with API-key authentication, pass --api-key alongside the base --dashboard-url:

aspire otel logs --dashboard-url https://my-dashboard.example.com --api-key "$DASHBOARD_API_KEY" --follow

Browser Telemetry

Frontend resources opted into Aspire.Hosting.Browsers via WithBrowserLogs() surface browser console logs, network requests, and screenshots in the dashboard alongside server-side telemetry.

Need	Action
Inspect browser telemetry that is already wired	Open the dashboard; browser logs / network / screenshots appear next to server telemetry for the resource
Confirm a frontend has it enabled	Check the AppHost for `.WithBrowserLogs()` on the resource
Add `WithBrowserLogs()` to a resource	Route to `aspireify`; this is AppHost authoring, not monitoring

Why Aspire CLI Can't Do Remote Diagnostics

The Aspire CLI talks to a running AppHost through a local backchannel socket at ~/.aspire/backchannels/. This is by design — there is no remote backchannel. For deployed apps, route to platform-specific tools such as azure-diagnostics, kubectl, or Docker.

Exception: if a Dashboard is reachable (deployed alongside the app, or running standalone), aspire otel logs and aspire otel traces can query it via --dashboard-url and optional --api-key. This does not apply to aspire logs or aspire describe.

Playwright Handoff

Use this when Playwright CLI is already configured and the next step is browser testing against a running Aspire app.

Scenario: I Need The Right Frontend URL Before Browser Testing

Use these commands when the task is to discover the live frontend endpoint from Aspire state and then hand that URL to Playwright.

aspire describe --format Json
aspire describe --apphost <path> --format Json
playwright-cli --help

Keep these points in mind:

Aspire discovers the endpoint first; Playwright uses the discovered endpoint after the handoff.
Prefer aspire describe --format Json when the URL needs to be consumed by a script or passed to another tool.
Use --apphost <path> when multiple AppHosts exist and the user is asking about one specific app.
Do not guess frontend endpoints without first consulting Aspire state.
If multiple frontends exist, use Aspire state to disambiguate which URL Playwright should use.

Related skills

Azure DeploySafely execute production deployments of already-prepared applications to Microsoft Azure.478k1.3k

Azure ValidateRun deep pre-deployment checks on Azure configuration, infrastructure definitions, RBAC roles, and managed identities before pushing to production.477k1.3k

Github Actions DocsGet precise, docs-grounded answers about GitHub Actions workflows, syntax, security, and migration instead of relying on stale knowledge.275k72

Setup Pre CommitAutomatically run Prettier, type checking, and tests on every commit via Husky and lint-staged.161k188k

Deploy To VercelSafely turn any local project into a live Vercel preview with one instruction.97.8k29.5k

Vercel Cli With TokensDeploy projects to Vercel from agents and scripts using token authentication instead of interactive browser login.73.4k29.5k

FAQ

What does aspire-monitoring produce?

Telemetry from Aspire CLI commands, resource state via describe, and routed diagnostics for deployed AKS, Azure, or Docker workloads.

When should I use aspire-monitoring?

When inspecting logs, traces, metrics, or dashboard telemetry for a locally running or deployed Aspire application.

Is aspire-monitoring safe to install?

Review the Security Audits panel on this page before installing in production.

DevOps & CI/CDmonitoring

About

Aspire Monitoring by the numbers

aspire-monitoring capabilities & compatibility

Add your badge

How do I inspect Aspire app logs, traces, and resource health locally or on deployed Azure and AKS platforms?

Who is it for?

When should I use this skill?

What you get

Files

Aspire Monitoring

Diagnostics Bridge — Where To Look

Investigation Workflow

Local Commands Reference

Hidden resources are filtered by default

Tips for Agents

Known Diagnostics Issues

Standalone Dashboard (aspire dashboard run)

Connect the Aspire CLI to a standalone dashboard

Browser Telemetry (Aspire.Hosting.Browsers)

Dashboard UX Features

Why Aspire CLI Can't Do Remote Diagnostics

Handoff Rules

Project-Local Skill Routing

References

Diagnostics Bridge — Local vs Deployed

Decision Flowchart

Local Development — Full Aspire CLI Support

How It Works

Available Commands

Tips for Agents

Standalone Dashboard — aspire dashboard run

Connect the CLI to a standalone dashboard

Browser Telemetry (Aspire.Hosting.Browsers)

Deployed Applications — Routing

Why Aspire CLI Cannot Help Directly

Three-way deployed routing

azure-diagnostics — quick reference

Production Telemetry — Automatic Configuration

Known Diagnostics Issues

Summary: Where to Look

Monitoring

Scenario: I Need To Know What Is Running And Where The Endpoints Are

Scenario: Something Is Wrong, But Investigate Before Editing Code

Filtering

Console Logs (aspire logs --search)

Structured Telemetry (aspire otel logs/traces/spans --search)

Scenario: I Need A Sharable Diagnostics Bundle

Dashboard Links

Displaying Resources

Displaying Telemetry

Production Monitoring Strategy (Azure)

Deployed App Monitoring — Route by Target

Standalone Dashboard (aspire dashboard run)

Connect the Aspire CLI to a standalone dashboard

Browser Telemetry

Why Aspire CLI Can't Do Remote Diagnostics

Playwright Handoff

Scenario: I Need The Right Frontend URL Before Browser Testing

Related skills

FAQ

What does aspire-monitoring produce?

When should I use aspire-monitoring?

Is aspire-monitoring safe to install?

This week in AI coding

Standalone Dashboard (`aspire dashboard run`)

Browser Telemetry (`Aspire.Hosting.Browsers`)

Standalone Dashboard — `aspire dashboard run`

Browser Telemetry (`Aspire.Hosting.Browsers`)

Console Logs (`aspire logs --search`)

Structured Telemetry (`aspire otel logs/traces/spans --search`)

Standalone Dashboard (`aspire dashboard run`)