@oneuptime/common 13.0.8 → 14.0.1

package/UI/Components/Feed/useFeedItems.ts

@@ -25,6 +25,14 @@ export interface FeedPage<TFeedModel> {
 
 export interface UseFeedItemsProps<TFeedModel> {
   resourceKey: string;
+  /*
+   * What the reader has chosen to see of this resource's feed - its sort
+   * order and event type filter (see useFeedOptions). A change re-reads the
+   * feed from its first window, exactly like moving to another resource:
+   * rows already loaded were read for the old view, so keeping them, or the
+   * size of the window they filled, would mix two different feeds.
+   */
+  viewKey?: string | undefined;
   refreshToken?: number | undefined;
   getItems: (limit: number) => Promise<FeedPage<TFeedModel>>;
   mapItems: (items: Array<TFeedModel>) => Array<FeedItemProps>;
@@ -50,7 +58,8 @@ interface FetchOptions {
 
 /*
  * Every dashboard activity feed follows the same paging contract: read the
- * newest top N rows and replace that window when the reader asks for more.
+ * first N rows in the reader's chosen order (newest first unless they asked
+ * for oldest first) and replace that window when the reader asks for more.
  * Re-reading from zero matters for a live feed. Offset-appending can duplicate
  * or skip a row when a new event arrives between page requests.
  */
@@ -71,10 +80,20 @@ const useFeedItems: <TFeedModel>(
     null,
   );
 
-  const activeResourceKeyRef: MutableRefObject<string> = useRef<string>(
-    props.resourceKey,
-  );
-  activeResourceKeyRef.current = props.resourceKey;
+  /*
+   * The resource and the view together name the feed being shown. Everything
+   * below that guards against a stale response or resets the window keys on
+   * this, so a response for the previous view is dropped the same way as a
+   * response for the previous resource.
+   */
+  const feedKey: string =
+    props.viewKey === undefined
+      ? props.resourceKey
+      : `${props.resourceKey}\u0000${props.viewKey}`;
+
+  const activeResourceKeyRef: MutableRefObject<string> =
+    useRef<string>(feedKey);
+  activeResourceKeyRef.current = feedKey;
   const previousResourceKeyRef: MutableRefObject<string | null> = useRef<
     string | null
   >(null);
@@ -184,8 +203,8 @@ const useFeedItems: <TFeedModel>(
 
   useEffect(() => {
     const hasResourceChanged: boolean =
-      previousResourceKeyRef.current !== props.resourceKey;
-    previousResourceKeyRef.current = props.resourceKey;
+      previousResourceKeyRef.current !== feedKey;
+    previousResourceKeyRef.current = feedKey;
 
     if (hasResourceChanged) {
       currentLimitRef.current = DEFAULT_LIMIT;
@@ -200,7 +219,7 @@ const useFeedItems: <TFeedModel>(
     }).catch(() => {
       // fetchItems converts request failures into the appropriate UI state.
     });
-  }, [fetchItems, props.resourceKey, props.refreshToken]);
+  }, [fetchItems, feedKey, props.refreshToken]);
 
   useEffect(() => {
     return () => {
@@ -208,7 +227,7 @@ const useFeedItems: <TFeedModel>(
     };
   }, []);
 
-  const isCurrentFeedLoaded: boolean = loadedResourceKey === props.resourceKey;
+  const isCurrentFeedLoaded: boolean = loadedResourceKey === feedKey;
 
   return {
     feedItems,

package/UI/Components/Feed/useFeedOptions.ts

@@ -0,0 +1,225 @@
+import {
+  MutableRefObject,
+  useCallback,
+  useEffect,
+  useMemo,
+  useRef,
+  useState,
+} from "react";
+import SortOrder from "../../../Types/BaseDatabase/SortOrder";
+import LocalStorage from "../../Utils/LocalStorage";
+import {
+  DEFAULT_FEED_SORT_ORDER,
+  FeedEventTypeOption,
+  FeedOptions,
+  GetFeedEventTypeIconFunction,
+  GetFeedEventTypeLabelFunction,
+  getFeedEventTypeOptions,
+  getFeedOptionsKey,
+  isFeedFiltered,
+  isFeedSortOrder,
+  sanitizeFeedEventTypes,
+} from "./FeedOptions";
+
+export interface UseFeedOptionsProps {
+  // Every event type the feed model can record, e.g. Object.values(the enum).
+  eventTypes: Array<string>;
+  getEventTypeLabel?: GetFeedEventTypeLabelFunction | undefined;
+  getEventTypeIcon?: GetFeedEventTypeIconFunction | undefined;
+  /*
+   * Names this kind of feed ("incident", "monitor", ...) so the reader's sort
+   * order is remembered across pages and visits. The event type filter is
+   * deliberately not remembered: it narrows one investigation, and a filter
+   * that silently followed the reader to the next incident would read as a
+   * feed with missing events.
+   */
+  storageKey?: string | undefined;
+  /*
+   * The resource whose feed this is (the incident id, the cluster id, ...).
+   * The dashboard moves between resources without remounting the feed, and
+   * the event type filter belongs to the resource it was chosen on, so a new
+   * resource starts unfiltered. The sort order is a preference and stays.
+   */
+  resetKey?: string | undefined;
+}
+
+export interface UseFeedOptionsResult {
+  options: FeedOptions;
+  // Pass to useFeedItems as viewKey: a change re-reads the feed.
+  optionsKey: string;
+  eventTypeOptions: Array<FeedEventTypeOption>;
+  isFiltered: boolean;
+  setOptions: (options: FeedOptions) => void;
+}
+
+const SORT_ORDER_STORAGE_KEY_PREFIX: string = "feed-sort-order:";
+
+// One shared empty selection, so an unfiltered render keeps its identity.
+const NO_EVENT_TYPES: Array<string> = [];
+
+type GetSortOrderStorageKey = (storageKey: string) => string;
+
+export const getSortOrderStorageKey: GetSortOrderStorageKey = (
+  storageKey: string,
+): string => {
+  return `${SORT_ORDER_STORAGE_KEY_PREFIX}${storageKey}`;
+};
+
+type ReadStoredSortOrder = (storageKey: string | undefined) => SortOrder;
+
+/*
+ * Storage can be missing, blocked or hold anything, so every read falls back
+ * to the default order.
+ */
+const readStoredSortOrder: ReadStoredSortOrder = (
+  storageKey: string | undefined,
+): SortOrder => {
+  if (!storageKey) {
+    return DEFAULT_FEED_SORT_ORDER;
+  }
+
+  try {
+    const storedValue: unknown = LocalStorage.getItem(
+      getSortOrderStorageKey(storageKey),
+    );
+
+    return isFeedSortOrder(storedValue) ? storedValue : DEFAULT_FEED_SORT_ORDER;
+  } catch {
+    return DEFAULT_FEED_SORT_ORDER;
+  }
+};
+
+type WriteStoredSortOrder = (
+  storageKey: string | undefined,
+  sortOrder: SortOrder,
+) => void;
+
+const writeStoredSortOrder: WriteStoredSortOrder = (
+  storageKey: string | undefined,
+  sortOrder: SortOrder,
+): void => {
+  if (!storageKey) {
+    return;
+  }
+
+  try {
+    if (sortOrder === DEFAULT_FEED_SORT_ORDER) {
+      LocalStorage.removeItem(getSortOrderStorageKey(storageKey));
+    } else {
+      LocalStorage.setItem(getSortOrderStorageKey(storageKey), sortOrder);
+    }
+  } catch {
+    // A preference that cannot be saved still applies to this page.
+  }
+};
+
+const useFeedOptions: (props: UseFeedOptionsProps) => UseFeedOptionsResult = (
+  props: UseFeedOptionsProps,
+): UseFeedOptionsResult => {
+  /*
+   * Callers pass Object.values(SomeEnum), a new array on every render, so the
+   * list is keyed by its contents.
+   */
+  const eventTypesKey: string = props.eventTypes.join("\u0000");
+  const knownEventTypes: Array<string> = useMemo(() => {
+    return props.eventTypes;
+  }, [eventTypesKey]);
+
+  const [sortOrder, setSortOrder] = useState<SortOrder>(() => {
+    return readStoredSortOrder(props.storageKey);
+  });
+  /*
+   * The selection remembers which resource it was made on. It is read through
+   * that, during render rather than in an effect, so the first render for a
+   * new resource is already unfiltered and never asks the API for the old
+   * resource's filter. The stale selection is also dropped (React's "adjust
+   * state when a prop changes" pattern), so going back to the first resource
+   * does not bring its old filter back either.
+   */
+  const [selection, setSelection] = useState<{
+    resetKey: string | undefined;
+    eventTypes: Array<string>;
+  }>(() => {
+    return {
+      resetKey: props.resetKey,
+      eventTypes: [],
+    };
+  });
+  const isSelectionForThisResource: boolean =
+    selection.resetKey === props.resetKey;
+
+  if (!isSelectionForThisResource) {
+    setSelection({
+      resetKey: props.resetKey,
+      eventTypes: NO_EVENT_TYPES,
+    });
+  }
+
+  const selectedEventTypes: Array<string> = isSelectionForThisResource
+    ? selection.eventTypes
+    : NO_EVENT_TYPES;
+
+  const options: FeedOptions = useMemo(() => {
+    return {
+      sortOrder,
+      eventTypes: sanitizeFeedEventTypes({
+        selectedEventTypes,
+        knownEventTypes,
+      }),
+    };
+  }, [sortOrder, selectedEventTypes, knownEventTypes]);
+
+  const eventTypeOptions: Array<FeedEventTypeOption> = useMemo(() => {
+    return getFeedEventTypeOptions({
+      eventTypes: knownEventTypes,
+      getEventTypeLabel: props.getEventTypeLabel,
+      getEventTypeIcon: props.getEventTypeIcon,
+    });
+  }, [knownEventTypes, props.getEventTypeLabel, props.getEventTypeIcon]);
+
+  const setOptions: (nextOptions: FeedOptions) => void = useCallback(
+    (nextOptions: FeedOptions): void => {
+      const nextSortOrder: SortOrder = isFeedSortOrder(nextOptions.sortOrder)
+        ? nextOptions.sortOrder
+        : DEFAULT_FEED_SORT_ORDER;
+
+      setSortOrder(nextSortOrder);
+      setSelection({
+        resetKey: props.resetKey,
+        eventTypes: sanitizeFeedEventTypes({
+          selectedEventTypes: nextOptions.eventTypes,
+          knownEventTypes,
+        }),
+      });
+    },
+    [knownEventTypes, props.resetKey],
+  );
+
+  /*
+   * The stored order follows the committed state, not each setOptions call:
+   * two changes batched into one render would otherwise leave storage holding
+   * the first while the page shows the second. The first run is the value
+   * just read from storage, so there is nothing to write.
+   */
+  const hasCommittedSortOrderRef: MutableRefObject<boolean> =
+    useRef<boolean>(false);
+
+  useEffect(() => {
+    if (!hasCommittedSortOrderRef.current) {
+      hasCommittedSortOrderRef.current = true;
+      return;
+    }
+
+    writeStoredSortOrder(props.storageKey, sortOrder);
+  }, [sortOrder]);
+
+  return {
+    options,
+    optionsKey: getFeedOptionsKey(options),
+    eventTypeOptions,
+    isFiltered: isFeedFiltered(options),
+    setOptions,
+  };
+};
+
+export default useFeedOptions;

package/UI/Components/Graphs/DayUptimeGraph.tsx

@@ -39,10 +39,52 @@ export interface UptimeBarDaySummary {
   incidents: Array<UptimeBarTooltipIncident>;
 }
 
+/*
+ * One day's reading, measured server-side.
+ *
+ * The bars used to be derived purely from the timeline rows the browser
+ * happened to receive, and those rows arrive under a cap that silently drops
+ * history (see MonitorStatusTimelineService.getDailyUptimeAggregate). A day
+ * whose rows were dropped is indistinguishable, client-side, from a day that
+ * was genuinely quiet - so the graph painted both as the status page's
+ * `defaultBarColor`, which is GREEN on the overwhelming majority of pages.
+ * The page then asserted uptime for periods it had no data for.
+ *
+ * A reading carries how much of the day was actually COVERED by data, which
+ * is the thing the browser cannot infer for itself.
+ */
+export interface DayReading {
+  dayStart: Date;
+  daySeconds: number;
+  /* Zero means nothing was ever recorded for this day. */
+  coveredSeconds: number;
+  statusDurations: Array<StatusDuration>;
+}
+
+/*
+ * A day nobody measured is not a colour the operator gets to choose.
+ *
+ * `defaultBarColor` is branding for an ordinary good day; letting it also
+ * stand for "we have no idea" is exactly the conflation that made a page with
+ * a green default claim uptime it never recorded, and a page with a grey
+ * default look unmonitored while it was passing every check. This is a fixed
+ * neutral, drawn with a hatch so it is still distinguishable in greyscale and
+ * to a colour-blind reader.
+ */
+export const NO_DATA_BAR_COLOR: Color = new Color("#9CA3AF");
+
 export interface ComponentProps {
   startDate: Date;
   endDate: Date;
   events: Array<Event>;
+  /*
+   * Server-measured coverage per day. When a day has a reading, it decides
+   * whether that day has data and what its durations are; the `events` array
+   * is then only used for incident overlays. When absent - the dashboard
+   * monitor page, which does not fetch the aggregate - the old event-derived
+   * behaviour applies unchanged.
+   */
+  dayReadings?: Array<DayReading> | undefined;
   height?: number | undefined;
   barColorRules?: Array<BarChartRule> | undefined;
   downtimeEventStatusIds?: Array<ObjectID> | undefined;
@@ -173,6 +215,20 @@ const DayUptimeGraph: FunctionComponent<ComponentProps> = (
     const startOfTheDay: Date = OneUptimeDate.getStartOfDay(todaysDay);
     const endOfTheDay: Date = OneUptimeDate.getEndOfDay(todaysDay);
 
+    /*
+     * The server's reading for this day, when the caller supplied one. It is
+     * matched by instant rather than by index: the window's first bucket is
+     * clipped to the window start, so bucket i is not necessarily day i.
+     */
+    const todaysReading: DayReading | undefined = (
+      props.dayReadings || []
+    ).find((reading: DayReading) => {
+      return (
+        reading.dayStart.getTime() >= startOfTheDay.getTime() &&
+        reading.dayStart.getTime() <= endOfTheDay.getTime()
+      );
+    });
+
     const todaysEvents: Array<Event> = props.events.filter((event: Event) => {
       let doesEventBelongsToToday: boolean = false;
 
@@ -274,32 +330,75 @@ const DayUptimeGraph: FunctionComponent<ComponentProps> = (
       }
     }
 
+    /*
+     * Does this day have data at all?
+     *
+     * With a server reading, coverage is the answer and it is authoritative -
+     * the browser cannot tell a quiet day from a day whose rows were dropped
+     * by the fetch cap. Without one, fall back to the old test.
+     */
+    const hasDataForTheDay: boolean = todaysReading
+      ? todaysReading.coveredSeconds > 0
+      : todaysEvents.length > 0;
+
     // now check bar rules and finalize the color of the bar
 
-    const uptimePercentForTheDay: number =
-      totalUptimeInSeconds + totalDowntimeInSeconds > 0
+    /*
+     * The denominator is what was MEASURED, not the length of the day. A day
+     * only half covered - the day a monitor was created - reports the
+     * percentage of the half we watched rather than being marked down for the
+     * hours nobody was looking.
+     *
+     * The old expression ended in `: 100`, which said "no readings at all
+     * means a perfect day". That is the single line that let a status page
+     * assert uptime for a period it had no data for, so it is gone rather
+     * than adjusted: with no data there is no percentage.
+     */
+    const uptimePercentForTheDay: number = !hasDataForTheDay
+      ? 0
+      : totalUptimeInSeconds + totalDowntimeInSeconds > 0
         ? (totalUptimeInSeconds /
             (totalDowntimeInSeconds + totalUptimeInSeconds)) *
           100
         : 100;
 
-    for (const rules of props.barColorRules || []) {
-      if (uptimePercentForTheDay >= rules.uptimePercentGreaterThanOrEqualTo) {
-        color = rules.barColor;
-        break;
+    /*
+     * Rules are skipped entirely on a day with no data. Otherwise a page
+     * configuring ">= 99% is green" would have that rule matched by a day
+     * nobody measured, which is the very claim this change removes. No-data
+     * outranks operator rules on purpose.
+     */
+    if (hasDataForTheDay) {
+      for (const rules of props.barColorRules || []) {
+        if (uptimePercentForTheDay >= rules.uptimePercentGreaterThanOrEqualTo) {
+          color = rules.barColor;
+          break;
+        }
       }
     }
 
-    if (todaysEvents.length === 1 && !hasEvents) {
+    if (todaysEvents.length >= 1) {
       hasEvents = true;
     }
 
-    if (todaysEvents.length === 1) {
-      hasEvents = true;
-    }
+    /*
+     * THE FIX.
+     *
+     * This used to read: no events today, so paint `defaultBarColor`. That
+     * single line is how a status page claimed uptime for days it had no data
+     * for - `defaultBarColor` is green on the overwhelming majority of pages,
+     * and "no events" was true both for a quiet day and for a day whose rows
+     * the fetch cap had thrown away.
+     *
+     * Now the two are separated. A day with data but no events of its own is
+     * an ordinary good day and still gets the operator's colour. A day with
+     * no data gets the fixed no-data treatment and says so.
+     */
+    hasEvents = hasDataForTheDay;
 
-    if (todaysEvents.length === 0) {
-      hasEvents = false;
+    if (!hasDataForTheDay) {
+      color = NO_DATA_BAR_COLOR;
+    } else if (todaysEvents.length === 0) {
       color = props.defaultBarColor || Green;
     }
 
@@ -315,9 +414,18 @@ const DayUptimeGraph: FunctionComponent<ComponentProps> = (
       className = "w-20 h-" + props.height;
     }
 
-    // Build status durations for tooltip
-    const statusDurations: Array<StatusDuration> = [];
-    for (const key in secondsOfEvent) {
+    /*
+     * Build status durations for the tooltip and the day dialog.
+     *
+     * A server reading wins: its durations are measured over the whole day
+     * server-side, while `secondsOfEvent` can only describe the rows this
+     * browser happened to receive.
+     */
+    const statusDurations: Array<StatusDuration> = todaysReading
+      ? todaysReading.statusDurations
+      : [];
+
+    for (const key in todaysReading ? {} : secondsOfEvent) {
       statusDurations.push({
         label: eventLabels[key] || "Unknown",
         seconds: secondsOfEvent[key] || 0,

package/UI/Components/Icon/Icon.tsx

@@ -800,7 +800,7 @@ const Icon: FunctionComponent<ComponentProps> = ({
       <path
         strokeLinecap="round"
         strokeLinejoin="round"
-        d="M3 4.5h14.25M3 9h9.75M3 13.5h9.75m4.5-4.5v12m0 0l-3.75-3.75M17.25 21L21 17.25"
+        d="M3 4.5h14.25M3 9h9.75M3 13.5h5.25m5.25-.75L17.25 9m0 0L21 12.75M17.25 9v12"
       />,
     );
   } else if (icon === IconProp.CheckCircle) {

package/UI/Components/ModelList/ModelList.tsx

@@ -37,6 +37,13 @@ export interface ComponentProps<TBaseModel extends BaseModel> {
   fetchRequestOptions?: RequestOptions | undefined;
   customElement?: ((item: TBaseModel) => ReactElement) | undefined;
   noItemsMessage: string;
+  /*
+   * Render nothing, rather than noItemsMessage (or its "No items found."
+   * fallback), when the list loads empty. For a caller that explains an empty
+   * list itself, e.g. from onListLoaded. A search that matches nothing still
+   * says so.
+   */
+  hideEmptyState?: boolean | undefined;
   headerField?: string | ((item: TBaseModel) => ReactElement) | undefined;
   onSelectChange?: ((list: Array<TBaseModel>) => void) | undefined;
   refreshToggle?: string | undefined;
@@ -260,7 +267,10 @@ const ModelList: <TBaseModel extends BaseModel>(
         {error ? <ErrorMessage message={error} /> : <></>}
         {isLoading ? <ComponentLoader /> : <></>}
 
-        {!isLoading && !error && searchedList.length === 0 ? (
+        {!isLoading &&
+        !error &&
+        searchedList.length === 0 &&
+        (Boolean(searchText) || !props.hideEmptyState) ? (
           <ErrorMessage
             message={
               searchText

package/UI/Components/MonitorGraphs/Uptime.tsx

@@ -2,9 +2,16 @@ import ComponentLoader from "../ComponentLoader/ComponentLoader";
 import ErrorMessage from "../ErrorMessage/ErrorMessage";
 import DayUptimeGraph, {
   BarChartRule,
+  DayReading,
   Event,
   UptimeBarDaySummary,
 } from "../Graphs/DayUptimeGraph";
+import { StatusDuration } from "../Graphs/UptimeDaySummary";
+import Dictionary from "../../../Types/Dictionary";
+import {
+  UptimeDayBucket,
+  UptimeStatusDuration,
+} from "../../../Types/StatusPage/UptimeDailyAggregate";
 import UptimeUtil from "./UptimeUtil";
 import Color from "../../../Types/Color";
 import CommonMonitorEvent from "../../../Utils/Uptime/MonitorEvent";
@@ -27,6 +34,17 @@ export interface ComponentProps {
   height?: number | undefined;
   barColorRules?: Array<StatusPageHistoryChartBarColorRule> | undefined;
   downtimeMonitorStatuses: Array<MonitorStatus> | undefined;
+  /*
+   * Server-measured per-day coverage for THIS monitor.
+   *
+   * The `items` array above arrives under a fetch cap that silently drops
+   * history, so it cannot answer "did we have data for this day". These
+   * buckets can. When absent the graph keeps its old event-derived
+   * behaviour, which is what the dashboard monitor page still uses.
+   */
+  uptimeBuckets?: Array<UptimeDayBucket> | undefined;
+  /* Statuses by id, so a bucket's durations can be given a name and colour. */
+  monitorStatuses?: Array<MonitorStatus> | undefined;
   defaultBarColor: Color;
   incidents?: Array<UptimeBarTooltipIncident> | undefined;
   onBarClick?: (
@@ -62,6 +80,56 @@ const MonitorUptimeGraph: FunctionComponent<ComponentProps> = (
     );
   }, [props.barColorRules]);
 
+  /*
+   * Turn the server's buckets into the graph's per-day readings, resolving
+   * each status id to the name and colour the page already knows.
+   */
+  const dayReadings: Array<DayReading> | undefined = useMemo(() => {
+    if (!props.uptimeBuckets) {
+      return undefined;
+    }
+
+    const statusById: Dictionary<MonitorStatus> = {};
+
+    for (const status of props.monitorStatuses || []) {
+      if (status.id) {
+        statusById[status.id.toString()] = status;
+      }
+    }
+
+    const downtimeIds: Array<string> = (
+      props.downtimeMonitorStatuses || []
+    ).map((status: MonitorStatus) => {
+      return status.id?.toString() || "";
+    });
+
+    return props.uptimeBuckets.map((bucket: UptimeDayBucket): DayReading => {
+      return {
+        dayStart: bucket.bucketStart,
+        daySeconds: bucket.daySeconds,
+        coveredSeconds: bucket.coveredSeconds,
+        statusDurations: bucket.statusDurations.map(
+          (duration: UptimeStatusDuration): StatusDuration => {
+            const statusId: string = duration.monitorStatusId.toString();
+            const status: MonitorStatus | undefined = statusById[statusId];
+
+            return {
+              label: status?.name || "Unknown",
+              seconds: duration.seconds,
+              color: status?.color || props.defaultBarColor,
+              isDowntime: downtimeIds.includes(statusId),
+            };
+          },
+        ),
+      };
+    });
+  }, [
+    props.uptimeBuckets,
+    props.monitorStatuses,
+    props.downtimeMonitorStatuses,
+    props.defaultBarColor,
+  ]);
+
   if (props.isLoading) {
     return <ComponentLoader />;
   }
@@ -80,6 +148,7 @@ const MonitorUptimeGraph: FunctionComponent<ComponentProps> = (
       startDate={props.startDate}
       endDate={props.endDate}
       events={events}
+      dayReadings={dayReadings}
       defaultBarColor={props.defaultBarColor}
       height={props.height}
       barColorRules={barColorRules}

package/UI/Components/TelemetryViewer/TelemetryViewer.tsx

@@ -33,6 +33,18 @@ export interface TelemetryViewerProps<T> {
   error?: string | undefined;
   onRefresh?: (() => void) | undefined;
   emptyMessage?: string | undefined;
+  /*
+   * Replaces the default "No results / try adjusting filters" block when the
+   * list comes back empty.
+   *
+   * For most signals the default is right: an empty list means the filters
+   * are too narrow. For a signal that a project may not be SENDING at all,
+   * it is usually wrong — the reader needs the setup guide, not an
+   * invitation to widen a time range over data that does not exist. Takes
+   * precedence over `emptyMessage`; nothing is rendered around it, so the
+   * caller owns the whole empty area.
+   */
+  emptyContent?: ReactNode;
 
   // -- Layout --
   /** Render one item row in the main list. */
@@ -296,18 +308,22 @@ function TelemetryViewerInner<T>(props: TelemetryViewerProps<T>): ReactElement {
                   <ComponentLoader />
                 </div>
               ) : props.items.length === 0 ? (
-                <div className="flex h-48 flex-col items-center justify-center gap-2 px-6 text-center">
-                  <Icon
-                    icon={IconProp.Search}
-                    className="h-8 w-8 text-gray-300"
-                  />
-                  <p className="text-sm font-medium text-gray-500">
-                    {props.emptyMessage || "No results"}
-                  </p>
-                  <p className="text-xs text-gray-400">
-                    Try adjusting filters or time range.
-                  </p>
-                </div>
+                props.emptyContent !== undefined ? (
+                  <>{props.emptyContent}</>
+                ) : (
+                  <div className="flex h-48 flex-col items-center justify-center gap-2 px-6 text-center">
+                    <Icon
+                      icon={IconProp.Search}
+                      className="h-8 w-8 text-gray-300"
+                    />
+                    <p className="text-sm font-medium text-gray-500">
+                      {props.emptyMessage || "No results"}
+                    </p>
+                    <p className="text-xs text-gray-400">
+                      Try adjusting filters or time range.
+                    </p>
+                  </div>
+                )
               ) : (
                 <ul className="divide-y divide-gray-100">
                   {props.items.map((item: T, index: number) => {