# Dashboard

> The overall dashboard — pillar rings around the human gate, service KPIs, pillar health, the gate queue, one section per pillar, the guardrails strip — and where every number comes from.

_Reference · Updated 2026-10-28 · Describes release 0.1.164_

## What the page is

![Dashboard: the pillar rings around the human gate — Incident, Compliance and Change by default — the four service KPI tiles, the Pillar health table beside the Human gate queue, and the Incident & Problem section with its pipeline strip and recent incidents.](/help/media/portal/portal-dashboard.png?v=0.1.162)

The **Dashboard** (`/portal/dashboard`, the first item in the sidebar) is the overall view of a workspace: the open work of the pillars it shows, the writes waiting for a person, and the service levels of the last 30 days. Signing in lands here once the workspace has an enabled read connection; a workspace without one is sent to the [Quick start](/portal/start) (in the product: `/portal/start`) once per browser session and then sees the same page with a **Connect your first data source** card on top, which repeats the Quick start's sentence instead of showing invented numbers.

Everything on the page is read in one request, `GET /api/aiops/{tid}/dashboard/summary`, which composes the readers the lists already use — the incident and change summaries, the saved compliance report, the spend rollup and the problem, route and knowledge rows — and is cached for a minute per workspace. Reading it needs `incidents.view`, like the lists. The **Human gate queue** card reads the **Needs you** queue the sidebar badge already polls. Nothing on the page is computed from a page of rows in the browser.

Three rules hold on every card:

