Table Health Dashboard & Alerting

The Table Health Dashboard gives you a real-time, table-centric view of your tables’ operational status directly in the StarTree Cloud Data Portal. Instead of digging through the cluster-wide Pinot admin console, you get a single grid of every table you manage, a pass/fail rollup per table, and one click to drill into exactly which checks are failing and why. Layered on top of the dashboard is Table Health Alerting: a per-recipient, per-check email subscription system. Instead of having to keep the dashboard open, you can subscribe yourself (or a distribution list) to email alerts whenever a check starts failing, keeps failing, or recovers — scoped as broadly as “every table, every check” or as narrowly as a single check on a single table.

​

Key features

• Per-table rollup: every table you have access to, with a Passing / N Failing summary and a Last Checked timestamp, sortable and filterable by health status.
• Drill-down detail: click into a table to see every check that runs against it, with a pass/fail chip, a human-readable description, and a read-only viewer for the raw diagnostic payload.
• One-click remediation: for checks that support it (and when you have permission), fix the underlying issue — trigger a segment rebalance or a segment reload — without leaving the page.
• Email alerting: subscribe any email address to failure/recovery notifications for all tables and checks, or fine-tune down to individual (table, check) pairs.
• Mute, don’t just disable: snooze a specific failing check’s alerts until it next passes, instead of permanently turning notifications off.
• Bulk controls: enable, disable, mute, or unmute alerts across an entire check type or an entire recipient’s subscriptions in one action.

​

Accessing the Table Health Dashboard

​

Reading the dashboard

The dashboard header shows two summary chips — Tables (total count) and Failing Tables (highlighted in red when non-zero) — plus a Last run indicator with a manual Refresh button so you don’t have to wait for the next automatic evaluation cycle. The grid itself has four columns: Use the Health column’s filter icon to narrow the grid to Passing, Failing, or No checks tables. If you haven’t created any tables yet, the dashboard shows an empty state with a Create table shortcut instead of a grid.

​

Table details page

Clicking a table name opens its detail page: an accordion list with one entry per health check that applies to that table, sorted failing-first (then alphabetically by check key). At the top of the page is a Recipient picker listing every subscribed recipient across all workspaces. The Email and Mute controls on each check act on whichever recipient is selected here, so the page shows an informational message and leaves those controls unavailable until at least one recipient has been subscribed. Opening the page from a digest email preselects the recipient the email was addressed to. Each accordion row shows:

• The check’s short label and its raw check key (for example, Segment Assignment / TABLE_SEGMENT_ASSIGNMENT_CHECK).
• A one-line description of what the check verifies.
• A passed / failed status chip.
• An Email: On/Off control — toggles this check’s email alerts for the currently selected recipient on this specific table (see Alerting below).
• For failing checks with email alerts on, a Mute/Unmute control to snooze that specific alert.

Expanding a row (failing checks auto-expand) reveals additional diagnostic detail returned by the check — for example, how many segments need to move, or which segments are affected. Simple values are shown inline; any nested field gets an eye icon that opens the raw JSON in a read-only viewer. Checks that return no extra detail show No additional details. Where a check supports it, one or more remediation buttons appear alongside this detail.

​

Remediating failing checks

Two of the table-level checks currently ship with one-click remediation, gated by RBAC permissions: Only a subset of the table-level checks Pinot runs is surfaced on the Table Health Dashboard, and that subset is set per environment. By default it is exactly the two remediable checks above — the other table-level checks (segment size, segment retention, segment availability, ingestion, column count, and more) are filtered out of the dashboard entirely rather than shown as pass/fail. Reach out to your StarTree Cloud team if you’d like additional checks surfaced; see Health checks for the full check catalog. For any check you see here — surfaced by default or enabled for your environment — the health check reference explains what it verifies, what the diagnostic fields in the expanded row mean, and what a failure asks of you.

​

Alerting: email notifications

Alerting is managed from the Notification Settings page — click the gear icon next to Last run on the dashboard, or next to the table title on any table’s detail page.

​

How subscriptions work

