alert-subscribe-copilot

Determine the business group with list_busi_groups, pick the notification outlet with list_notify_rules, then call create_alert_subscribe with a config containing severities and notify_rule_ids. The tool returns the rule ID and a URL linking to the edit page.

Set the for_duration field (in seconds) on a subscription rule so events are forwarded only after persisting longer than that threshold. The alert rule itself must have repeated notifications configured, otherwise the event never recurs for the escalation to match.

Check the matching gates in order: disabled flag, datasource_ids, prod, cate, AND'd tags, business group name match, for_duration versus elapsed alert time, and severities. If all pass, verify the downstream notification rule referenced by notify_rule_ids is correctly configured.

No. The original event follows its own notification path, and the subscription clones a copy that is forwarded additionally through the subscription's notify_rule_ids. The cloned event's callbacks are cleared by default to avoid re-hitting the original webhooks.

Only in the old version (notify_version=0) via redefine_severity and redefine_channels. Under notify_version=1, validation clears those fields, so severity and channel routing must be configured at the notification rule layer instead.

Changes take effect within at most 9 seconds because the in-memory subscription cache polls on a 9-second cycle. No restart of the Nightingale server is required after creating or updating a rule.