@oneuptime/common 13.0.4 → 13.0.6

package/build/dist/Types/Dashboard/DashboardTemplates.js

@@ -13,6 +13,9 @@ import MonitorType from "../Monitor/MonitorType";
 import MetricDashboardMetricType from "../Metrics/MetricDashboardMetricType";
 import { DashboardValueTrendDirection } from "./DashboardComponents/DashboardValueComponent";
 import { SloWidgetDisplayType, SloWidgetMetric, } from "./DashboardComponents/DashboardSloComponent";
+import SloMetricType from "../ServiceLevelObjective/SloMetricType";
+import SloMetricTypeUtil, { SLO_METRIC_SLO_ID_ATTRIBUTE, SLO_METRIC_SLO_NAME_ATTRIBUTE, } from "../../Utils/Slo/SloMetricType";
+import { SLO_LIST_DEFAULT_MAX_ROWS } from "../../Utils/Slo/SloListWidgetFormat";
 /*
  * Trace / Exception / Profiles entries are intentionally not in this
  * enum: their metric catalogs (e.g. SpanMetricType, ExceptionMetricType)
@@ -94,7 +97,7 @@ export const DashboardTemplates = [
     {
         type: DashboardTemplateType.Slo,
         name: "SLO Dashboard",
-        description: "One objective's SLI, error budget remaining and burn rate as tiles and trends, with monitor uptime, latency, incidents and alerts beside it. Pick the SLO on each widget after creating it.",
+        description: "Every SLO's status, SLI, error budget and burn rate in one list, fleet-wide budget and burn-rate trends, and live tiles and history for the SLO you pick in the toolbar.",
         icon: IconProp.Percent,
         category: DashboardTemplateCategory.Monitoring,
     },
@@ -682,18 +685,19 @@ function createNetworkMapComponent(data) {
     };
 }
 /*
- * An SLO widget names exactly ONE ServiceLevelObjective, by id. A template
- * cannot know which of a project's SLOs a reader means, so every widget the
- * SLO template ships leaves `serviceLevelObjectiveId` unset and the renderer
- * shows its "Click to select an SLO" setup state until the reader picks one
- * (DashboardSloComponent).
+ * An SLO widget shows exactly ONE ServiceLevelObjective. A template cannot
+ * know a project's SLO ids, so it never pins one: a baked-in id would point
+ * at nothing in every project but the one it was copied from, and on a
+ * public dashboard a stored id IS the authorization decision
+ * (PublicDashboardSloWidget). Instead every SLO widget a template ships
+ * follows the template's own SLO toolbar variable through
+ * `followVariableId`, so it shows whichever objective the reader picks and
+ * says "Choose an SLO in the toolbar" until one is picked
+ * (DashboardSloComponent, Common/Utils/Dashboard/SloWidgetSource).
  *
- * `widgetTitle` is therefore always set here. Left unset, the renderer titles
- * a configured widget "<SLO name> · <metric>", which is nicer once an SLO is
- * chosen but leaves all six unconfigured widgets reading "SLO Widget" in the
- * template a reader has just created. A self-describing template wins: the
- * reader can see which tile is the burn rate before anything is configured,
- * and can rename any of them afterwards.
+ * `widgetTitle` is always set. Before a pick the placeholder shows it, so the
+ * reader can tell the burn-rate tile from the SLI; after a pick the renderer
+ * leads it with the objective's name ("Checkout API · SLI").
  */
 function createSloComponent(data) {
     return {
@@ -711,33 +715,38 @@ function createSloComponent(data) {
             widgetTitle: data.title,
             sloMetric: data.sloMetric,
             displayType: data.displayType,
+            serviceLevelObjectiveVariableId: data.followVariableId,
         },
     };
 }