A recipient’s alert coverage is resolved from preference rows, each pairing them with a (workspace, table, check) tuple where the table and check may be a * wildcard:

• A wildcard subscription — “every table, every check” — created in each workspace the first time you subscribe a recipient.
• Concrete overrides — a specific (table, check) pair for that recipient.

For a given failing check, the most specific matching row wins and only that row’s settings apply — specificity runs exact (table, check) → (table, *) → (*, check) → (*, *). In practice the Data Portal writes only the two ends of that range: a wildcard row when you subscribe someone, and a concrete (table, check) row whenever you change an individual cell (including when a bulk action fans out across many cells). The partial-wildcard forms in between are accepted by the API for scripted setups. This lets you subscribe someone to everything and then carve out exceptions (for example, turn off a single noisy check on one table) without touching the rest of their subscriptions.

​

Subscribing a new recipient

​

Managing a recipient’s preferences

Once a recipient is selected in the picker, the page shows one collapsible section per health-check type (for example, Table Segment Assignment Check). Each section lists every (workspace, table) pair for that check, with its current Passing / Failing status and that recipient’s effective Email and Muted state. From here you can:

• Toggle Email for a single table/check cell, or flip the section header’s switch to enable/disable the check for every table at once.
• Mute or Unmute a single failing cell, or use the section’s Mute All / Unmute All to snooze every currently-failing, email-enabled row in that section.
• Use the page-level bulk actions — Enable Email for All, Disable Email for All, Mute All Failing, Unmute All — to act across the recipient’s entire subscription in one click.
• Click the trash icon next to the recipient picker to remove them entirely. After you confirm, this deletes their wildcard subscriptions and every override, unsubscribing them from all table-health alerts. This can’t be undone (they’d need to be re-subscribed from scratch).

​

What triggers an email

Alerting runs its own evaluation cycle, polling the cluster’s health state every 20 minutes by default. (That is independent of how often Pinot itself re-runs the checks, which the dashboard reflects directly.) For each subscribed (recipient, table, check), an alert is generated when:

• A check goes from passing to failing — an immediate “new failure” notification.
• A previously-failing check recovers — an immediate “recovery” notification.
• A check is still failing — it is always listed alongside any new failure or recovery in the same email. On its own, with nothing else to report, it becomes a reminder sent at most once every 24 hours by default, so you aren’t paged repeatedly for a known, ongoing issue. Any new-failure or recovery email resets that 24-hour clock, so the standalone reminder is skipped on days you’ve already heard from us.
• Nothing is sent on the first cycle after alerting starts — that run just records the current state, so subscribing doesn’t immediately blast you with the state of the world. Note this baseline is also reset if every recipient is unsubscribed; after that gap, the next cycle with a subscriber starts clean again. Once a baseline exists, a check that appears for the first time already failing does alert straight away.

Each recipient gets at most one digest email per evaluation cycle, covering all of their workspaces in a single message — every table is labelled with the workspace that owns it. Within the email, new failures, still failing, and recovered checks are grouped into separate sections, each listing up to 5 affected tables (ordered by failing-check count) with a “+N more” note for the rest. The email links back to the Table Health Dashboard and to the specific failing table’s detail page, so you can jump straight from your inbox to the fix.

​

Permissions required

The entire Monitoring section — the dashboard, table detail pages, and Notification Settings — requires Pinot Admin access in the Data Portal (the PinotAdminSystemAdmin app permission), and the health APIs behind it check the Pinot RBAC GetHealth action. Triggering remediation additionally requires cluster-level UpdateClusterConfig write access, as described above.

​

Related

• Health check reference — per-check detail: what each check verifies, its threshold, the diagnostic fields it returns, and what to do about a failure.
• Health checks — the Cluster Health view and the full catalog: table-, instance-, and cluster-level checks, with per-check detail. Table Health surfaces a table-scoped subset of the same checks with a friendlier, per-table workflow plus alerting.
• RBAC Actions — reference for GetHealth, UpdateClusterConfig, and the other Pinot permission actions referenced above.
• Troubleshooting — what to do once a check is failing: diagnostic paths for query failures, ingestion problems, and resource pressure.