-
Notifications
You must be signed in to change notification settings - Fork 16
DashboardUi
The Dashboard UI is a Blazor Server app for monitoring and managing queues. It talks to the Dashboard API over HTTP.
- Connection and queue overview with message counts by status
- Feature indicators per queue (Status, HeartBeat, Priority, Delayed, Expiration, Routing)
- Paginated message listing with status filtering
- Message detail drawer with body, headers, retry history, and error stack traces
- Edit message bodies
- Requeue individual or all error messages
- Reset individual or all stale messages
- Delete messages and bulk-delete errors
- Active consumer tracking with machine name, PID, and uptime
- Consumer count badges on queue cards
- Scheduled job listing
- Queue configuration display
- Maintenance status display (when host maintenance is enabled)
- Configurable auto-refresh (default 10 seconds)
- Optional login with cookie-based authentication
- Dark theme via MudBlazor
- Message history tab with status filtering, duration display, expandable exceptions, pagination, and purge
- Per-message cancellation button for messages in Processing status (requires in-process consumer)
- Multi-source support: connect to multiple Dashboard API instances from one UI
- Per-source health monitoring with background polling
- Collapsible source panels on the home page with health indicators
- Partial failure resilience: offline sources show warnings without blocking healthy ones
Home page — one row per Dashboard API source, connection/queue counts at a glance:

Queue detail with the History tab — status counts, feature indicators, and a paginated message history with expandable exception rows for error entries:

Message detail drawer showing the deserialized POCO body plus headers and action buttons (delete, reset, cancel):

Install-Package DotNetWorkQueue.Dashboard.Ui
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorComponents()
.AddInteractiveServerComponents();
builder.Services.AddMudServices();
// Multi-source configuration is read from appsettings.json (see Configuration below).
// HttpClient instances are created per source automatically.
var app = builder.Build();
app.MapRazorComponents<App>()
.AddInteractiveServerRenderMode();
app.Run();Note: Use
https://in staging and production so that the API key and session cookies are encrypted in transit.
Configure API sources and optional authentication in appsettings.json:
{
"DashboardApi": {
"Sources": [
{
"Name": "Local",
"BaseUrl": "http://localhost:5000",
"ApiKey": ""
}
]
},
"DashboardAuth": {
"Username": "",
"PasswordHash": ""
}
}| Setting | Description |
|---|---|
DashboardApi:Sources |
Array of Dashboard API sources to connect to |
Sources[].Name |
Display name for this source (must be unique; used to derive the URL slug) |
Sources[].BaseUrl |
URL of the Dashboard API service |
Sources[].ApiKey |
API key sent as X-Api-Key header (must match the API's ApiKey setting) |
DashboardAuth:Username |
Login username (leave empty to disable login) |
DashboardAuth:PasswordHash |
SHA256 hash of the login password |
Breaking (0.9.31): The flat
DashboardApi:BaseUrl/DashboardApi:ApiKeyformat is no longer supported. See the Migration Guide for upgrade steps. Using the old format throws anInvalidOperationExceptionat startup with a migration example.
The UI can connect to multiple Dashboard API instances from a single deployment. Each entry in the Sources array gets its own API client and cached health state.
{
"DashboardApi": {
"Sources": [
{
"Name": "Production",
"BaseUrl": "https://dashboard-api.prod.example.com",
"ApiKey": "prod-key"
},
{
"Name": "Staging",
"BaseUrl": "https://dashboard-api.staging.example.com",
"ApiKey": "staging-key"
}
]
}
}Each source name is converted to a URL slug (lowercased, non-alphanumeric characters replaced with hyphens). All page URLs include a /source/{slug} prefix:
| URL | Page |
|---|---|
/ |
Home, all sources grouped in collapsible panels |
/source/production |
Home filtered to a single source |
/source/production/connections/{id} |
Connection detail |
/source/production/queues/{id} |
Queue detail |
For single-source deployments, the home page shows a flat connection list without panels.
The UI polls each source every 30 seconds (5-second timeout per source). Health state is cached and displayed on the home page:
- Healthy -- API responded successfully
- Unhealthy -- API unreachable or timed out; error message displayed
Offline sources show a warning banner without blocking healthy ones. A per-source Retry button triggers an immediate re-poll.
PowerShell:
$s = [System.Security.Cryptography.SHA256]::Create()
[BitConverter]::ToString($s.ComputeHash([Text.Encoding]::UTF8.GetBytes("yourpassword"))).Replace('-','').ToLower()Bash:
echo -n 'yourpassword' | sha256sum | cut -d' ' -f1Security warning: SHA256 is a general-purpose digest, not a password hash. It offers no resistance to brute-force attacks. This authentication is intended for internal/intranet tooling. For internet-facing deployments, prefer a proper identity solution configured via
DashboardOptions.AuthorizationPolicy. If using the built-in login, choose a long, random password (16+ characters).
When DashboardAuth:Username and DashboardAuth:PasswordHash are configured, the UI displays a login page at /login. Sessions expire after 8 hours. When both values are empty, the UI is accessible without login.
The UI is a standalone web app that talks to one or more Dashboard API services. You can host UI and API together or separately. The UI never connects to queue databases directly; everything goes through the API.
In self-contained / Docker mode, the in-process API auto-registers as a "Local" source and resolves its own listen address via IServer. You do not need to manually add a "Local" entry when the UI and API run in the same process. See Dashboard Docker Deployment for details.
For any issues please use the GitHub issues