- A number that is a link opens the list whose total it is, with the same filter. The count on the Dashboard and the count on that list come from the same server query.
- The page shows the pillars the workspace lists on **Guardrails → Dashboard pillars** (`dashboard_pillars` on `GET`/`PATCH /guardrails`; the platform default is **Incident & Problem**, **Compliance** and **Change Mgmt**): only their rings, **Pillar health** rows and sections render. **SecOps**, **FinOps · Optimise** and **Continuous Improve** are hidden until they are listed there; their counts stay in the summary the page reads (`shown_pillars` names the listed ones, each ring carries `shown`), and the list applies on the next read, never a minute later.
- A listed pillar the platform has switched off (the ops console's pillar switch) has no section, a dashed ring reading **off**, and a dash in **Pillar health**. A figure the rows cannot support — no resolved incident yet, no previous window — says so or is left out; it is never estimated.

The sections below follow the page from the top. Each names what it inherits from the customer's "Mission Overview" mock-up and what differs.

## The hub and the human gate

From the customer's mock-up: the hub graphic — the pillar rings orbiting the human-gate count — and the HUMAN GATE panel with its "production changes awaiting sign-off" line and **Review queue** button. The sci-fi faces and colours were not inherited; the rings use the design system's status tokens, so light, dark and the brand skin all apply. The mock-up's Compliance and Improve rings read a score; here they count open rows — the compliance score is in the ring's accessible name and in its section. The rings sit on one circle around the gate, evenly spaced from the top (three pillars: top, lower left, lower right), and the picture scales with the page, so a ring never meets another or the gate at any width. The table lists every ring the hub can show; a workspace sees the ones it lists (three by default, see above).

| Ring | Its number | Opens |
| --- | --- | --- |
| **Incident** | Unresolved incidents in the Incidents list — every pillar but compliance, since that list has no pillar switch; the sidebar's **Incidents** badge is the same number, re-read every 15 seconds — the Dashboard's figure may be up to a minute older | **Operate → Incidents**, filtered to *Unresolved (any but resolved)* |
| **Compliance** | Unresolved compliance findings, every domain (the score is in the ring's accessible name and in the section) | The compliance findings list under **Security posture**, every domain, filtered to *Unresolved (any but resolved)* |
| **Change** | Change requests waiting for approval | **Operate → Changes**, filtered to *pending approval* |
| **SecOps** | Unresolved SecOps incidents | The **SecOps** section of this page: no list holds only SecOps rows (the Incidents list has no pillar switch), so the ring opens the section, whose figures link where a list exists |
| **FinOps** | The AI agents' spend over the last 30 days | **Insights → Usage & billing**, for people with `report.view` — the ring and the FinOps section show their figures to them only; others see a dash |
| **Improve** | Open problems | **Operate → Problems**, filtered to *open* |

The centre, **Human gate**, is every write a person must release before it runs: incidents whose write action is paused for approval, in every pillar, plus change requests pending approval. The panel beside the hub shows the same total and links each half to the list with that total: the paused incidents open **Needs you** filtered to *incidents paused for approval* (`/approvals?type=incident_approval` — the Incidents list leaves compliance findings out, and a paused finding fix counts at the gate too), the pending changes open **Operate → Changes** filtered to *pending approval*. For people who may act or decide, **Review queue** opens **Needs you**. The hub itself carries no decision buttons: a decision is made next to the evidence, on the incident or the change.

The Incidents list holds every pillar but compliance, so the **Incident** ring counts the SecOps ring's rows too, whether or not SecOps is shown. There is one definition of *unresolved* on the page: a ring, its **Pillar health** row and its section headline show the same number — the total of the list the ring opens — so **Incident** reads the Incidents list's unresolved rows in all three places, **Compliance** the findings list's and **Change** the requests pending approval.

## Service KPIs

From the customer's mock-up: four tiles — MTTR, MTTA, alert noise reduced and auto-handled events — each with a sparkline and a delta against the previous period. Inherited as four tiles over a rolling 30 days against the 30 days before, with a 14-day daily sparkline whose sentence a screen reader hears.

| Tile | What it measures | When it is left out |
| --- | --- | --- |
| **MTTR** | From an incident's open to the moment its condition was verified gone, else to the resolve click — the same definition as the [Service delivery report](/help/service-delivery-report.md); service incidents only, never compliance findings or incidents closed as noise | No incident resolved in either window |
| **MTTA** | From open to the start of the first analysis run an agent made on its own (an alert, a manual start or a schedule — never a verification, a test or the agent API) | No incident analysed in either window |
| **Alert noise reduced** | The share of received alerts the platform suppressed as cascading or storm victims, in percentage points. This is not the Service delivery report's *Noise reduction*, which is the share of alerts that did not become an incident of their own (1 − incidents ÷ alerts): the report measures grouping, this tile measures suppression | No alert received in either window |
| **Auto-handled events** | Changes that completed without a click: a pre-approved runbook fix released on its own. The mock-up's tile is a share; the platform records no denominator for it, so this is a count — its own rows, so it compares only from five on each side too | Always shown once a window exists |

The delta reads "−25% vs previous 30 days" for a ratio, "+5 pp vs previous 30 days" for a share, and says "no previous 30 days to compare" or "nothing to measure in this window" rather than showing a number with no base. The direction that is good news is coloured; the text carries it too.

**MTTR**, **MTTA** and **Alert noise reduced** also say what they rest on — *over 7 resolved incidents*, *over 9 analysed incidents*, *over 412 alerts* (`samples` in the summary) — and print a delta only when both windows have at least five rows; with fewer the tile reads *too few to compare*, never a percentage from a handful of incidents. A window with no rows of its own says nothing about them, never *over 0 resolved incidents*. An MTTA under a minute reads *under a minute* with *analysis starts on open*: an alert's analysis begins the moment its incident opens, so "0s" would be true and misleading.

## Pillar health and the human gate queue

From the customer's mock-up: the "Pillar health" table (pillar · status · signal · 7-day sparkline) and the "Human gate queue" card. The table's columns are what the platform records per pillar: **Status** (enabled or disabled), **Unresolved** — the same number as the pillar's ring, the total of the list it opens (FinOps, with no list, counts its own unresolved rows) — **Pending approvals** (the incident writes paused for approval among the incidents its **Unresolved** counts — for Incident & Problem every pillar but compliance — or for Change Mgmt the requests pending approval, so the column adds up to the human gate) and **Last run** of that pillar's agent. The mock-up's per-pillar "signal" sentence and 7-day sparkline were left out: there is no per-pillar health score to draw, and a sentence per pillar would have been written by hand.

The queue lists the write actions paused for approval and the change requests pending approval, most urgent first, as **Needs you** orders them: the title, the agent's reason, the risk tier, who must release it — **one approver**, or for a high-risk (L3) change **two distinct approvers** with the quorum so far — and how long it has waited. Each row opens its record. The card says when the queue could not be loaded instead of showing an empty one, and how many more rows **Needs you** holds.

## Incident & Problem

From the customer's mock-up: open incidents, MTTA, MTTR, auto-triage coverage, the active-incidents table and the pipeline strip. Inherited, with the pipeline shown for the workspace rather than for one incident.

- **Unresolved incidents** opens the Incidents list filtered to *Unresolved (any but resolved)*; the hint says how many incidents the list holds in all. **MTTA** and **MTTR** repeat the KPI tiles' values with the rows they rest on; **Auto-triage coverage** is the share of the window's service incidents an agent analysed on its own.
- **By status** and **By severity** chips open the list with that filter; **Opened per day** and **Resolved per day** are the last 14 days.
- The pipeline strip — **Classify → Correlate → Triage → Recommend fix → Human approval → Validate → Rollback** — shows one number per stage where a list carries it: incidents opened in the last 14 days, the noise share, the auto-triage share, incidents that need attention (a fix proposed or a hand-over), incidents whose write is paused, incidents whose fix is running, and change requests rolled back. The counted stages open their lists.
- **Recent incidents** are the five newest unresolved incidents: ID, service, title, owner (or *unassigned*), status.

Problems are counted under **Continuous improvement**, where the automation candidates come from, once **Continuous Improve** is listed on **Guardrails → Dashboard pillars**; on the default three pillars the page counts no problem.

## Compliance

From the customer's mock-up: overall compliance, critical non-compliant, auto-remediation rate, active exceptions and the score by framework. Inherited with the platform's own vocabulary and two decisions from the 24 October review: the four domains **Posture**, **Vulnerabilities**, **Patching** and **Backup** are the menu (Q5), and the platform's SOC 2 / ISO 27001 mapping stays hidden (Q4'), so **Standards** lists the scanners' own standards only — Security Hub standards and Config conformance packs.

- **Overall score** is the scanners' total from the saved compliance report (every check counted once) and opens **Security posture → Audit & coverage → Scores**. The section's **Unresolved findings** link opens the findings list, every domain, filtered to *Unresolved (any but resolved)*; the **Critical findings** hint counts the unresolved findings, the Compliance ring's number.
- **Critical findings** opens the compliance findings list filtered to critical.
- **Auto-remediation share** is the share of the last 30 days' compliance fixes that ran without a click; with no fix in the window it reads "—" and says so.
- **Active exceptions** counts accepted risks still in force (approved, not revoked, not expired). It opens nothing: the Risk register lists every decision, so no list has exactly this total.
- **Findings by domain** chips open each domain's list with its total and how many are open.
- **Patch compliance**, **Next patch window**, **Backup coverage** and **Backups before changes** come from the saved report and the workspace's patch schedules; the two scores open the Patching and Backup lists.

## Change management

From the customer's mock-up: changes in CAB, change-related incidents, auto-approved low-risk and the change pipeline. Inherited as **Waiting for approval** (opens the pending list; the hint names the oldest wait), **Change-related incidents** (service incidents of the last 30 days a change is suspected of causing — no list filter carries this, so it is not a link), **Auto-released pre-approved** (the auto-handled count) and **Scheduled releases** (requests with a release scheduled ahead, and the next one). **Requests by status** chips open the Changes list under **Requests** with that status; **Changes per day** is the last 14 days. The mock-up's change success rate and AI risk score are not platform figures and were left out.

## SecOps

From the customer's mock-up: open detections, MTTD, critical vulns open and auto-enriched alerts. Inherited as **Open detections** (unresolved SecOps incidents; not a link, because the Incidents list has no pillar switch — the hub's SecOps ring opens this section for the same reason), **Critical CVEs** (critical vulnerability findings, opening that list) and **Denied-access reports** (a cloud call the cloud refused — a report, nothing changed — opening the incident search for them). MTTD and auto-enrichment are not measured by the platform and were left out.

