@oneuptime/common 13.0.1 → 13.0.4

package/Types/Dashboard/DashboardTemplates.ts

@@ -14,6 +14,10 @@ import MonitorMetricType from "../Monitor/MonitorMetricType";
 import MonitorType from "../Monitor/MonitorType";
 import MetricDashboardMetricType from "../Metrics/MetricDashboardMetricType";
 import { DashboardValueTrendDirection } from "./DashboardComponents/DashboardValueComponent";
+import {
+  SloWidgetDisplayType,
+  SloWidgetMetric,
+} from "./DashboardComponents/DashboardSloComponent";
 
 /*
  * Trace / Exception / Profiles entries are intentionally not in this
@@ -42,6 +46,7 @@ export enum DashboardTemplateType {
   Metrics = "Metrics",
   Rum = "Rum",
   Network = "Network",
+  Slo = "Slo",
 }
 
 /*
@@ -104,6 +109,14 @@ export const DashboardTemplates: Array<DashboardTemplate> = [
     icon: IconProp.Globe,
     category: DashboardTemplateCategory.Monitoring,
   },
+  {
+    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.",
+    icon: IconProp.Percent,
+    category: DashboardTemplateCategory.Monitoring,
+  },
   {
     type: DashboardTemplateType.Incident,
     name: "Incident Dashboard",
@@ -904,6 +917,100 @@ 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).
+ *
+ * `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.
+ */
+function createSloComponent(data: {
+  title: string;
+  sloMetric: SloWidgetMetric;
+  displayType: SloWidgetDisplayType;
+  top: number;
+  left: number;
+  width: number;
+  height: number;
+}): DashboardBaseComponent {
+  return {
+    _type: ObjectType.DashboardComponent,
+    componentType: DashboardComponentType.Slo,
+    componentId: ObjectID.generate(),
+    topInDashboardUnits: data.top,
+    leftInDashboardUnits: data.left,
+    widthInDashboardUnits: data.width,
+    heightInDashboardUnits: data.height,
+    // Same floor the widget's own default declares (DashboardSloComponentUtil).
+    minHeightInDashboardUnits: 2,
+    minWidthInDashboardUnits: 2,
+    arguments: {
+      widgetTitle: data.title,
+      sloMetric: data.sloMetric,
+      displayType: data.displayType,
+    },
+  };
+}
+
+function createIncidentListComponent(data: {
+  title: string;
+  top: number;
+  left: number;
+  width: number;
+  height: number;
+  maxRows?: number;
+}): DashboardBaseComponent {
+  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: data.maxRows ?? 25,
+      viewMode: "list",
+    },
+  };
+}
+
+function createAlertListComponent(data: {
+  title: string;
+  top: number;
+  left: number;
+  width: number;
+  height: number;
+  maxRows?: number;
+}): DashboardBaseComponent {
+  return {
+    _type: ObjectType.DashboardComponent,
+    componentType: DashboardComponentType.AlertList,
+    componentId: ObjectID.generate(),
+    topInDashboardUnits: data.top,
+    leftInDashboardUnits: data.left,
+    widthInDashboardUnits: data.width,
+    heightInDashboardUnits: data.height,
+    minHeightInDashboardUnits: 3,
+    minWidthInDashboardUnits: 6,
+    arguments: {
+      title: data.title,
+      maxRows: data.maxRows ?? 25,
+      viewMode: "list",
+    },
+  };
+}
+
 function createMonitorListComponent(data: {
   title: string;
   top: number;
@@ -2839,6 +2946,362 @@ function createRumDashboardConfig(): DashboardViewConfig {
   };
 }
 
+function createSloDashboardConfig(): DashboardViewConfig {
+  /*
+   * What this template can and cannot query, which is what its whole shape
+   * follows from:
+   *
+   * - 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.
+   *
+   * - 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.
+   *
+   * - 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).
+   *
+   *   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 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.
+   *
+   * - 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.
+   *
+   *   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.
+   *
+   *   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.)
+   *
+   *   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.
+   *
+   * - 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.
+   */
+  const components: Array<DashboardBaseComponent> = [
+    // Row 0: Title
+    createTextComponent({
+      text: "SLO Dashboard",
+      top: 0,
+      left: 0,
+      width: 12,
+      height: 1,
+      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.
+     *
+     * 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.
+     */
+    createTextComponent({
+      text: "Edit this dashboard to pick an objective on each SLO widget.",
+      top: 1,
+      left: 0,
+      width: 12,
+      height: 1,
+    }),
+
+    // Row 2: Section header
+    createTextComponent({
+      text: "Objective Health",
+      top: 2,
+      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.
+     */
+    createSloComponent({
+      title: "SLI",
+      sloMetric: SloWidgetMetric.Sli,
+      displayType: SloWidgetDisplayType.Tile,
+      top: 3,
+      left: 0,
+      width: 4,
+      height: 3,
+    }),
+    createSloComponent({
+      title: "Error Budget Remaining",
+      sloMetric: SloWidgetMetric.ErrorBudgetRemaining,
+      displayType: SloWidgetDisplayType.Tile,
+      top: 3,
+      left: 4,
+      width: 4,
+      height: 3,
+    }),
+    createSloComponent({
+      title: "Burn Rate",
+      sloMetric: SloWidgetMetric.BurnRate,
+      displayType: SloWidgetDisplayType.Tile,
+      top: 3,
+      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.
+     */
+    createSloComponent({
+      title: "SLI Over Time",
+      sloMetric: SloWidgetMetric.Sli,
+      displayType: SloWidgetDisplayType.Chart,
+      top: 7,
+      left: 0,
+      width: 6,
+      height: 4,
+    }),
+    createSloComponent({
+      title: "Error Budget Remaining Over Time",
+      sloMetric: SloWidgetMetric.ErrorBudgetRemaining,
+      displayType: SloWidgetDisplayType.Chart,
+      top: 7,
+      left: 6,
+      width: 6,
+      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",
+      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",
+      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: Array<DashboardVariable> = [
+    createTelemetryAttributeVariable({
+      name: "monitor",
+      label: "Monitor",
+      attributeKey: "monitorName",
+      isMultiSelect: true,
+    }),
+  ];
+
+  return {
+    _type: ObjectType.DashboardViewConfig,
+    components,
+    variables,
+    heightInDashboardUnits: Math.max(DashboardSize.heightInDashboardUnits, 24),
+  };
+}
+
 function createHostDashboardConfig(): DashboardViewConfig {
   /*
    * Layout notes:
@@ -4146,6 +4609,8 @@ export function getTemplateConfig(
       return createMetricsDashboardConfig();
     case DashboardTemplateType.Rum:
       return createRumDashboardConfig();
+    case DashboardTemplateType.Slo:
+      return createSloDashboardConfig();
     case DashboardTemplateType.Network:
       return createNetworkDashboardConfig();
     case DashboardTemplateType.Blank:

package/Types/OnCallDutyPolicy/Layer.ts

@@ -313,6 +313,18 @@ export default class LayerUtil {
         hasReachedTheEndOfTheCalendar = true;
       }
 
+      /*
+       * When the window end lands exactly on a handoff, the previous period
+       * already ended at `end` and this period starts 1 s after it, so the
+       * clamp above leaves an inverted [end + 1s, end] slice. Emitting it
+       * handed direct getEvents callers (the layer shift preview, the calendar
+       * feed coverage envelope) a negative-length event for the next user.
+       * It is the final period, so stopping here changes nothing else.
+       */
+      if (OneUptimeDate.isAfter(currentEventStartTime, currentEventEndTime)) {
+        break;
+      }
+
       // check restriction times. if the end time of the event is after the end time of the restriction times, we need to update the end time of the event.
 
       const trimmedStartAndEndTimes: Array<StartAndEndTime> =

package/Types/Rules/RuleCriteria.ts

@@ -0,0 +1,51 @@
+import FilterCondition from "../Filter/FilterCondition";
+
+type RuleCriteriaSchemaVersion = 1;
+
+export const RULE_CRITERIA_SCHEMA_VERSION: RuleCriteriaSchemaVersion =
+  1 as const;
+
+/** A legacy regular expression that can never match any resource value. */
+export const RULE_CRITERIA_LEGACY_NEVER_MATCH_PATTERN: string = "(?!)";
+
+export enum RuleCriteriaOperator {
+  Equals = "Equals",
+  NotEquals = "NotEquals",
+  Contains = "Contains",
+  DoesNotContain = "DoesNotContain",
+  StartsWith = "StartsWith",
+  EndsWith = "EndsWith",
+  MatchesPattern = "MatchesPattern",
+  DoesNotMatchPattern = "DoesNotMatchPattern",
+  HasAnyOf = "HasAnyOf",
+  HasAllOf = "HasAllOf",
+  HasNoneOf = "HasNoneOf",
+}
+
+export type RuleCriteriaValue = string | number | boolean | Array<string>;
+
+export interface RuleCriteriaFilter {
+  field: string;
+  operator: RuleCriteriaOperator;
+  value: RuleCriteriaValue;
+}
+
+/**
+ * Versioned, resource-agnostic criteria stored by rule models.
+ *
+ * Field allowlists and field-specific operator choices deliberately live with
+ * each rule form and engine. This shared type only describes how conditions
+ * are combined and serialized.
+ */
+export default interface RuleCriteria {
+  schemaVersion: typeof RULE_CRITERIA_SCHEMA_VERSION;
+  filterCondition: FilterCondition;
+  filters: Array<RuleCriteriaFilter>;
+
+  /**
+   * Logical state carried only for relation-only rules during rolling deploys.
+   * Their legacy `isEnabled` column is deliberately sent as false so an old
+   * API cannot create an enabled match-all rule after dropping `criteria`.
+   */
+  isEnabled?: boolean;
+}