@oneuptime/common 12.0.33 → 12.0.34

package/Types/Monitor/ServiceAlertTemplates.ts

@@ -105,16 +105,19 @@ export interface ServiceAlertTemplate {
 }
 
 /*
- * `EvaluateOverTimeType` names the window collapse, and its two members used
- * here do NOT mean what their names suggest — worth stating once, here, rather
- * than being rediscovered per template:
+ * `EvaluateOverTimeType` names the window collapse. The two members these
+ * templates use are worth stating once, here, rather than being rediscovered
+ * per template:
  *
  *   AnyValue  -> ANY bucket in the rolling window breaching is a breach.
  *                Right for spikes.
- *   AllValues -> EVERY bucket must breach. Right for sustained pressure, and
- *                what the comparators actually do for every member that is not
- *                `AnyValue` (they fall through to `.every()`; there is no
- *                averaging on this code path despite `Average` existing).
+ *   AllValues -> EVERY bucket must breach. Right for sustained pressure.
+ *
+ * The reducing members (`Average`, `Sum`, `MaximumValue`, `MunimumValue`) do
+ * now collapse the window to one sample before the comparison —
+ * `CompareCriteria.reduceWindow` — so they mean what they say. `AllValues` is
+ * still the right default here: a reduced window hides the shape, and a metric
+ * that spends half the window fine is not under sustained pressure.
  *
  * A window with no samples at all never reaches the comparator — the
  * evaluator's no-data guard returns "not breaching" under the default
@@ -129,6 +132,34 @@ export interface ServiceAlertTemplate {
  */
 const SUSTAINED: EvaluateOverTimeType = EvaluateOverTimeType.AllValues;
 