## FinOps · Optimise

From the customer's mock-up: spend month-to-date, identified savings, commitment coverage and cost anomalies. The platform has no cloud cost data — cloud spend stays in the cloud's own cost tools — so the section says so and shows the AI agents' own cost for the workspace: **Agent spend today**, the last 30 days (test runs excluded) and the cost per incident occurrence; shown to people with `report.view` (the two spend figures open **Usage & billing**); the section is hidden for others and while the workspace has spent nothing.

## Continuous improvement

From the customer's mock-up: automation coverage, runbooks in library, knowledge articles and the automation candidates. Inherited as **Runbooks in library** (every step runbook, with how many an approver certified at their current revision, opening the [Runbook library](/help/runbook-library.md) for people with `datasources.view`), **Knowledge items** (the items the agents read, opening the Knowledge base for people with `knowledge.view`; the counts show to everyone), **Open problems** (opening Problems filtered to *open*, with the proposed ones in the hint) and **Automation candidates** (recurring fixes that held, with how many are blocked because a fix did not hold twice). Error-budget burn and engineer hours saved were left out: the platform does not measure them.

## Guardrails — always on

From the customer's mock-up: the six-item principles strip. Inherited word for word in its headings, with each sentence stating the platform's own rule: reads flow and every write pauses at the gate; every tier is released by an approver and a high-risk change by two distinct people; a fix runs on its own only through a certified runbook at its certified revision; every analysis names its evidence; a change carries its last-known-good state and rollback before it runs; every decision and action is an audit row in a per-workspace hash chain. None of them is a setting.

