Stop Flying Blind in Production: Add a Live Observability Dashboard to Your ASP.NET Core App in 5 Minutes

Mahmood Al Sarraj — Wed, 27 May 2026 21:59:23 +0000

No Grafana. No Datadog. No YAML. Just visibility.

You've shipped your ASP.NET Core API. It's live. And then your product manager pings you: "Something seems slow — can you check?"

You open the logs. Wall of text. No correlation IDs. No timing. No idea which request threw that exception at 2 AM.

Sound familiar?

That's the problem AsGuard solves.

What Is AsGuard?

AsGuard is a lightweight NuGet package that plugs directly into your ASP.NET Core middleware pipeline and gives you:

Full HTTP request/response logging with timing, method, status, and body capture
Exception tracking with stack traces, severity, and trends — no Sentry account required
Host ILogger capture — your existing LogWarning and LogError calls get stored and searchable
A built-in live dashboard with dark/light mode, SSE-powered real-time updates, and filtering
APM trace timelines — auto-tracks EF Core queries and HttpClient calls with Gantt charts
Alerting for queue pressure, exception spikes, and persistence failures
Sensitive data masking via [AsGuardMasked] attributes and configurable header redaction

The entire thing runs inside your app. No external services. No Docker compose file with six containers. No licensing tiers. Just a NuGet package and four lines of configuration.

Getting It Running (For Real, Under 5 Minutes)

Step 1 — Install the package

dotnet add package AsGuard

Step 2 — Configure in `Program.cs`

using AsGuard.Extensions;
using AsGuard.Domain.RequestLogging;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRequestLogging(options =>
{
    options.DatabaseProvider = LoggingDatabaseProvider.Sqlite;
    options.ConnectionString = "Data Source=asguard.db";

    options.DashboardRoute = "/logs";
    options.DashboardUsername = builder.Configuration["AsGuard:Username"] ?? "admin";
    options.DashboardPassword = builder.Configuration["AsGuard:Password"] ?? "change-me";

    options.EnableExceptionLogging = true;
    options.CaptureHostLogs = true;
});

var app = builder.Build();

Step 3 — Register the middleware

The placement matters. Add UseRequestLogging() after HTTPS/CORS but before auth and your endpoints:

app.UseHttpsRedirection();

app.UseRequestLogging(); // ← right here

app.UseAuthentication();
app.UseAuthorization();
app.MapControllers();

app.Run();

Step 4 — Hit the dashboard

Run your app, open a browser, and navigate to:

https://localhost:<port>/logs

Enter your credentials and you'll see a live dashboard with every request your app has handled. That's it.

The Middleware Order Actually Matters

One gotcha worth knowing upfront: where you place UseRequestLogging() in the pipeline determines what gets captured.

[HTTP Request In]
       │
       ▼
┌──────────────────────┐
│ Exception Handler    │  ← register first so AsGuard can intercept exceptions
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│ HTTPS / CORS / HSTS  │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│  UseRequestLogging() │  ← HERE: correlation IDs generated, body stream opened
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│  Auth & Authorization│  ← 401s and 403s will still be logged
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│  Your Endpoints      │
└──────────────────────┘

Placing it after auth means you lose logs for unauthorized requests. Placing it before exception handlers means unhandled exceptions won't have their HTTP context correctly linked. The order shown above gets you everything.

Choosing a Database

AsGuard supports four providers out of the box:

SQLite — zero setup, file-based; perfect for local dev, small apps, and quick demos
SQL Server — the natural fit for production on Azure or Windows-hosted workloads
PostgreSQL — ideal for Linux environments and cloud-native stacks
In-Memory — no persistence, no config; great for integration tests and ephemeral environments

Switching is one line:

// PostgreSQL
options.DatabaseProvider = LoggingDatabaseProvider.PostgreSql;
options.ConnectionString = "Host=localhost;Database=asguard;Username=postgres;Password=pass";

// In-Memory (no persistence, great for tests)
options.DatabaseProvider = LoggingDatabaseProvider.InMemory;
options.MaxInMemoryEntries = 10000;

No migrations to run manually. AsGuard auto-creates its tables on startup.

Masking Sensitive Data

If you capture request bodies (and you should, for debugging), you don't want passwords or card numbers showing up in your log viewer. AsGuard gives you two ways to handle this.

Per-property attribute:

public class LoginRequest
{
    public string Username { get; set; }

    [AsGuardMasked]
    public string Password { get; set; } // stored as "[REDACTED]"
}

Global key list in config:

options.SensitiveBodyKeys.Add("creditCardNumber");
options.SensitiveBodyKeys.Add("ssn");
options.SensitiveBodyKeys.Add("token");

This runs at the middleware level before anything hits the database — you're never storing what you shouldn't.

What You'll Actually Use It For

Debugging slow requests in development

The request log view shows method, path, status code, and duration for every call. You can filter by status, search by path, and click into any row to see the full request/response bodies, headers, and the correlation ID chain.

