Home Page

The console root (/) is Home — a glance board that answers "what needs me now?" across the projects you can access. Signing in lands you here. The page is served by GET /api/v1/briefing and refreshes automatically every 30 seconds while the tab is in the foreground. The Operations performance card is served separately, by GET /api/v1/service-desk/metrics/series and GET /api/v1/alerts/metrics/series; its figures cover whole past days, so it is not part of the 30-second refresh.

What you see

Top to bottom:

1. A greeting and a one-line summary of what needs action (for example, Acme Retail: 1 P1 alert needs action · 1 monitor down). The summary only mentions sections you can see and that loaded. With nothing to report it says "Nothing needs action right now" — but only when at least one of alerts, monitors, vulnerabilities or waiting tickets loaded; if a section couldn't load it says "Some sections couldn't load" instead, and if you can see none of those sections it shows no summary at all.
2. The project filter (on the right of the header) — see Filtering by project.
3. A key numbers band: P1 alerts (plus unclassified), monitors up, agents current, KEV packages, and tickets waiting on you. A number whose section you cannot see, or whose source failed, is left out — never shown as 0.
4. A grid of widgets, described below.
5. An Operations performance card — Service Desk and alert response figures with trend bars, and a 7d / 30d / 90d period switch.

Lists in the widgets show at most three rows, followed by an "N more →" link to the owning page with the same project filter applied.

Widgets

Widget	What it shows	Needs
Active P1 alerts	Firing or acknowledged P1 alerts and unclassified (unknown severity) alerts, P1 first, most recently active first. Links to the Alerts page.	alerts:read
On-call now	Who a P1 would page: the escalation steps of the matching policy, the person on shift now for schedule steps, and when each later step fires. Warnings appear when a P1 would page nobody — no matching route, on-call off for the project, the policy's owner team still in shadow, an invalid policy, a policy not owned by a team, or a policy with no step that notifies anyone — or when the policy is one you don't have access to. A chain is shown only when the escalation engine would actually page it.	oncall:read, schedules:write or escalation:write
Uptime monitors	Up / total, with down and pending monitors listed oldest first. Paused, disabled and maintenance monitors are counted apart from up.	monitors:read
Agent fleet	Agents up to date, with an update available, outdated, and stale (not reporting), plus progress of an active update rollout. The counts match the Fleet page.	agents:read
Vulnerabilities awaiting updates	Open CVEs and known-exploited (CISA KEV) packages, listing KEV and critical packages first, by how many hosts run them.	hosts:read
Service Desk — waiting on you	Your requests in Client Review (awaiting your approval) and Waiting for Info (needs your reply). Counts of 20 or more show as "20+". Only requests from projects where you hold servicedesk:read are listed.	Service Desk feature and servicedesk:read

The On-call now preview matches a P1 that has no environment, host or labels. Routes scoped to an environment, host or label can send a real P1 elsewhere; when a project has such routes, the widget says how many it is not showing.

Operations performance

The bottom card shows how the team performed over the last 7, 30 or 90 days, compared with the period of the same length before it. One period switch drives the whole card. The choice is kept in the URL (?period=), and 30 days is the default. The line under the title names the scope and the window, for example Acme Retail · last 30d vs the 30d before · UTC.

The card has two rows. Each row appears only if you can read it, and each loads on its own. If one row fails, it shows "Couldn't load" with a Retry button, and the other row is unaffected. One exception: when the Service Desk data itself cannot be reached, the outage is shown once, on the Service Desk — waiting on you card, and the Service Desk row is hidden until it recovers.

Row	Tiles	Needs
Service Desk	MTTA and MTTR (business hours), First-response SLA and Resolution SLA (% of SLA-tracked requests met), requests Resolved, and SLA breaches	Service Desk feature and servicedesk:read
Alert response	MTTA and MTTR (minutes from an alert group first firing to its acknowledgement or resolution), Escalated past first responder (the share of alert groups that entered escalation in which the escalation went on to run a later person-facing step — one that may have reached nobody, for example when no one is on shift), and Noise (the share of resolved alert groups nobody acknowledged)	alerts:read

The Alert response row counts P1 and P2 alerts only, and says so under its heading. Lower severities are often resolved automatically or never acknowledged, and would drown the signal. The ⓘ button beside each alert tile gives its definition.

When few alerts are acknowledged in Console, a muted line above the alert tiles says so, for example "Only 1 of 300 resolved P1 and P2 alert groups were acknowledged in Console". It appears when at least 5 alert groups resolved in the period and fewer than 20% of them were acknowledged. An MTTA worked out from a handful of acknowledgements describes those few alerts, not the team's response, and the line keeps it from being read as a good sign. It is a note, not a warning.