## Proposed, and left out

Decisions the mock-up did not make, taken while building the page:

- (proposed) The hub's centre counts incidents awaiting approval plus change requests pending approval. Risk requests, certifications, one-time windows and merge suggestions stay in **Needs you**; the hint says how many more wait there.
- (proposed) MTTR ends when the condition was verified gone (else at the resolve click), as the Service delivery report defines it, so the two pages never disagree.
- (proposed) Problems sit under **Continuous improvement**, not under **Incident & Problem**, because the automation candidates are what the page says about them.
- (proposed) A pillar's section disappears when the platform switches that pillar off; the ring stays, dashed, so the hub keeps its shape.
- (proposed) The Dashboard shows three pillars — Incident & Problem, Compliance, Change Mgmt — until a workspace lists more on **Guardrails → Dashboard pillars**; the other three are built but hidden, so the page sells what the product sells today.
- (proposed) The pipeline strip counts the workspace's stages rather than replaying one incident; the incident page keeps the per-incident pipeline.
- (proposed) The summary is cached for 60 seconds per workspace; the page says when it was read and refreshes every minute.
- (proposed) `Raise a concern` keeps its place in the header, as the only way to open an investigation by hand.

Left out of the mock-up, and why:

- The cross-pillar activity stream and the agent-fleet accuracy bars: the activity is on each record and in the audit log; an accuracy figure "over the last 1,000 actions" has no measure behind it.
- The ticker, the sci-fi faces, glows and count-up animations: the design system's tokens and motion rules apply instead.
- Per-pillar "Approve & run" cards on the dashboard: a decision is made next to the evidence, on the record, where the plan, the snapshot and the rollback are.
- Compliance by framework (CIS, ISO 27001, MAS TRM, Well-Architected): the scanners' standards are listed; the platform's own framework mapping is hidden by the 24 October decision.
- Change success rate, AI risk scores, collision warnings and the freeze countdown; MTTD and auto-enriched alerts; cloud spend, savings, commitment coverage and anomalies; automation coverage, error-budget burn and engineer hours saved: none is a figure the platform records.
- A region or environment badge in the header: a workspace is not tied to one.
- The sidebar's per-pillar entries with open-item badges: since the 25 September review the sidebar is grouped by task (Operate, Security posture, Insights, Agent quality), not by pillar, and the open counts per pillar are in the hub and in **Pillar health**.

[Needs you and approvals](/help/incidents.md) · [Service delivery report](/help/service-delivery-report.md) · [REST API](/help/rest-api.md).


## Next steps

- Next: [Dashboard, Operate and alerts](/help/mission-overview.md)
- [All Work with the agents pages](/help/work-with-the-agents/llms.txt)
- [Documentation home](/help/)