hyperdxio/hyperdx @hyperdx/api@2.37.0

on GitHub

Minor Changes

• 0558f77: Record and show which notification target an evaluation's delivery time went to. webhookDurationMs was a single number covering the whole delivery, and because targets are dispatched concurrently the slowest one sets it — so a multi-target alert reported a figure with no way to tell which webhook was responsible, or that the other targets were fine.

  Each dispatch is now timed individually and aggregated per target across the evaluation, since a grouped alert notifies the same target once per firing group and again on resolve. One entry per distinct target carries its webhook id, display name, summed duration, how many dispatches it took, and how many failed. The evaluation history's "Notification duration" cell expands in place to show the breakdown.

  Stored per evaluation rather than per dispatch: a 50-group alert notifying 10 targets would otherwise write 500 entries onto every history row. The array is capped at ALERT_NOTIFICATION_TARGETS_LIMIT and sorted slowest-first, so the cap drops the least interesting rows. Records written before this change keep rendering their total with nothing to expand.

• df4a7a5: Add a new inline alert source that persists its own chart config directly on the alert, so alerts no longer require a saved search (logs) or a dashboard tile (metrics). The config is the same shape a dashboard tile stores — builder configs on log/trace/metric sources plus raw SQL (Line/Stacked Bar/Number display types); PromQL is rejected. The internal alerts API accepts and returns the new source, and the check-alerts task evaluates inline alerts through the same code path as tile alerts (including group-by and multi-window behavior). Notifications for inline alerts link to the chart explorer seeded with the alert's config over the alerting window, and default their title to the config's name. Backend only — the creation/edit UI and external API v2 support land separately.

Patch Changes

• 3c81bb9: Build alert notifications for an alert's configured channels directly, instead of encoding them as @webhook-<id> mention strings and parsing them back out. That round-trip carried only type and webhookId, and it appended the channels after whatever the user wrote in the message body — so a body containing MAX_NOTIFICATIONS_PER_EVENT mentions consumed every slot of the per-event cap and the alert's own configured channel, the one target it was set up to notify, was silently never reached. Configured channels are now queued first and are exempt from that cap, which only ever meant to bound ad hoc mentions; channels is already bounded by MAX_ALERT_CHANNELS. Mentions written into the message body are unchanged, still capped, and still deduplicated against the configured channels so naming one twice notifies it once. This also removes the lossiness that prevented a channel from carrying any field beyond its webhook id through to delivery, which downstream forks with richer channel types (e.g. an email channel, or a Slack-app channel that also needs a Slack channel id) could not work around. getDefaultExternalActions is removed, as nothing needs the mention-string form of a configured channel any more.
• f11038e: feat: Persist variable-keyed dashboard filter value state
• 892cc65: feat(mcp): improve metric discovery, add quiet-saturation eval scenario
• b52a6fa: Advertise the MCP quantile level field as a string enum so Gemini-backed clients can use the server at all. z.union([z.literal(0.5), ...]) renders as { "type": "number", "enum": [0.5, 0.9, 0.95, 0.99] }, and Gemini's function declarations only accept enum alongside type: "string" — so a client that forwards MCP tool schemas to the provider had its entire tool list rejected because of this one field, surfacing as a generic "trouble connecting to the model provider" error that named neither the tool nor the property. Affected clickstack_timeseries, clickstack_table, clickstack_save_dashboard and clickstack_patch_dashboard. Only the advertised wire type changes: numeric input is still accepted for callers working from a cached schema, the value is coerced back to a number before any consumer sees it, and out-of-set values are still rejected. The external REST API's own level contract is untouched. A new test asserts that no advertised tool schema carries a non-string enum or an array-form items, complementing the draft-2020-12 metaschema check.
• 5fc3341: feat: Support dashboard variables in the MCP server
• Updated dependencies [0558f77]
• Updated dependencies [f11038e]
• Updated dependencies [df4a7a5]
• Updated dependencies [f9f7d5b]
• Updated dependencies [82852c3]
• Updated dependencies [de9038e]
• Updated dependencies [5fc3341]
• Updated dependencies [7662fae]
• Updated dependencies [93b51b1]
• Updated dependencies [64326d0]
  • @hyperdx/common-utils@0.28.0