Reading a tile

• The number covers the whole period. It is worked out from every request or alert in the period, not by averaging the daily points.
• The trend bars show the shape of the period: one bar per day for 7 and 30 days, and one per week for 90 days (weeks start on Monday). Days and weeks are counted in UTC, and the period ends at the start of today (UTC), or of this week for 90 days, so the last bar is always a complete day or week and never a partial one that looks like a bad day.
• Empty slots. A day with no data is an empty slot on the baseline and is never counted as 0. For example, a day with no acknowledged alerts has no MTTA, so its slot is empty. Bars always start at 0, so a bar's height is its value. The last day that had data is drawn in full colour and the earlier bars lighter, so a trailing empty day moves the emphasis back.
• Too little data for a chart. When only 1 or 2 days (or weeks) in the period have data, the tile shows how much data its value comes from instead of bars, for example 1 ack in 30d, 2 entered escalation in 30d, from 4 tickets in 30d or from 2 resolved groups in 30d. One or two bars across a month read as noise, not a trend. Tickets and alert groups are counted by the day they were created or first fired, not the day they were resolved, so this is not the same count as the Resolved tile. With no day of data at all the tile shows "—" and the reason instead, with no chart and no count.
• Count tiles (Resolved, SLA breaches) always draw bars: a day with none is a real 0, not an empty slot. When the last day of the period is such a 0, it is still the last day with data, so no bar is drawn in full colour.
• "—" versus 0. "—" means there was nothing to measure in the period, and the note says why, for example "no acks in period" or "no tickets in period". 0 is a real count of zero, such as no SLA breaches.
• The note under the number is the change against the previous period, as a signed value with the period it is compared to: +2.1h vs prev 30d, −3 pts vs prev 30d (percentage points), or no change vs prev 30d. If the previous period had no data, it says no data for prev 30d rather than comparing against 0. The note is never coloured green or red. Whether a rise is good depends on the metric (a higher MTTR is worse, a higher SLA % is better), so read the value itself.

While a new period or project loads, the previous numbers stay on screen, dimmed, until the new ones arrive.

Select a project

Users who can see every project (super admins) see "Select a project to see Service Desk performance" instead of the Service Desk tiles until they pick a project. Adding up the Service Desk figures of every client on every page load is refused on purpose. The Alert response row is shown across all projects. The Vulnerabilities widget, like Service Desk performance, needs a project selected for these users. A project with no Service Desk organization linked has no Service Desk row at all.

Known limitations

• A reopened alert is measured from its first firing. If an alert resolves and later fires again, its MTTA and MTTR count from the first time it fired, including the time it spent resolved.
• "Escalated past first responder" can read low, never high. An alert counts only when the escalation actually ran a later step that pages a person. An alert acknowledged by the first responder while the policy was still waiting does not count, and a policy with only one step that pages a person never counts. When a policy repeats its steps (or re-escalates an unconfirmed acknowledgement), an alert that did reach a second person and then went round again can be counted as not escalated.
• Service Desk days are Tashkent days. The Service Desk data stores Tashkent local time, so a Service Desk "UTC" day actually runs from midnight to midnight Tashkent time. Alert response days are true UTC days.
• Alert response covers P1 and P2 only. P3 to P5 and unclassified alerts are not included.

Filtering by project

The project filter narrows every widget, the key numbers and the summary to one project. The filter menu lists each project you can access with a coloured status dot and the reason for it (for example, 1 P1 or 1 down): critical, needs attention, OK, or unknown when you cannot read any of that project's signals (or one you can read failed to load). The dot is always paired with text. If project status could not be loaded at all, the filter says "Project status couldn't load" above the menu.

The selected project is kept in the URL as ?project=<id>, so a filtered Home can be bookmarked or shared. The breadcrumb reads Home / <project>, and per-row project names are hidden while a project is selected. Choose All projects or the ✕ on the project chip to clear it. If the URL names a project you don't have access to, the filter is cleared and a message tells you so.

Empty, absent and couldn't load

A widget can be in three different states, and the page keeps them apart:

• Empty — the source answered and there is nothing to show. The widget says so in words, for example "All monitors up" or "Nothing waiting on you".
• Absent — you lack the permission, or the feature is off for every project in scope. The widget is not shown at all.
• Couldn't load — the source failed or timed out. The widget says "Couldn't load this section" with a Retry button, and never shows the empty sentence, so a failure is never mistaken for "all clear". Other widgets are unaffected.

Access and scoping

Every widget applies its own permission and is scoped to the projects — and, where your role is limited to an environment, the environments — you can access. A number you could not open is never counted. Permissions and feature flags are two separate gates; see Permissions vs. feature flags.