Operators open one page and know whether the platform is healthy and what needs attention. They can fix the common, safe problems themselves: failed background jobs, tenants left behind on a schema migration, and undelivered emails.
The dashboard is the portal home page. It shows the total number of tenants (every state except Deleted), the count in each state (Active, Provisioning, Provisioning failed, Maintenance, Suspended, Pending deletion), and new sign-ups (tenants created, in any state) in the last 24 hours and 7 days.
HLT-02
Must
"Needs attention" lists, grouped by type, each item with the tenant name, subdomain, state reason, and since-when, linking to the tenant detail: tenants in Provisioning failed, tenants in Provisioning longer than the slow-provisioning threshold, tenants in Maintenance longer than the stuck-maintenance threshold, failed backups, tenants behind on schema version, failed background jobs, and services not healthy. Each type shows at most 50 items, oldest first. When nothing needs attention it says so.
HLT-03
Must
Dashboard data is no older than 1 minute: the page refreshes it automatically every 30 seconds and on demand with a Refresh button, and shows when it was last refreshed. If a refresh fails, the page says so and keeps the last data that loaded.
Services screen shows status (Healthy, Degraded, Down) and last check time for: web app, API, background worker, control-plane database, tenant database server(s), cache, object storage, and email provider.
HLT-05
Must
Each service shows the application version deployed and links to the external monitoring and log tools configured for the deployment.
Background jobs screen shows each queue with pending, running, and failed counts, and the age of the oldest pending job.
HLT-07
Must
Failed jobs list: job type, tenant, first failed time, attempts, last error. Owner or Operator can retry one job or all failed jobs of a type, or discard a job with a reason.
HLT-08
Should
An alert is sent when a queue's oldest pending job is older than its threshold (default 5 minutes).
Schema migrations screen shows the current target schema version and, for each tenant, its schema version and the result of its last migration. Default filter: tenants not on the target version.
HLT-10
Must
Owner or Operator can retry the migration for one tenant or for all tenants behind the target version. Progress is shown per tenant.
HLT-11
Must
A tenant whose migration failed stays usable on its previous version if the application supports it; otherwise it is put in Maintenance and listed under "Needs attention".
Email delivery log for platform transactional emails (welcome, invitation, password reset, maintenance notices): time, tenant, recipient, template, status (Queued, Sent, Delivered, Bounced, Failed), and provider error. Email bodies are not stored.
HLT-13
Should
Any operator can resend a failed or bounced email to the original recipient. Resending a password reset creates a new link; it never reuses the old one.
Owner can publish a platform announcement (for example a planned maintenance window) shown as a banner to all tenant users between a start and end time.
Dashboard. Heading with the last refreshed time and a Refresh button; a Total card and one card per tenant state (Provisioning failed in red when above zero); sign-up cards for the last 24 hours and 7 days; "Needs attention" list grouped by type.
System health. Header shows overall status: operational, or Degraded with the visible cause(s) (badge text and tooltip) that links or scrolls to the relevant tab or section. Auto-refresh selector (Off / 30s / 1 min) sits next to Refresh and Last refreshed. Tabs: Services, Background jobs, Schema migrations, Email delivery; tab counter badges have tooltips (failed jobs, pending migrations). Services tab: telemetry cards (Uptime label; CPU load % with core count secondary; memory bar green/amber/red with System GB and Node heap labels; status badges match the registry table), then the Service Health Registry (no Last Checked column; Latency with sparkline or "Not measured" tooltip; Logs column). Each other tab is a table as described in its requirements, with the same filter and pagination rules as the rest of the portal.
Dashboard thresholds: provisioning is slow after 10 minutes in Provisioning (ADMIN_SLOW_PROVISIONING_MINUTES), and maintenance is stuck after 60 minutes in Maintenance (ADMIN_STUCK_MAINTENANCE_MINUTES). Both are deployment settings.
Health checks run at least every 30 seconds; a service is Degraded after 2 failed checks in a row and Down after 5.
Retrying a migration for many tenants runs them in small batches so the database servers are not overloaded; a failure in one tenant does not stop the batch.
Thresholds, alert destinations, and external tool links are deployment settings.
Email recipients are shown in full only to Owner and Operator; Support sees them partly masked.
HLT-01: Given 4 active, 1 suspended, and 3 deleted tenants, the dashboard shows Total 5, Active 4, Suspended 1, and no Deleted card; a tenant created 2 hours ago counts in both sign-up figures, one created 3 days ago only in the 7-day figure.
HLT-02: Putting one tenant in Provisioning failed adds one item under "Provisioning failed" that links to /tenants/<id>; fixing it removes the item at the next refresh. A tenant in Maintenance for 59 minutes is not listed; at 61 minutes it is.
HLT-03: The page shows "Last refreshed" with a time; auto-refresh defaults to 30s (Off / 30s / 1 min); Refresh loads new data at once. Degraded status always names at least one visible cause.
HLT-02: Making one provisioning run fail adds one item to "Needs attention" that links to the run; fixing it removes the item at the next refresh.
HLT-04: Stopping the background worker shows it as Down within 3 minutes.
HLT-07: Retrying a failed job that now succeeds removes it from the failed list and records an audit entry.
HLT-09: After a new schema version is released, tenants not yet migrated appear in the default filter.
HLT-10: Retrying all tenants behind the version, with one tenant forced to fail, migrates the others and leaves only the failing tenant listed.
HLT-13: Resending a password reset email sends a new link, and the old link no longer works.
Support can view all tabs and resend emails, but sees no retry or discard actions for jobs and migrations.
HLT-02 items for failed backups, tenants behind on schema version, failed background jobs, and services not healthy: their data sources (Backup, restore, and reset, the tenant migration runner, background jobs, and health checks) do not exist yet. Provisioning items come from tenant state until provisioning runs are recorded (Provisioning monitor).
The dashboard endpoint (GET /api/admin/dashboard) is not protected yet; it must require a signed-in operator once Operator access and audit is built.
HLT-04 to HLT-14: Services, Background jobs, Schema migrations, Email delivery, and Announcements screens.