Dashboard¶

/ui/management/dashboard is Atlaso's authenticated operations command center. It is a read-only orientation surface: operators can see current health and follow links into the owning workflow, but the dashboard never applies configuration, restarts a service, or mutates appliance state.

Interface overview¶

This verified appliance view provides visual orientation before you begin.

Atlaso Dashboard page in the clean-appliance desktop viewport.

Figure: Dashboard in the verified clean-appliance desktop state.

Overall state¶

The status band reports one of three states:

Setup incomplete while management networking is not healthy or no global appliance-apply task has succeeded;
Needs attention when setup is complete and an actionable exception exists;
Healthy when setup is complete and no actionable exception exists.

The primary action follows the current state. Setup links to the first incomplete readiness item, attention links to the highest-priority exception, valid pending changes link to Appliance Apply, active work links to Tasks, and an otherwise healthy appliance links to Monitor.

When the factory comparison baseline already matches desired state but no Appliance Apply has succeeded, Continue setup opens the shared appliance-review modal with the complete validated initial desired state selected. Review the components and choose Submit appliance changes to create the first global task. Opening the review remains read-only; nothing changes on the host until that explicit submission.

Readiness and attention¶

Readiness covers management-interface discovery, management address/link health, Appliance Settings validity, whole desired-state validity, and the first successful global appliance apply. Readiness mode ends only after the management path is healthy and a global appliance-apply task has succeeded.

The Network summary selects from the last successfully applied Network baseline, so pending role, listener, address, or VLAN edits cannot replace the running management path. Only appliances without a baseline use desired state as a bootstrap fallback. Physical health also requires a matching observed address; configured CIDRs alone are insufficient. Each Dashboard refresh performs bounded, read-only native discovery. Failed discovery cannot reuse cached health and does not reconcile or change saved interface configuration. DHCP and automatic IPv6 listeners require native automatic-address evidence; leftover static addresses do not satisfy readiness.

The preferred Management UI listener is selected from that state: a dedicated Management interface takes precedence, including DHCP while waiting for its lease, followed by flagged Access physical interfaces and enabled flagged Access VLANs. Physical listeners need a usable address, admin-up desired state, and an observed active link. Link-local addresses do not satisfy readiness. A VLAN needs an available trunk parent and a bounded native check of its exact tag, parent identity, active links, and addresses; configured addresses alone never establish VLAN health. If native verification is unavailable, the VLAN link remains unknown and management readiness remains incomplete. These checks do not clear independent Appliance Settings, service, or desired-state validation failures.

Actionable exceptions use this fixed priority:

changed appliance-apply units that fail validation;
failed tasks created during the last 24 hours, except an appliance-apply failure whose unresolved units were all covered by later successful appliance applies;
enabled services that are stopped or unhealthy;
configured physical interfaces that are missing or unexpectedly down.

Valid changed units stay in the separate Changes & Tasks summary. Disabled optional services and interfaces whose desired role and mode are both unused do not create attention items. A successful apply for unrelated units does not clear an earlier failure. A resolved appliance-apply failure remains in Tasks, Audit Events, and Recent activity as history; only its actionable dashboard warning is cleared.

Private snapshot and refresh¶

The initial page and session-authenticated GET /ui/management/dashboard/data endpoint use the same snapshot builder. The private response contains generated time, overall state, readiness, attention, pending-change and task summaries, service and network summaries, and six recent activity rows. Activity rows expose only source, title, outcome, actor, time, and destination URL. Task results, command output, raw errors, audit detail, and secrets are never dashboard fields.

The browser refreshes every 30 seconds while the page is visible, pauses while hidden, and refreshes immediately after becoming visible. A failed refresh keeps the last successful DOM and displays a stale-data notice.

Each snapshot evaluates current desired-state validation and pending changes without fetching detail-page disk inventory, DHCP client leases, or vSphere provider counts. Those live details remain available in their owning pages. Validation inputs such as NTP capabilities and management DHCP DNS upstreams are still checked; Dashboard does not cache desired-state results to shorten page opening.

/api/v1/dashboard remains the existing bearer-authenticated public API and is not backed by this private UI response.