+/*
+ * The resource attribute that identifies ONE process of a service.
+ *
+ * Every metric template here except the two request-latency percentiles
+ * thresholds a property of a single process — a heap, an event loop, a
+ * goroutine count, a thread pool. Without a group-by the ClickHouse
+ * aggregation collapses every replica of the service into one number, so an
+ * `Avg` template on three replicas at 95/20/20 reads 45 and stays green while
+ * one of them OOM-kills, and a `Max` template fires on the worst replica with
+ * no way to say which. Grouping fixes both at once: the worker emits one
+ * series per instance and the alert carries that instance in `seriesLabels`,
+ * which `SeriesLabelDisplay` renders into the title and the description block.
+ *
+ * `service.instance.id` is OPTIONAL in the resource semantic conventions, and
+ * this degrades safely when it is absent: the query returns one series whose
+ * label value is the empty string (ClickHouse `attributes[k]` on a missing key
+ * yields ""), `MetricSeriesFingerprint.extractSeriesLabels` keeps the key so
+ * the fingerprint stays stable across evaluations, and
+ * `SeriesLabelDisplay.getDisplayLabels` drops empty values rather than
+ * rendering "Instance: ". A service that does not report it therefore gets
+ * exactly today's single-series behaviour, not silence.
+ *
+ * The `resource.` prefix is the one OtelMetricsIngestService stamps onto OTel
+ * resource attributes (`prefixKeysWithString: "resource"`), the same spelling
+ * KubernetesAlertTemplates uses for `resource.k8s.pod.name`.
+ */
+const PER_INSTANCE_GROUP_BY: Array<string> = ["resource.service.instance.id"];
+
 interface CountCriteriaArgs {
   args: ServiceAlertTemplateArgs;
   checkOn: CheckOn.SpanCount | CheckOn.ExceptionCount;
@@ -201,7 +232,17 @@ function buildCriteriaPair(data: {
         checkOn: data.checkOn,
         filterType: data.unhealthyFilterType,
         value: data.threshold,
-        metricMonitorOptions: metricMonitorOptions,
+        /*
+         * A copy per filter, not the shared object. `MetricMonitorCriteria`
+         * writes its `AnyValue` default straight back through this reference
+         * when `metricAggregationType` is unset, and the criteria form spreads
+         * and re-assigns it on edit — either of which, on a shared object,
+         * changes the healthy criteria as a side effect of touching the
+         * unhealthy one.
+         */
+        metricMonitorOptions: metricMonitorOptions
+          ? { ...metricMonitorOptions }
+          : undefined,
       },
     ],
     incidents: [
@@ -242,7 +283,10 @@ function buildCriteriaPair(data: {
         checkOn: data.checkOn,
         filterType: data.healthyFilterType,
         value: data.threshold,
-        metricMonitorOptions: metricMonitorOptions,
+        // A copy per filter — see the unhealthy filter above.
+        metricMonitorOptions: metricMonitorOptions
+          ? { ...metricMonitorOptions }
+          : undefined,
       },
     ],
     incidents: [],
@@ -316,6 +360,7 @@ function buildQueryConfig(data: {
   aggregationType: MetricsAggregationType;
   attributes?: Record<string, string> | undefined;
   legendUnit?: string | undefined;
+  groupByAttributeKeys?: Array<string> | undefined;
 }): MetricQueryConfigData {
   return {
     metricAliasData: {
@@ -332,6 +377,14 @@ function buildQueryConfig(data: {
         aggegationType: data.aggregationType,
         aggregateBy: {},
       },
+      /*
+       * Omitted entirely rather than written as [] when there is nothing to
+       * group by, so an ungrouped template serializes to exactly the shape it
+       * did before this parameter existed.
+       */
+      ...(data.groupByAttributeKeys && data.groupByAttributeKeys.length > 0
+        ? { groupByAttributeKeys: data.groupByAttributeKeys }
+        : {}),
     },
   };
 }
@@ -356,6 +409,13 @@ function buildMetricTemplate(data: {
   rollingTime?: RollingTime | undefined;
   unhealthyFilterType?: FilterType | undefined;
   healthyFilterType?: FilterType | undefined;
+  /*
+   * Defaults to per-instance. Pass `[]` only for a metric that is a property
+   * of the SERVICE rather than of one process — the request latency
+   * percentiles are the only two here, and grouping them would quietly change
+   * "the service's p95" into "some replica's p95", which is a different alert.
+   */
+  groupByAttributeKeys?: Array<string> | undefined;
   incidentDescription: string;
 }): ServiceAlertTemplate {
   return {
@@ -388,6 +448,8 @@ function buildMetricTemplate(data: {
               aggregationType: data.aggregationType,
               attributes: data.attributes,
               legendUnit: data.legendUnit,
+              groupByAttributeKeys:
+                data.groupByAttributeKeys || PER_INSTANCE_GROUP_BY,
             }),
           ],
           formulaConfigs: [],
@@ -443,6 +505,7 @@ function buildRatioTemplate(data: {
   denominatorAlias: string;
   resultAlias: string;
   thresholdPercent: number;
+  groupByAttributeKeys?: Array<string> | undefined;
   incidentDescription: string;
 }): ServiceAlertTemplate {
   return {
@@ -494,6 +557,18 @@ function buildRatioTemplate(data: {
               title: `${data.name} (used)`,
               aggregationType: MetricsAggregationType.Sum,
               attributes: data.numeratorAttributes,
+              /*
+               * The SAME key set on both queries. The worker splits every
+               * query on the UNION of their keys, so the split itself cannot
+               * go wrong from setting only one side — but
+               * `MetricMonitorCriteria.buildContext` reads
+               * `groupByAttributeKeys` off a SINGLE query config when it
+               * builds the alert's "Grouped By" root-cause block, and a
+               * one-sided setting renders that block empty for whichever side
+               * it read.
+               */
+              groupByAttributeKeys:
+                data.groupByAttributeKeys || PER_INSTANCE_GROUP_BY,
             }),
             buildQueryConfig({
               metricName: data.denominatorMetricName,
@@ -501,6 +576,8 @@ function buildRatioTemplate(data: {
               title: `${data.name} (limit)`,
               aggregationType: MetricsAggregationType.Sum,
               attributes: data.denominatorAttributes,
+              groupByAttributeKeys:
+                data.groupByAttributeKeys || PER_INSTANCE_GROUP_BY,
             }),
           ],
           formulaConfigs: [formulaConfig],
@@ -760,6 +837,14 @@ const latencyP95Template: ServiceAlertTemplate = buildMetricTemplate({
   metricAlias: "service_latency_p95",
   aggregationType: MetricsAggregationType.P95,
   legendUnit: "ms",
+  /*
+   * Not grouped, unlike every other metric template here. A request latency
+   * percentile is a property of the SERVICE — it is the number the SLO is
+   * written against — and splitting it per instance would turn "the service's
+   * p95 is above a second" into "one replica's p95 is above a second", which
+   * fires on a single slow pod and means something else.
+   */
+  groupByAttributeKeys: [],
   threshold: 1000,
   thresholdLabel: "1,000 ms",
   incidentDescription:
@@ -777,6 +862,8 @@ const latencyP99Template: ServiceAlertTemplate = buildMetricTemplate({
   metricAlias: "service_latency_p99",
   aggregationType: MetricsAggregationType.P99,
   legendUnit: "ms",
+  // Service-level, not per instance — see latencyP95Template.
+  groupByAttributeKeys: [],
   threshold: 2500,
   thresholdLabel: "2,500 ms",
   incidentDescription:
@@ -1147,7 +1234,7 @@ const pythonTemplates: Array<ServiceAlertTemplate> = [
     id: "service-python-rss-memory",
     name: "Resident Memory High",
     description:
-      "Alert when resident memory stays above 1 GB per worker — the signal that precedes an OOM kill. Needs the system-metrics instrumentation enabled.",
+      "Alert when a worker's resident memory stays above 1 GB — the signal that precedes an OOM kill. Needs the system-metrics instrumentation enabled. Reads process.runtime.cpython.memory with type=rss; newer opentelemetry-python releases report this as process.memory.usage, which the language-agnostic Process Memory High template already covers.",
     category: "Python Runtime",
     severity: "Warning",
     language: "python",
@@ -1166,7 +1253,7 @@ const pythonTemplates: Array<ServiceAlertTemplate> = [
     id: "service-python-thread-growth",
     name: "Thread Count Growth",
     description:
-      "Alert when thread count stays above 200, which usually means a leaked executor or an unclosed client pool. Needs the system-metrics instrumentation enabled.",
+      "Alert when thread count stays above 200, which usually means a leaked executor or an unclosed client pool. Needs the system-metrics instrumentation enabled. Reads process.runtime.cpython.thread_count; newer opentelemetry-python releases report this as process.thread.count — retarget the created monitor in one edit if your SDK emits that instead.",
     category: "Python Runtime",
     severity: "Warning",
     language: "python",

package/Types/Monitor/UptimeHistoryLabels.ts

@@ -0,0 +1,56 @@
+/*
+ * Every string the day-by-day uptime history speaks: the accessible names on
+ * the strip itself, and the chrome of the dialog a day opens.
+ *
+ * These live in one interface, rather than one per component, because a
+ * caller who translates the strip must also translate the dialog it opens -
+ * splitting them is how you end up with a French status page whose bars
+ * announce themselves in French and whose dialog is in English.
+ *
+ * Every field has an English default (DefaultUptimeHistoryLabels), so the
+ * dashboard - which is English-only, like the tooltip next to it - passes
+ * nothing.
+ */
+export default interface UptimeHistoryLabels {
+  /* Names the strip. {{total}} is the number of days it covers. */
+  graphLabel: string;
+  /* A day with data. {{date}}, {{uptime}}. */
+  dayLabel: string;
+  /* A day with data and incidents. {{date}}, {{uptime}}, {{total}}. */
+  dayLabelWithIncidents: string;
+  /* A day with no timeline rows at all. {{date}}. */
+  dayLabelNoData: string;
+  /* No timeline rows, but incidents. {{date}}, {{total}}. */
+  dayLabelNoDataWithIncidents: string;
+
+  /* Dialog + tooltip body. */
+  uptime: string;
+  noMonitoringData: string;
+  incidents: string;
+  noIncidents: string;
+  noIncidentsDescription: string;
+  /* Dialog subtitle when the day carried exactly one incident. */
+  oneIncidentOnThisDay: string;
+  /* Dialog subtitle for two or more. {{total}}. */
+  incidentsOnThisDay: string;
+  /* Prefixes an incident's declaration time: "Declared Mar 03 2026, 14:12". */
+  declared: string;
+  close: string;
+}
+
+export const DefaultUptimeHistoryLabels: UptimeHistoryLabels = {
+  graphLabel: "Uptime history for the last {{total}} days",
+  dayLabel: "{{date}}: {{uptime}}% uptime",
+  dayLabelWithIncidents: "{{date}}: {{uptime}}% uptime, {{total}} incidents",
+  dayLabelNoData: "{{date}}: no data",
+  dayLabelNoDataWithIncidents: "{{date}}: no data, {{total}} incidents",
+  uptime: "Uptime",
+  noMonitoringData: "No monitoring data for this day",
+  incidents: "Incidents",
+  noIncidents: "No incidents",
+  noIncidentsDescription: "No incidents were reported on this day.",
+  oneIncidentOnThisDay: "1 incident reported on this day",
+  incidentsOnThisDay: "{{total}} incidents reported on this day",
+  declared: "Declared",
+  close: "Close",
+};

package/Types/NotificationSetting/RoutineEmailEvents.ts

@@ -0,0 +1,30 @@
+import NotificationSettingEventType from "./NotificationSettingEventType";
+
+/*
+ * Keep this an explicit allowlist: newly introduced events retain their existing
+ * email preference until someone deliberately classifies them as routine.
+ */
+export const ROUTINE_EMAIL_EVENT_TYPES: ReadonlyArray<NotificationSettingEventType> =
+  Object.freeze([
+    NotificationSettingEventType.SEND_INCIDENT_NOTE_POSTED_OWNER_NOTIFICATION,
+    NotificationSettingEventType.SEND_ALERT_NOTE_POSTED_OWNER_NOTIFICATION,
+    NotificationSettingEventType.SEND_INCIDENT_EPISODE_NOTE_POSTED_OWNER_NOTIFICATION,
+    NotificationSettingEventType.SEND_ALERT_EPISODE_NOTE_POSTED_OWNER_NOTIFICATION,
+    NotificationSettingEventType.SEND_SCHEDULED_MAINTENANCE_NOTE_POSTED_OWNER_NOTIFICATION,
+    NotificationSettingEventType.SEND_INCIDENT_OWNER_ADDED_NOTIFICATION,
+    NotificationSettingEventType.SEND_ALERT_OWNER_ADDED_NOTIFICATION,
+    NotificationSettingEventType.SEND_INCIDENT_EPISODE_OWNER_ADDED_NOTIFICATION,
+    NotificationSettingEventType.SEND_ALERT_EPISODE_OWNER_ADDED_NOTIFICATION,
+    NotificationSettingEventType.SEND_MONITOR_OWNER_ADDED_NOTIFICATION,
+    NotificationSettingEventType.SEND_SLO_OWNER_ADDED_NOTIFICATION,
+    NotificationSettingEventType.SEND_PROBE_OWNER_ADDED_NOTIFICATION,
+    NotificationSettingEventType.SEND_AI_AGENT_OWNER_ADDED_NOTIFICATION,
+    NotificationSettingEventType.SEND_STATUS_PAGE_OWNER_ADDED_NOTIFICATION,
+    NotificationSettingEventType.SEND_SCHEDULED_MAINTENANCE_OWNER_ADDED_NOTIFICATION,
+    NotificationSettingEventType.SEND_INCIDENT_ADDED_TO_EPISODE_OWNER_NOTIFICATION,
+    NotificationSettingEventType.SEND_ALERT_ADDED_TO_EPISODE_OWNER_NOTIFICATION,
+    NotificationSettingEventType.SEND_WHEN_USER_IS_ADDED_TO_ON_CALL_POLICY,
+    NotificationSettingEventType.SEND_WHEN_USER_IS_REMOVED_FROM_ON_CALL_POLICY,
+    NotificationSettingEventType.SEND_MONITOR_CREATED_OWNER_NOTIFICATION,
+    NotificationSettingEventType.SEND_STATUS_PAGE_CREATED_OWNER_NOTIFICATION,
+  ]);

package/Types/Rum/SessionReplay.ts

@@ -158,6 +158,111 @@ export const SESSION_REPLAY_ALLOWED_RETENTION_DAYS: Array<number> = [
  */
 export const DEFAULT_SESSION_REPLAY_RETENTION_IN_DAYS: number = 7;
 
+/*
+ * ---- Caps on host-page supplied strings (identify / setTags / track). ----
+ *
+ * Every one of these is enforced twice, on the client before the bytes
+ * leave the page and again at ingest, and the two sides MUST agree: a
+ * recorder that sends more than the server keeps produces silent
+ * truncation nobody can explain from the dashboard, and a server that
+ * keeps more than the recorder sends is a cap that protects nothing. The
+ * numbers are small on purpose. These maps ride on the header row of a
+ * ReplacingMergeTree that is rewritten by the finalizer, so every byte
+ * here is merge amplification, and they are rendered in list cells that
+ * have to stay one line.
+ */
+
+/* identify(ref, traits): the traits map. */
+export const SESSION_REPLAY_MAX_TRAIT_KEYS: number = 20;
+export const SESSION_REPLAY_MAX_TRAIT_KEY_LENGTH: number = 40;
+export const SESSION_REPLAY_MAX_TRAIT_VALUE_LENGTH: number = 200;
+
+/*
+ * setTags()/addTag(): tighter than traits because tags are indexed for the
+ * tag:key=value search and shown as pills, where a 200-character value is
+ * unreadable anyway.
+ */
+export const SESSION_REPLAY_MAX_TAG_KEYS: number = 20;
+export const SESSION_REPLAY_MAX_TAG_KEY_LENGTH: number = 32;
+export const SESSION_REPLAY_MAX_TAG_VALUE_LENGTH: number = 128;
+
+/*
+ * track(name, properties): a custom event's name is a rail row title, and
+ * its properties map shares the trait caps for key/value length.
+ */
+export const SESSION_REPLAY_MAX_CUSTOM_EVENT_NAME_LENGTH: number = 64;
+export const SESSION_REPLAY_MAX_CUSTOM_EVENT_PROPERTY_KEYS: number = 20;
+
+/*
+ * Per-CHUNK caps on the two custom-event kinds the host page can fire in a
+ * loop. Per chunk rather than per session so a long session keeps
+ * recording interactions after a busy minute; the recorder emits one
+ * "-dropped { count }" event per chunk once a cap is hit, so the player
+ * can say "212 clicks not labelled" instead of showing a quiet stretch.
+ */
+export const SESSION_REPLAY_MAX_CUSTOM_EVENTS_PER_CHUNK: number = 50;
+export const SESSION_REPLAY_MAX_CLICK_EVENTS_PER_CHUNK: number = 100;
+
+/*
+ * The visible text carried on a click event (aria-label, name or text
+ * content, after the active masking transform). Enough to read "Place
+ * order", short enough that a click on a paragraph cannot smuggle it.
+ */
+export const SESSION_REPLAY_MAX_CLICK_TEXT_LENGTH: number = 40;
+
+/* captureSession(reason): the reason becomes a custom event property. */
+export const SESSION_REPLAY_MAX_CAPTURE_REASON_LENGTH: number = 80;
+
+/*
+ * ---- Player-side activity model. ----
+ *
+ * A stretch with no user input for at least this long is an idle band on
+ * the timeline and a candidate for "skip idle". 5s is the smallest gap a
+ * viewer perceives as waiting rather than reading; shorter bands would
+ * turn every pause-to-read into a jump.
+ */
+export const SESSION_REPLAY_IDLE_THRESHOLD_MS: number = 5 * 1000;
+
+/*
+ * Coarse activity from the manifest alone: a chunk carrying fewer events
+ * than this is provisionally idle before it is decoded. A chunk always
+ * holds a handful of housekeeping events (meta, viewport, the flush
+ * checkout), so "3 or fewer" means nothing the user did reached it. The
+ * finalizer uses the same threshold to compute activeMs on the header, so
+ * the list's "idle 40%" and the timeline's hatched bands agree.
+ */
+export const SESSION_REPLAY_ACTIVE_CHUNK_MIN_EVENTS: number = 4;
+
+/*
+ * ---- List search. ----
+ *
+ * Free-text search runs as a case-insensitive substring match over several
+ * argMax'd header columns, which cannot use an index. The string cap keeps
+ * the predicate cheap; the window cap bounds how many partitions it may
+ * scan, and the handler answers "narrow the range" rather than timing out
+ * against a wider window.
+ */
+export const SESSION_REPLAY_LIST_SEARCH_MAX_LENGTH: number = 200;
+export const SESSION_REPLAY_LIST_SEARCH_MAX_WINDOW_DAYS: number = 30;
+
+/*
+ * Everything a current recorder build can capture beyond the rrweb DOM
+ * stream. The recorder sends the subset it implements on chunk 0
+ * (SessionReplayChunkEnvelope.capabilities); the player and the setup page
+ * compare a recording against this list to explain what an older cached
+ * artifact could not have captured, e.g. "click labels: no". Additive
+ * only: a value is never removed or renamed, because stored headers quote
+ * these strings.
+ */
+export const SESSION_REPLAY_RECORDER_CAPABILITIES: ReadonlyArray<string> = [
+  "click-events",
+  "web-vitals",
+  "custom-events",
+  "traits",
+  "tags",
+  "visibility",
+];
+
 /* How the payload bytes were compressed by the recorder. */
 export type SessionReplayPayloadEncoding = "gzip" | "identity";
 
@@ -197,6 +302,21 @@ export enum SessionReplayFidelityNotice {
    * may be noisier than the application's settings intend.
    */
   IgnorePatternsDiscarded = "ignore-patterns-discarded",
+  /*
+   * A per-session cap on recorded console lines, errors, network requests
+   * or route changes was reached, so later signals of that kind were not
+   * recorded. The footage itself is complete; only the rail is truncated
+   * past this point. The recorder emits an in-band cap marker too, so the
+   * rail can show WHERE the truncation started.
+   */
+  SignalCapReached = "signal-cap-reached",
+  /*
+   * rrweb threw inside the recorder's own emit path (its errorHandler
+   * swallowed it so the host page kept working) three or more times on
+   * this page. The recorder took a fresh checkout after the burst, so the
+   * footage recovers, but playback may skip or freeze around those points.
+   */
+  RecorderError = "recorder-error",
 }
 
 /* Why a session stopped accumulating chunks. */
@@ -227,6 +347,19 @@ export interface SessionReplaySignalCounts {
   errorClickCount: number;
   refreshRageCount: number;
   routeCount: number;
+
+  /*
+   * Engagement counters, optional because a recorder that predates them
+   * omits them and the server reads absence as 0. clickCount counts the
+   * oneuptime.click events the chunk carries (capped per chunk, see
+   * SESSION_REPLAY_MAX_CLICK_EVENTS_PER_CHUNK), customEventCount the
+   * oneuptime.custom events from the host page's track() calls. Both are
+   * summed into the session header by the finalizer like the others, and
+   * feed the list's "41 clicks" column and the player's activity lane
+   * before any chunk is decoded.
+   */
+  clickCount?: number;
+  customEventCount?: number;
 }
 
 /*
@@ -249,6 +382,27 @@ export interface SessionReplayChunkMeta {
    * explicitly enabled user-identity capture.
    */
   identifiedUserRef?: string;
+
+  /*
+   * Traits the host page attached to the identified user through
+   * identify(ref, traits): plan, role, tenant - never the reference itself.
+   * Already stringified, capped (SESSION_REPLAY_MAX_TRAIT_*) and masked on
+   * the client; the server re-caps and stores them ONLY when the
+   * application has user-identity capture on, in a column under the same
+   * narrow identity ACL as identifiedUserLabel. Absent from an older
+   * recorder, and absent whenever identify() was never called.
+   */
+  identifiedUserTraits?: Record<string, string>;
+
+  /*
+   * Per-session key/value tags from setTags()/addTag(): a build id, an
+   * experiment arm, a customer tier. Unlike traits these describe the
+   * session rather than the person, so they live under the ordinary
+   * session ACL and are searchable from the list (tag:key=value). Carried
+   * on whichever chunk carries meta so a tag set after chunk 0 still
+   * reaches the header.
+   */
+  tags?: Record<string, string>;
 }
 
 /*
@@ -346,6 +500,17 @@ export interface SessionReplayChunkEnvelope {
 
   /* Trace ids observed in this chunk's network events, for correlation. */
   traceIds?: Array<string>;
+
+  /*
+   * What this recorder build can capture, as a subset of
+   * SESSION_REPLAY_RECORDER_CAPABILITIES. Sent on chunk 0 only and purely
+   * informational: the server stores it on the header so the player can
+   * say "this recording predates click labels" instead of rendering an
+   * empty Interactions tab, and the setup page can tell a customer on a
+   * stale cached artifact which features their visitors' browsers are
+   * still missing. Never used to gate ingest.
+   */
+  capabilities?: Array<string>;
 }
 
 /*
@@ -388,6 +553,15 @@ export enum SessionReplayDisabledReason {
    * not match one, or a kill key is set.
    */
   NotEnabledForApplication = "not-enabled-for-application",
+
+  /*
+   * The project's daily byte budget or the application's monthly budget
+   * is already spent, so the recorder is told at config time not to
+   * record at all. Without this every new page load would record,
+   * compress and upload a chunk only to be refused. `disabledDetail`
+   * says which budget and `budgetResetsAt` when it clears.
+   */
+  BudgetExhausted = "budget-exhausted",
 }
 
 /*
@@ -486,6 +660,25 @@ export interface SessionReplayConfigResponse {
    */
   disabledReason?: SessionReplayDisabledReason;
 
+  /*
+   * Narrows disabledReason so the customer's console and the Dashboard's
+   * installation test can name the exact switch or budget: for
+   * NotEnabledForApplication one of project-not-allowed,
+   * application-not-enabled, application-unknown, project-killed; for
+   * BudgetExhausted one of project-daily-budget-exhausted,
+   * app-monthly-budget-exhausted. Free-form on purpose - the vocabulary
+   * belongs to the server's gate cache, and an older recorder just logs
+   * whatever string it receives.
+   */
+  disabledDetail?: string;
+
+  /*
+   * ISO timestamp of when a spent budget clears, set only alongside
+   * BudgetExhausted, so the recorder's diagnostics can say "resets at
+   * 00:00 UTC" instead of "disabled".
+   */
+  budgetResetsAt?: string;
+
   /*
    * Ask every recorder that reads this policy to print its decisions to
    * the browser console (SESSION_REPLAY_DEBUG on the deployment).
@@ -538,6 +731,22 @@ export interface SessionReplayChunkManifestEntry {
   errorClickCount: number;
   refreshRageCount: number;
   routeCount: number;
+
+  /*
+   * Optional because a manifest from a server that predates the column
+   * simply omits it, and the player must not draw "0 clicks" for a chunk
+   * that was never counted. Feeds the coarse activity heat on the timeline
+   * before the chunk is decoded.
+   */
+  clickCount?: number;
+
+  /*
+   * Scrubbed URL the chunk was flushed from (the chunk row's url column).
+   * Lets the stage's URL bar and the timeline preview name the page for a
+   * chunk that is not loaded yet; the exact navigation events take over
+   * once it is decoded.
+   */
+  url?: string;
 }
 
 /* A hole in the chunk sequence. Never crossed silently during playback. */