Generic webhook template doesn't identify which metric attribute/label combination (e.g. trace name) triggered the alert

My alert is on a dashboard tile with a single series: a metrics data source, a gauge aggregation, and a where clause — no groupBy is configured anywhere in the tile. Despite that, the chart renders multiple lines, because the underlying OTel metric carries multiple distinct attribute/label combinations (e.g. per trace/span name), and HyperDX implicitly plots one line per unique combination even though I never set an explicit group-by.

When the alert fires, the generic webhook body currently supports {{title}}, {{body}}, {{link}}, {{state}}, {{startTime}}, {{endTime}}, and {{eventId}}. None of these identify which underlying attribute combination (e.g. which trace name) actually crossed the threshold — the payload describes the alert's overall state and timing, but has no reference to the specific label values that produced the offending line.

This makes it impossible to route or triage generic webhook alerts without manually opening the dashboard and visually picking out which of the several implicit lines crossed the threshold. For downstream automation (custom incident routing, deduping, auto-annotating tickets, posting to the right team channel, etc.) this is a hard blocker — the alert is not attributable to a specific cause without a human eyeballing the chart.

Current behavior

• Dashboard tile: single series, metrics data source, gauge value, where clause. No groupBy configured.
• The metric itself has multiple attribute/label combinations (e.g. per-trace or per-span name), so the tile implicitly renders several lines even without an explicit group-by.
• Alert is attached to this tile/series.
• On firing, the generic webhook body supports {{title}}, {{body}}, {{link}}, {{state}}, {{startTime}}, {{endTime}}, and {{eventId}}.
• None of these resolve to the specific attribute/label combination (e.g. trace name) whose line crossed the threshold — {{link}} sends you to the tile, and the rest describe the alert's state/timing/ID, but none carry the identity of the offending line. You still have to visually inspect the chart to identify it.

Expected behavior

The webhook payload/template should include the specific attribute/label combination that breached the threshold for that firing — e.g. a {{seriesLabels}} or {{attributeValue}} (name TBD) template variable, populated with the trace name / span name / other metric attribute value that produced the crossing line.

This is closely related to (and possibly the same underlying gap as) groupBy-based alerts not surfacing the specific group value that fired — in both cases, the tile can implicitly or explicitly contain multiple lines, and the webhook has no way to say which one triggered.

Why this matters

Without this, generic webhook consumers (custom bots, incident routing via generic webhook, internal Slack bots, etc.) can only say "something on this metric tile crossed a threshold" — not "trace X crossed the threshold." For any metric with multiple attribute combinations feeding one tile, this makes the alert nearly useless for automated triage; a human has to click through and visually inspect the chart every time just to know what actually needs attention.

Suggested implementation

• Add a template variable (e.g. {{seriesLabels}}) available in the generic webhook body template, populated per-firing with the specific attribute/label combination (as key-value pairs) of the line that breached.
• Since a metric-source tile with no explicit groupBy can still implicitly fan out into many lines by attribute combination, consider either:
  • firing one webhook call per breaching attribute combination (each with its own labels), or
  • including an array of breaching attribute combinations in the payload if a single call is preferred.
• Apply the equivalent fix for explicit groupBy-based alerts (surface the specific group value that fired, not just the field being grouped on) — same underlying gap, different mechanism for producing multiple lines.
• Expose the same field on the External API v2 alert-history/evaluation response, if separate from the webhook payload, so it's fetchable after the fact too.

Environment

• Alert type: Dashboard tile alert (chart), single series, metrics data source, gauge aggregation, where clause, no groupBy configured
• Multiple alerts appear implicitly due to distinct attribute/label combinations in the underlying metric
• Notification channel: Generic Webhook

The issue does not name files or tests. Start by locating the generic webhook template handling, metric alert evaluation, and External API v2 alert-history paths; trace how implicit and explicit series labels reach a firing. Done means breaching attribute combinations are available in webhook templates and alert-history responses, with behavior defined for one or multiple webhook deliveries.