Tracking down production exceptions

Exception logging captures the full stack trace, the HTTP context it occurred in, the severity, and when it happened. The dashboard includes trend charts so you can see if your error rate just spiked after a deploy.

Capturing `ILogger` output

With CaptureHostLogs = true, any LogWarning or LogError your existing services emit gets stored alongside the HTTP logs. You don't need to change a single line of your existing logging code — AsGuard just intercepts the host ILogger pipeline.

APM for EF Core and HttpClient

AsGuard auto-instruments EF Core queries and outbound HttpClient calls, showing them as Gantt-style trace timelines per request. If one endpoint is slow because it's firing 12 database queries, you'll see exactly which ones and how long each took.

Seeing what's live, right now

The dashboard uses Server-Sent Events for real-time updates — no page refresh, no polling interval to configure. While you're load testing or manually poking an endpoint, the request log updates in front of you.

Production Notes

A few things to know before deploying:

Change the default credentials. AsGuard actively rejects the literal string "admin" as a username. Store credentials in environment variables or user secrets:

# environment variable approach
ASGUARD__USERNAME=your_secure_user
ASGUARD__PASSWORD=your_secure_password

The write path is non-blocking. AsGuard uses a queue-based architecture — logs are written to an in-process channel and flushed asynchronously. Your API response times are not affected by database write latency.

Set up retention policies. For high-traffic apps, configure auto-cleanup so the log table doesn't grow unbounded:

options.RetentionDays = 30;

SQLite is fine for low-to-medium traffic. For anything handling hundreds of requests per second in production, switch to PostgreSQL or SQL Server.

The Bigger Picture

Most .NET teams reach for Sentry for exceptions, Datadog or Azure Monitor for metrics, and a custom Kibana setup for logs. That's three services, three SDKs, three dashboards, and three monthly bills.

AsGuard doesn't replace that stack for large-scale production systems. But for the majority of apps — internal tools, SaaS products under 100k requests/day, staging environments, side projects — it gives you 80% of the observability value at 0% of the infrastructure overhead.

Install it in your existing app today and you'll have a searchable, live view of every request and exception by the time your coffee's ready.

GitHub: mahmood-alsarraj/asguard

NuGet: dotnet add package AsGuard

If this saved you a debugging session, give the repo a star — it helps.

ASP.NET Core Request & Exception Logging with a Built-In Dashboard

Mahmood Al Sarraj — Fri, 22 May 2026 18:39:32 +0000

Most ASP.NET Core logging setups tell you that something failed — but not what actually happened during the request lifecycle.

I built AsGuard to provide lightweight request + exception logging with a built-in dashboard and minimal setup.

GitHub Repository:
https://github.com/mahmood-alsarraj/asguard

Why AsGuard?

centralized request + exception visibility
built-in dashboard
minimal setup
easier inspection during debugging
lightweight integration

Feature	Description
🚀 Queue-based persistence	Non-blocking async writes - your API never waits for database
📊 Built-in dashboard	Beautiful Razor UI with dark/light mode and live updates
🔒 Sensitive data masking	`[AsGuardMasked]` attribute + configurable header redaction
📝 Body capture	Request/response bodies with content-type allowlist
🔗 Correlation IDs	Distributed tracing with configurable headers (default: `X-Correlation-ID`)
⚡ Live SSE updates	Real-time push notifications without SignalR
🗄️ Multiple databases	SQL Server, PostgreSQL, SQLite, or In-Memory
📈 Exception analytics	Trends, severity summaries, and configurable alerts
🎯 Host ILogger capture	Automatically captures `ILogger<T>` warnings/errors
🔔 Alerting system	Queue pressure, exception spikes, persistence failures
📡 REST API	Full programmatic access to logs and stats
🧹 Retention policies	Auto-cleanup with configurable intervals

Quick Setup

dotnet add package AsGuard
builder.Services.AddRequestLogging(options =>
{
    options.DatabaseProvider = LoggingDatabaseProvider.Sqlite;
    options.ConnectionString = "Data Source=AsGuard.db";
    options.DashboardRoute = "/request-logs-ui";
    options.DashboardUsername = "admin";
    options.DashboardPassword = "admin123";
    options.EnableExceptionLogging = true;
    options.LogRequestBody = true;
    options.LogResponseBody = true;    
});

var app = builder.Build();

app.UseExceptionHandler("/error");
// After the exception handler
app.UseRequestLogging();

Navigate to "/request-logs-ui", enter your credentials, and watch your application’s heartbeat in real-time.

Final Thoughts

Modern applications need visibility.

Sometimes you don’t need a massive observability platform — you just need a fast and practical way to inspect requests and exceptions.

That’s the problem AsGuard aims to solve for ASP.NET Core developers.

Resources:

📦 NuGet
📚 Documentation
🐛 Issues

⭐ Star the repo if AsGuard helps you!

DEV Community: Mahmood Al Sarraj