Aspire dashboard now persists telemetry across restarts

Aspire 13.6 moves dashboard telemetry from memory into SQLite, so logs, traces and metrics survive restarts. A run selector lets you revisit earlier runs of the same app. Default telemetry limits rise to 100,000 entries, and memory use drops in the team's benchmark.

Key points

• With Aspire 13.6, an AppHost-launched dashboard creates a separate SQLite database for each run.
• Use the header run selector to revisit earlier runs for logs, traces, metrics and resource state.
• Default limits for console logs, structured logs and traces rose from 10,000 to 100,000 entries.
• Standalone dashboards accept --persistence set to None, Run or Resume; the default is None.
• Persisted data lives under the user's .aspire directory by default; ASPIRE_HOME changes the base location.
• In a container, mount a persistent volume, or the stored data disappears with the container.

Until now the Aspire dashboard kept telemetry only in memory, so restarting the app erased logs, traces and metrics. Aspire 13.6 adds persistence: each dashboard launch creates a run with its own SQLite database. A header run selector lets you reopen an earlier run and use the same views. It is on by default when an AppHost starts the dashboard.

Storage moved to SQLite, an embedded database that runs inside the dashboard process, so no separate server is needed. Default limits for console logs, structured logs and traces rose from 10,000 to 100,000 entries, and a benchmark showed private memory falling from 1,007 MB to 241 MB. Standalone dashboards still default to no persistence, so choose Run or Resume, and mount a volume in containers.

Real-world use

• Your AppHost failed on startup; after fixing configuration and restarting, open the earlier run to study the original error.
• You monitor a non-.NET service with the standalone dashboard container and want its history kept across restarts by mounting a volume.
• A microservices solution produces heavy log and trace volume locally, so you need longer history without the dashboard eating RAM.

Why it matters

Restarting the app no longer wipes the evidence you need to debug it, and you can reopen earlier runs straight from the dashboard. The lower memory footprint also matters on busy dev machines running an IDE, builds and containers alongside it.

Related stories

• Collection Return Types in C#: Interfaces, Views, and SnapshotsDLNick Cosentino (Dev Leader)2 d ago
• CritterWatch 1.1 groups dead letters by failure cause and acts on each group at onceJXJasperFx (Critter Stack) Blog4 d ago
• Dapper FluentMap Is Back: What Changed from 2.0 to 3.6DVDEV Community: #dotnet5 d ago