-function createIncidentListComponent(data) {
-    var _a;
-    return {
-        _type: ObjectType.DashboardComponent,
-        componentType: DashboardComponentType.IncidentList,
-        componentId: ObjectID.generate(),
-        topInDashboardUnits: data.top,
-        leftInDashboardUnits: data.left,
-        widthInDashboardUnits: data.width,
-        heightInDashboardUnits: data.height,
-        minHeightInDashboardUnits: 3,
-        minWidthInDashboardUnits: 6,
-        arguments: {
-            title: data.title,
-            maxRows: (_a = data.maxRows) !== null && _a !== void 0 ? _a : 25,
-            viewMode: "list",
-        },
-    };
-}
-function createAlertListComponent(data) {
+/*
+ * What the SLO template's fleet charts fan out by: one line per OBJECTIVE.
+ *
+ * `sloName` alone is not an objective. Names are not unique within a project
+ * (only the slug is), so two SLOs sharing a name would be one line — the Avg
+ * of both budgets, the Max of both burn rates — under a single legend entry.
+ * `sloId` splits them; `sloName` leads so the legend reads by name and stays
+ * the key the toolbar variable binds to. SloMetricUtil stamps both on every
+ * row it writes, which SloTemplateMetricEmitterContract pins.
+ *
+ * Renaming an SLO does start a new line under the new name, because the
+ * old rows keep the old one; grouping by id alone would avoid that but would
+ * label every line with a UUID.
+ */
+export const SLO_TEMPLATE_CHART_GROUP_BY_KEYS = [
+    SLO_METRIC_SLO_NAME_ATTRIBUTE,
+    SLO_METRIC_SLO_ID_ATTRIBUTE,
+];
+/*
+ * Every active SLO with its status, SLI against target, error budget and
+ * burn rate, least budget first (DashboardSloListComponent). Same floors the
+ * widget's own default declares (DashboardSloListComponentUtil).
+ */
+function createSloListComponent(data) {
     var _a;
     return {
         _type: ObjectType.DashboardComponent,
-        componentType: DashboardComponentType.AlertList,
+        componentType: DashboardComponentType.SloList,
         componentId: ObjectID.generate(),
         topInDashboardUnits: data.top,
         leftInDashboardUnits: data.left,
@@ -747,7 +756,7 @@ function createAlertListComponent(data) {
         minWidthInDashboardUnits: 6,
         arguments: {
             title: data.title,
-            maxRows: (_a = data.maxRows) !== null && _a !== void 0 ? _a : 25,
+            maxRows: (_a = data.maxRows) !== null && _a !== void 0 ? _a : SLO_LIST_DEFAULT_MAX_ROWS,
             viewMode: "list",
         },
     };
@@ -2607,72 +2616,106 @@ function createRumDashboardConfig() {
 }
 function createSloDashboardConfig() {
     /*
-     * What this template can and cannot query, which is what its whole shape
-     * follows from:
+     * How this template is built, and why:
      *
-     * - The three SLO numbers (SLI, error budget remaining, burn rate) live in
-     *   Postgres (the columns the evaluation worker maintains) and in the
-     *   SloHistory ClickHouse table. Neither is in the metric store, so a
-     *   Chart / Value / Gauge widget over a metric NAME can never render them.
-     *   The dedicated Slo widget is the only thing that reads them, and it
-     *   names exactly one SLO by id, which is why the six widgets below ship
-     *   unconfigured and the first text row says so.
+     * - It opens on the FLEET, so it is useful the moment it is created.
+     *   Everything above the "Selected SLO" header queries immediately with no
+     *   configuration: the SLO List reads every active objective's current
+     *   state from Postgres, and the Error Budget & Burn Rate band reads the
+     *   `oneuptime.slo.*` series the evaluation worker posts for every SLO
+     *   (SloMetricUtil), fanned out one line per objective by the bare
+     *   `sloName` attribute those series carry. SLOs at risk or out of budget
+     *   are counted in the list's own status strip, because a metric
+     *   aggregation can total a series but cannot count objectives by state.
      *
-     * - Dashboard variables do not reach the Slo widget at all: it resolves one
-     *   SLO from its stored id and has nothing to interpolate. The Monitor
-     *   variable below therefore scopes only the metric widgets in the second
-     *   half of the dashboard.
+     * - ONE toolbar variable scopes the whole board. "SLO" is a Telemetry
+     *   Attribute variable on that same bare `sloName` key (no `resource.`
+     *   prefix — the worker, not an OTel collector, writes it). Left on "All"
+     *   the dashboard is the fleet. Pick an objective and:
+     *     - the metric widgets narrow to its series
+     *       (DashboardVariableInterpolation),
+     *     - the SLO List narrows to its row, because `sloName` maps to the
+     *       SLO's `name` column (SLO_LIST_ATTRIBUTE_TO_COLUMN), and
+     *     - the Selected SLO widgets resolve it by name
+     *       (serviceLevelObjectiveVariableId, Common/Utils/Dashboard/SloWidgetSource).
+     *   It is single-select because those widgets can show only ONE objective:
+     *   a multi-select pick of several would leave six widgets asking for a
+     *   single pick while the charts above compared. It ships no default,
+     *   because a template cannot know a project's SLO names.
      *
-     * - Those metric widgets query `oneuptime.monitor.online` and
-     *   `oneuptime.monitor.response.time`, which MonitorMetricUtil emits for
-     *   EVERY probeable monitor in the project. Unscoped they describe the
-     *   project, not the objective. That is exactly what the Monitor variable
-     *   is for, and it binds to the bare `monitorName` attribute key those
-     *   series carry (no `resource.` prefix).
+     * - The picker's options are the `sloName` values posted in the last day,
+     *   not a read of the SLO table. That is the trade-off of using a Telemetry
+     *   Attribute variable, and it is deliberate: it is the one variable type
+     *   that scopes metric widgets, the SLO List and the Selected SLO widgets
+     *   alike, and that the public dashboard route resolves for anonymous
+     *   viewers. So every SLO the worker evaluates must post a point, including
+     *   the ones it can only guard — Paused, Misconfigured and not yet measured
+     *   (SloMetricUtil.saveSloGuardMetrics writes their target) — or they would
+     *   be listed below and unpickable here. What still leaves the picker is
+     *   what the worker does not evaluate at all: a disabled or archived SLO
+     *   drops out about a day after its last point, and a brand-new SLO appears
+     *   after its first evaluation tick.
      *
-     *   Two callers write those names, though, and only one stamps
-     *   `monitorName`. NetworkDeviceMetricUtil.saveWalkMetrics writes the same
-     *   `oneuptime.monitor.online` / `.response.time` names off a network
-     *   device poll with `deviceName` and `networkDeviceId` instead, so the
-     *   unscoped view is "every probeable monitor PLUS every network device",
-     *   and device rows drop out the moment a monitor is picked rather than
-     *   being selectable. Nothing here can filter them out — the template
-     *   helpers expose no stored attribute filter — so the widgets are
-     *   labelled for what they are and the Monitor variable is the scope.
+     * - The picker offers NAMES, because a list of ids would be unreadable, and
+     *   names are not unique. The fleet charts therefore group by name AND id
+     *   (SLO_TEMPLATE_CHART_GROUP_BY_KEYS), so two same-named objectives stay
+     *   two lines. Picking a shared name narrows the charts to both lines, the
+     *   SLO List to both rows and the tiles to the worse of the two, while the
+     *   Selected SLO widgets refuse to guess and say the name is ambiguous.
      *
-     * - The Objective Health tiles do NOT follow the dashboard time picker.
-     *   They read the SLO's own state columns, which the evaluation worker
-     *   maintains over the objective's compliance window; only the three Slo
-     *   CHARTS and the monitor widgets honour the selected range.
+     * - The Selected SLO widgets are the only ones that wait for a pick, and
+     *   they ask for it in terms of the toolbar ("Choose an SLO in the toolbar
+     *   to see it here") — the one control that works in the view mode a new
+     *   dashboard opens in — so no SLO id is baked in and no instruction row
+     *   is needed. They carry what the metric series cannot:
+     *     - the objective's CURRENT state with its status pill and target
+     *       (the tiles read the SLO row, not an aggregate over the window), and
+     *     - SloHistory's 400-day series with the SLI target drawn as a
+     *       reference line, where `oneuptime.slo.*` keeps only the monitor
+     *       metric retention (30 days by default).
+     *   The tiles therefore do NOT follow the dashboard time picker; the
+     *   history charts and the whole Error Budget & Burn Rate band do.
      *
-     * - Incident and alert METRICS are deliberately NOT on this dashboard even
-     *   though an error budget is spent by incidents, for two DIFFERENT
-     *   reasons — not one shared one.
+     * - The budget and burn-rate tiles aggregate with Min and Max rather than each
+     *   series' own Avg (SloMetricTypeUtil.getAggregationType), because they
+     *   must read truthfully in BOTH states of the toolbar. Across the fleet an
+     *   average of several objectives' budgets is nobody's budget, while the
+     *   LOWEST budget and the PEAK burn rate are the numbers someone acts on;
+     *   with one SLO picked they become that objective's low point and peak
+     *   over the window. The charts keep each series' own aggregation.
      *
-     *   Incident metrics cannot be scoped at all: IncidentService stamps them
-     *   with `monitorNames` (plural, comma-joined) rather than `monitorName`,
-     *   so picking a monitor would empty every incident tile while the uptime
-     *   tiles beside them stayed populated.
+     * - The SLI is not charted fleet-wide. Objectives run at different targets
+     *   (a 95% and a 99.99% objective on one axis read as a flat line and a
+     *   dot), so the SLI is shown per objective, against its own target, in
+     *   the Selected SLO section. Budget remaining and burn rate are already
+     *   normalised to each objective, which is what makes them comparable.
      *
-     *   Alert metrics CAN be scoped — AlertService writes the singular key —
-     *   but createBurnRateAlert in EvaluateSlos never sets `monitor`, so a
-     *   burn-rate alert carries no `monitorName` and a scoped alert tile would
-     *   hide precisely the alerts this dashboard exists for. (That omission is
-     *   not the uptime-repair problem its incident twin has: resolving an
-     *   Alert never writes MonitorStatusTimeline — only the Incident path
-     *   reaches markMonitorsActiveForMonitoring.)
+     * - Deliberately NOT here: project-wide incident, alert and monitor lists,
+     *   and monitor uptime / latency series. None of them can be narrowed to an
+     *   objective — the lists have no SLO filter and ignore telemetry
+     *   variables, and monitor series carry `monitorName`, never `sloName` — so
+     *   beside an SLO they read as that SLO's incidents and monitors while
+     *   showing the whole project's. The SLO's own Incidents, Alerts and
+     *   Monitors pages are the scoped views of those.
      *
-     *   The incident and alert LISTS below read Postgres and ignore telemetry
-     *   variables entirely, so they stay correct under every selection — but
-     *   they are project-wide and honour no time range; see their row.
+     * - Archived SLOs appear nowhere. They are not evaluated, so they post no
+     *   new `oneuptime.slo.*` points (and leave the SLO picker as their last
+     *   points age out); the SLO List excludes them; and a Selected SLO widget
+     *   will not resolve a name to one.
      *
-     * - Monitor uptime is a PROXY, not the SLI. An availability SLI is
-     *   computed from MonitorStatusTimeline downtime intervals (honouring
-     *   maintenance windows and the SLO's own downtime statuses); the uptime
-     *   tile is the probe's raw 0/1 series averaged over the window. They will
-     *   disagree, which is why the tile is labelled "Monitor Uptime" rather
-     *   than anything that reads as a second opinion on the SLI.
+     * - Disabled SLOs are not evaluated either, but they are still the
+     *   project's objectives, so the SLO List keeps them: marked Disabled
+     *   rather than showing the status they were frozen at, counted apart in
+     *   its status strip, and ordered after every enabled objective so a frozen
+     *   overspent budget never tops the list (SloListWidgetFormat). Like
+     *   archived ones, they leave the picker as their last points age out.
      */
+    const sloVariable = createTelemetryAttributeVariable({
+        name: "slo",
+        label: "SLO",
+        attributeKey: SLO_METRIC_SLO_NAME_ATTRIBUTE,
+        isMultiSelect: false,
+    });
     const components = [
         // Row 0: Title
         createTextComponent({
@@ -2684,51 +2727,145 @@ function createSloDashboardConfig() {
             isBold: true,
         }),
         /*
-         * Row 1: the one instruction a reader needs on a freshly created SLO
-         * dashboard. No other template carries a guidance row, and none of them
-         * has to: their widgets query immediately. Every Slo widget here is
-         * inert until somebody picks an objective, so saying it once beats six
-         * identical "Click to select an SLO" placeholders explaining themselves.
-         *
-         * It names EDIT deliberately. The widgets' own placeholder says "Click
-         * to select an SLO", but the click only opens the settings panel in
-         * edit mode — and a dashboard created from a template opens in view
-         * mode, where following that instruction does nothing.
+         * Rows 1-5: every active objective — status, SLI against its target, an
+         * error-budget bar and the burn rate — enabled first, least budget first,
+         * so the objectives in trouble lead and a capped list drops disabled ones
+         * and then the healthiest.
+         * Full width because each row carries five columns and the budget bar
+         * has to read as a bar.
          *
-         * Kept to one short line on purpose: the Text widget scales its font to
-         * the widget's height, so a sentence much past ~70 characters wraps out
-         * of a height-1 row and is clipped. Everything else this dashboard
-         * needs to say is said by the widget titles.
+         * No section heading above it: like the Monitor and Kubernetes templates,
+         * the board opens on its headline band directly under the title. The
+         * list card already carries its own title, so a heading here would stack
+         * three titles on one card.
          */
-        createTextComponent({
-            text: "Edit this dashboard to pick an objective on each SLO widget.",
+        createSloListComponent({
+            title: "Service Level Objectives",
             top: 1,
             left: 0,
             width: 12,
+            height: 5,
+            maxRows: SLO_LIST_DEFAULT_MAX_ROWS,
+        }),
+        /*
+         * Row 6: Section header. Named for both halves of the band — burn rate is
+         * how fast the budget is being spent, but a heading that said only
+         * "Error Budget" would sit over two burn-rate widgets.
+         */
+        createTextComponent({
+            text: "Error Budget & Burn Rate",
+            top: 6,
+            left: 0,
+            width: 12,
             height: 1,
+            isBold: true,
+        }),
+        /*
+         * Row 7: the worst case across whatever the toolbar selects — the least
+         * budget left, as a share and as time, and the fastest it is being spent.
+         * Units come from each series' MetricType row (%, seconds scaled to
+         * minutes/hours, x), so the titles carry none. Trend colours are set
+         * explicitly: the name heuristic cannot know that more budget is good.
+         */
+        createValueComponent({
+            title: "Lowest Error Budget Remaining",
+            top: 7,
+            left: 0,
+            width: 4,
+            metricConfig: {
+                metricName: SloMetricType.ErrorBudgetRemainingPercent,
+                aggregationType: MetricsAggregationType.Min,
+            },
+            trendDirection: DashboardValueTrendDirection.HigherIsBetter,
+        }),
+        createValueComponent({
+            title: "Least Error Budget Time Left",
+            top: 7,
+            left: 4,
+            width: 4,
+            metricConfig: {
+                metricName: SloMetricType.ErrorBudgetRemainingSeconds,
+                aggregationType: MetricsAggregationType.Min,
+            },
+            trendDirection: DashboardValueTrendDirection.HigherIsBetter,
+        }),
+        createValueComponent({
+            title: "Peak Burn Rate",
+            top: 7,
+            left: 8,
+            width: 4,
+            metricConfig: {
+                metricName: SloMetricType.BurnRate,
+                aggregationType: MetricsAggregationType.Max,
+            },
+            trendDirection: DashboardValueTrendDirection.HigherIsWorse,
+        }),
+        /*
+         * Rows 8-11: the same two normalised numbers over the dashboard's time
+         * range, one line per objective. Grouped by `sloName` AND `sloId`
+         * (SLO_TEMPLATE_CHART_GROUP_BY_KEYS): names are not unique within a
+         * project, and grouped by name alone two objectives sharing one would be
+         * drawn as a single line — the average of both budgets, the peak of both
+         * burn rates — under one legend entry, hiding the one in trouble. The name
+         * leads, so the legend still reads by name, and it is the same key the
+         * toolbar variable binds to, so a pick leaves that objective's line (or
+         * both same-named lines, told apart by id). Aggregation, legend and unit
+         * all come from SloMetricTypeUtil — the table the worker registers each
+         * series' MetricType row from — so the chart cannot label a series
+         * differently from the catalog.
+         */
+        createChartComponent({
+            title: "Error Budget Remaining by SLO",
+            chartType: DashboardChartType.Line,
+            top: 8,
+            left: 0,
+            width: 6,
+            height: 4,
+            metricConfig: {
+                metricName: SloMetricType.ErrorBudgetRemainingPercent,
+                aggregationType: SloMetricTypeUtil.getAggregationType(SloMetricType.ErrorBudgetRemainingPercent),
+                legend: SloMetricTypeUtil.getLegend(SloMetricType.ErrorBudgetRemainingPercent),
+                legendUnit: SloMetricTypeUtil.getLegendUnit(SloMetricType.ErrorBudgetRemainingPercent),
+                groupByAttributeKeys: [...SLO_TEMPLATE_CHART_GROUP_BY_KEYS],
+            },
+        }),
+        createChartComponent({
+            title: "Burn Rate by SLO",
+            chartType: DashboardChartType.Line,
+            top: 8,
+            left: 6,
+            width: 6,
+            height: 4,
+            metricConfig: {
+                metricName: SloMetricType.BurnRate,
+                aggregationType: SloMetricTypeUtil.getAggregationType(SloMetricType.BurnRate),
+                legend: SloMetricTypeUtil.getLegend(SloMetricType.BurnRate),
+                legendUnit: SloMetricTypeUtil.getLegendUnit(SloMetricType.BurnRate),
+                groupByAttributeKeys: [...SLO_TEMPLATE_CHART_GROUP_BY_KEYS],
+            },
         }),
-        // Row 2: Section header
+        // Row 12: Section header
         createTextComponent({
-            text: "Objective Health",
-            top: 2,
+            text: "Selected SLO",
+            top: 12,
             left: 0,
             width: 12,
             height: 1,
             isBold: true,
         }),
         /*
-         * Rows 3-5: the three numbers an SLO review opens with, in the order
-         * they are read — where the service is (SLI), how much room is left
-         * (error budget), and how fast the room is disappearing (burn rate).
-         * Every tile carries the SLO's status pill; the sublines differ — SLI
-         * shows the target, the budget tile shows time remaining or over
-         * budget, and burn rate has none.
+         * Rows 13-15: the picked objective's CURRENT numbers, in the order an SLO
+         * review reads them — where the service is (SLI, with its target), how
+         * much room is left (budget, with time remaining or over budget), and
+         * how fast the room is disappearing (burn rate). Each tile carries the
+         * objective's status pill.
          */
         createSloComponent({
             title: "SLI",
             sloMetric: SloWidgetMetric.Sli,
             displayType: SloWidgetDisplayType.Tile,
-            top: 3,
+            followVariableId: sloVariable.id,
+            top: 13,
             left: 0,
             width: 4,
             height: 3,
@@ -2737,7 +2874,8 @@ function createSloDashboardConfig() {
             title: "Error Budget Remaining",
             sloMetric: SloWidgetMetric.ErrorBudgetRemaining,
             displayType: SloWidgetDisplayType.Tile,
-            top: 3,
+            followVariableId: sloVariable.id,
+            top: 13,
             left: 4,
             width: 4,
             height: 3,
@@ -2746,206 +2884,57 @@ function createSloDashboardConfig() {
             title: "Burn Rate",
             sloMetric: SloWidgetMetric.BurnRate,
             displayType: SloWidgetDisplayType.Tile,
-            top: 3,
+            followVariableId: sloVariable.id,
+            top: 13,
             left: 8,
             width: 4,
             height: 3,
         }),
-        // Row 6: Section header
-        createTextComponent({
-            text: "Error Budget Trends",
-            top: 6,
-            left: 0,
-            width: 12,
-            height: 1,
-            isBold: true,
-        }),
         /*
-         * Rows 7-10: the same three numbers over the dashboard's time range,
-         * read from SloHistory. The SLI chart draws the objective's target as a
-         * reference line, so "are we above the line" is answerable at a glance
-         * rather than by comparing two numbers.
+         * Rows 16-19: each tile's history directly beneath it, from SloHistory
+         * (400 days), so a column reads as "now, and how it got here". The SLI
+         * chart draws the objective's target as a reference line. Titled
+         * "History" rather than "Over Time" because the renderer leads a picked
+         * objective's title with its name, and a four-unit column has no room for
+         * both.
          */
         createSloComponent({
-            title: "SLI Over Time",
+            title: "SLI History",
             sloMetric: SloWidgetMetric.Sli,
             displayType: SloWidgetDisplayType.Chart,
-            top: 7,
+            followVariableId: sloVariable.id,
+            top: 16,
             left: 0,
-            width: 6,
+            width: 4,
             height: 4,
         }),
         createSloComponent({
-            title: "Error Budget Remaining Over Time",
+            title: "Error Budget History",
             sloMetric: SloWidgetMetric.ErrorBudgetRemaining,
             displayType: SloWidgetDisplayType.Chart,
-            top: 7,
-            left: 6,
-            width: 6,
+            followVariableId: sloVariable.id,
+            top: 16,
+            left: 4,
+            width: 4,
             height: 4,
         }),
-        /*
-         * Rows 11-14: burn rate beside the incidents. A burn-rate rule declares
-         * an incident when the budget starts going fast, so the spike and the
-         * record of what was done about it belong on one row.
-         *
-         * The list cannot be narrowed to those incidents, though, and says so
-         * in its title. IncidentList has no SLO or fingerprint filter, and —
-         * unlike every chart on this dashboard — it does not read
-         * `dashboardStartAndEndDate` at all. It is the project's latest
-         * incidents, newest first, NOT the incidents inside the window the
-         * chart beside it is drawing. Titled "Latest" rather than "Recent" so
-         * it does not imply the dashboard's time range.
-         */
         createSloComponent({
-            title: "Burn Rate Over Time",
+            title: "Burn Rate History",
             sloMetric: SloWidgetMetric.BurnRate,
             displayType: SloWidgetDisplayType.Chart,
-            top: 11,
-            left: 0,
-            width: 6,
-            height: 4,
-        }),
-        createIncidentListComponent({
-            title: "Latest Incidents",
-            top: 11,
-            left: 6,
-            width: 6,
-            height: 4,
-            maxRows: 25,
-        }),
-        // Row 15: Section header
-        createTextComponent({
-            text: "Monitor Health",
-            top: 15,
-            left: 0,
-            width: 12,
-            height: 1,
-            isBold: true,
-        }),
-        /*
-         * Row 16: the probe's own view of the monitors the SLO is built on.
-         *
-         * IsOnline is emitted as 0/1 with unit "", so Avg is an uptime RATIO in
-         * [0, 1] and not a percent — labelled "(avg)" for the same reason the
-         * Monitor template labels its tile that way. Response time gets both an
-         * average and a max: an SLO that is burning on latency usually shows it
-         * in the tail long before the mean moves.
-         */
-        createValueComponent({
-            title: "Monitor Uptime (avg)",
-            top: 16,
-            left: 0,
-            width: 4,
-            metricConfig: {
-                metricName: MonitorMetricType.IsOnline,
-                aggregationType: MetricsAggregationType.Avg,
-            },
-            trendDirection: DashboardValueTrendDirection.HigherIsBetter,
-        }),
-        createValueComponent({
-            title: "Avg Response Time",
-            top: 16,
-            left: 4,
-            width: 4,
-            metricConfig: {
-                metricName: MonitorMetricType.ResponseTime,
-                aggregationType: MetricsAggregationType.Avg,
-                legendUnit: "ms",
-            },
-            trendDirection: DashboardValueTrendDirection.HigherIsWorse,
-        }),
-        createValueComponent({
-            title: "Worst Response Time",
+            followVariableId: sloVariable.id,
             top: 16,
             left: 8,
             width: 4,
-            metricConfig: {
-                metricName: MonitorMetricType.ResponseTime,
-                aggregationType: MetricsAggregationType.Max,
-                legendUnit: "ms",
-            },
-            trendDirection: DashboardValueTrendDirection.HigherIsWorse,
-        }),
-        // Rows 17-19: the same two signals over time.
-        createChartComponent({
-            title: "Monitor Uptime Over Time",
-            chartType: DashboardChartType.Area,
-            top: 17,
-            left: 0,
-            width: 6,
-            height: 3,
-            metricConfig: {
-                metricName: MonitorMetricType.IsOnline,
-                aggregationType: MetricsAggregationType.Avg,
-                legend: "Uptime Ratio",
-            },
-        }),
-        createChartComponent({
-            title: "Response Time Over Time",
-            chartType: DashboardChartType.Line,
-            top: 17,
-            left: 6,
-            width: 6,
-            height: 3,
-            metricConfig: {
-                metricName: MonitorMetricType.ResponseTime,
-                aggregationType: MetricsAggregationType.Avg,
-                legend: "Avg Response Time",
-                legendUnit: "ms",
-            },
-        }),
-        /*
-         * Rows 20-23: the monitors themselves, and the alerts a burn-rate rule
-         * raises. Both read Postgres, so neither is affected by the Monitor
-         * variable and neither honours the dashboard time range.
-         *
-         * The monitor list is titled "All Monitors" rather than anything that
-         * implies the objective: MonitorList's only variable binding is
-         * `labelVariableId` against a ProjectLabel variable, which this
-         * template does not ship, so nothing the reader does in the toolbar
-         * narrows it. The section header above was "Monitors Behind the
-         * Objective" and promised exactly the scoping none of these widgets
-         * has on a freshly created dashboard. Scope the list with its own
-         * Labels filter if the project is large.
-         */
-        createMonitorListComponent({
-            title: "All Monitors",
-            top: 20,
-            left: 0,
-            width: 6,
-            height: 4,
-            maxRows: 25,
-        }),
-        createAlertListComponent({
-            title: "Latest Alerts",
-            top: 20,
-            left: 6,
-            width: 6,
             height: 4,
-            maxRows: 25,
-        }),
-    ];
-    /*
-     * Monitor metrics are stored with the bare `monitorName` attribute key
-     * rather than the OTel `resource.` prefix — see
-     * MonitorMetricUtil.buildAttributes — so the variable binds to the bare
-     * key. Multi-select because an objective is normally backed by several
-     * monitors, and picking one of them would describe less than the SLO does.
-     */
-    const variables = [
-        createTelemetryAttributeVariable({
-            name: "monitor",
-            label: "Monitor",
-            attributeKey: "monitorName",
-            isMultiSelect: true,
         }),
     ];
+    const variables = [sloVariable];
     return {
         _type: ObjectType.DashboardViewConfig,
         components,
         variables,
-        heightInDashboardUnits: Math.max(DashboardSize.heightInDashboardUnits, 24),
+        heightInDashboardUnits: Math.max(DashboardSize.heightInDashboardUnits, 20),
     };
 }
 function createHostDashboardConfig() {