Full table of notify rule config fields

Data model models/notify_rule.go: NotifyRule + NotifyConfig[].

Basic fields

notify_configs (per route)

severity (alert level)

params (channel parameters)

The shape of params is determined by the chosen medium; the information different media require from the user differs completely. The three fields contact_key / custom_params / request_type returned by list_notify_channels are the basis for the decision — match them up:

The first two rows are not mutually exclusive: a user's custom channel may have both contact_key and custom_params non-empty, in which case custom_params decides whether the message is sent (required), while user_ids/user_group_ids only decide who to @ in the group (optional) — don't miss the token by matching only on the first row.

If information is missing, stop and ask the user — do not leave it blank or fabricate it — and when asking, attach the corresponding official doc from "Medium parameter quick lookup and doc links" below, telling the user where to obtain the value (e.g. "DingTalk group → group settings → smart group assistant → the string after access_token= in the bot Webhook URL").

User-recipient type (contact_key non-empty)

{ "user_ids": [1, 2, 3], "user_group_ids": [1, 2] }

• user_ids and user_group_ids are an OR relationship; the matched users are deduplicated and their contact methods are taken.
• Which specific contact field is taken (phone/email/dingtalk_userid…) is exactly contact_key — if that field is blank in the user's contact_info, it is silently not sent (the most common root cause of "test was OK but the real alert wasn't sent"); have the user confirm the recipient has filled in that field in the personal center / user management.

Custom-parameter type (custom_params non-empty)

The keys of params correspond one-to-one with the keys returned by custom_params, the values are all strings, supplied by the user. The built-in group-bot channels are all of this type:

{ "access_token": "xxxx", "bot_name": "Nightingale Alerts" }

• Whether the message is sent depends only on these parameters (e.g. whether the access_token is correct), unrelated to recipients; if the medium has a "contact method" configured (contact_key also non-empty), you can additionally add user_ids to decide who to @ in the group.
• token/key/url must come from the user; note parameters like bot_name / note are asked about in passing when requesting the token ("which group / what purpose is this bot, give me a note") — if the user does not provide one, do not press them and do not leave it blank, but auto-generate one from the notify rule's configuration (using the rule name / routing intent, e.g. "Nightingale Alerts - Core Service P1"); once there are many rules, without notes you can't tell which token maps to which group.
• Reuse already-filled values: use list_notify_rule_custom_params(notify_channel_id) to look up parameter values that other rules have filled in for this medium (grouped by value, with the names of the rules using them attached). When the user says "send to the same DingTalk group as rule X" or doesn't bring a token, check here first; if it matches, reuse it directly without making the user dig out the Webhook; if nothing is found or the user explicitly says it's a new group, ask the user for it.

Flashduty channel

{ "ids": [123] }

PagerDuty channel

{
  "pagerduty_integration_ids": ["service_id-integration_id"],
  "pagerduty_integration_keys": ["integration_key"]
}

Medium parameter quick lookup and doc links

When asking the user for parameters, attach the corresponding link (clickable, external). The URL prefix is uniformly https://flashcat.cloud/docs/content/flashcat-monitor/nightingale-v9/usage/alert-notify/notify-channel/; the table below only lists the final segment:

For media a user built themselves (idents not in the table above), go by the keys returned by custom_params and ask about each one; when you can't figure out a key's meaning, give the user the notification-medium overview doc: .../notify-channel/ (i.e. the prefix itself).

time_ranges (applicable time windows)

{ "week": [0, 1, 2, 3, 4, 5, 6], "start": "00:00", "end": "00:00" }

• Both start and end being "00:00" means the full 24 hours of the day.
• One NotifyConfig can have multiple time_ranges, OR'd between them.
• Crossing midnight (e.g. 22:00–02:00) must be split into two segments: {start:"22:00", end:"23:59"} + {start:"00:00", end:"02:00"}; the engine does not roll over to the next day automatically.
• For effectiveness at all times, leave it empty []; don't stuff in an all-day entry.

label_keys (label filtering)

Event labels come from time-series data (PromQL labels) + alert-rule additional labels + the rule name, etc.

{ "key": "service", "value": "api" }

• Multiple label_keys are AND'd (alert/dispatch/dispatch.go:NotifyRuleMatchCheck).
• The same key cannot be written multiple times to OR them (structural limitation); for OR use attributes' in, or split into multiple NotifyConfigs.
• List of selectable keys: GET /api/n9e/event-tagkeys; when unsure which labels an event has, confirm with the user in your reply.
• When the event labels do not contain ident (e.g. lost when categraf writes directly to the time-series store), routing by ident will fail to match everything, so have the user confirm the data flow.

attributes (attribute filtering)

Attributes = event metadata, not user-defined labels. The supported keys are fixed:

func (operators)