Overview

The DingTalk Group Chat Robot notification channel pushes alert events from Nightingale to a designated DingTalk group via the DingTalk Group Custom Robot (Webhook).

• Use case: deliver alerts as Markdown messages into a DingTalk group, with @ mentions of specific members.
• Prerequisites: a DingTalk group, plus permission to “Add Robot” in that group.
• The whole setup has three steps: ① Add a robot in the DingTalk group → ② Create a DingTalk notification channel in Nightingale → ③ Fill in the access_token in the notification rule.

If you are already familiar with DingTalk Open Platform’s “internal enterprise application” mechanism and need to deliver alerts to a single chat or include alert screenshots, see DingTalk Application. This page only covers the most common and simplest group-robot approach.

Step 1: Add a custom robot in the DingTalk group

1. In the target DingTalk group: Group Settings → Smart Group Assistant → Add Robot → Custom (Custom Robot).

2. Set the robot name (for example Nightingale Alert) and avatar, then click “Next”.

3. Security settings (at least one is required; “Custom Keyword” is recommended — Nightingale currently only supports these two):

   Type	Description	Use case
   Custom Keyword	Robot only accepts messages containing the specified keyword(s); up to 10	Recommended, simplest. Use a word that always appears in alert rule names, such as Alert or n9e
   IP Allowlist	Only accept requests from the specified IP range	Suitable when deployed behind a fixed public egress

4. Check “I have read and agree to the Robot Service and Disclaimer”, then click “Done”.

5. On the popup, copy the Webhook URL, which looks like:

   https://oapi.dingtalk.com/robot/send?access_token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   

   The string after access_token= is the Access Token you’ll fill into Nightingale later — save it.

Official DingTalk limit: a single robot can send at most 20 messages per minute, exceeding which triggers throttling. For very high alert volumes, split alerts across multiple groups/robots, or configure a sensible suppression strategy in your notification rule.

Step 2: Create a DingTalk notification channel in Nightingale

1. Sign in to Nightingale → left menu Notification → Notification Channels to enter the channel list page.

2. In the channel-type panel on the left, click DingTalk to enter the create page (URL /notification-channels/add?ident=dingtalk).

   

3. Fill in the basics and save. Most fields are pre-filled by the system — you only need to change “Name”:

   

   Section	Field	Edit needed	Notes
   Basic	Name	Yes	e.g. DingTalk Group Robot. This is what appears when you select the channel in a notification rule
   Basic	Enabled	Keep on	If turned off, the channel will not be used
   Variables	Contact Method	Optional	Used for @ mentions; the selected user field’s “phone” is injected into the message body (configure phone in “User Management” first)
   Variables	Parameters	Keep default, do not delete	The parameters access_token and bot_name are pre-set; the actual token is filled in step 3 inside the notification rule
   HTTP	URL	Keep default	https://oapi.dingtalk.com/robot/send
   HTTP	Method	POST	DingTalk Webhook only accepts POST
   HTTP	Headers	Content-Type: application/json	Pre-filled

4. Scrolling down you will see “Request Parameters” and “Request Body”. These two pieces are the core sending logic for DingTalk — keep them as default:

   

   • Request Parameters has access_token = {{$params.access_token}} pre-set, meaning the real token comes from the access_token parameter filled in the notification rule;

   • Request Body is pre-set to DingTalk Markdown message format:

     {
       "msgtype": "markdown",
       "markdown": {
         "title": "{{$tpl.title}}",
         "text": "{{$tpl.content}}\n{{batchContactsAts $sendtos}}"
       },
       "at": {
         "atMobiles": {{batchContactsJsonMarshal $sendtos}}
       }
     }
     

     Where {{$tpl.title}} and {{$tpl.content}} come from the message template named Dingtalk, and {{$sendtos}} is the list of contacts to @ (typically phone numbers).

5. Click Save in the lower-left, and a notification channel of type “DingTalk” is ready.

Note: Nightingale v8 no longer stores the token on the channel itself like older versions did. The same DingTalk channel can be reused across multiple groups/robots; each notification rule fills in its own access_token.

Step 3: Fill in the access_token in the notification rule

The access_token segment of a DingTalk robot Webhook URL is filled inside the notification rule:

1. Left menu Notification → Notification Rules → New (or edit an existing rule).

2. In the “Notification Configuration” area:

   

   • Notification Channel: pick the DingTalk channel you just created;
   • Message Template: pick Dingtalk (built-in; if missing, import the default templates from “Message Templates”);
   • Access Token: paste the token from Step 1 (just the part after access_token=, no full URL);
   • Bot Name: optional; a name to help you identify it, such as Nightingale Monitoring;
   • Applicable Severity / Time Range / Tags: filter which events to push as needed.

3. After saving, click “Notification Test” to send a test message — the DingTalk group should immediately receive a Markdown alert.

One DingTalk channel + multiple robots

If different business lines want to push to different groups, no new channel is needed — just create another notification rule with a different access_token.

FAQ

Q1: Getting keywords not in content (keyword mismatch)?

A: The DingTalk robot has the “Custom Keyword” security policy enabled, but no keyword appears in the alert title/content. Fix: include the configured keyword in your alert rule name, or add a more permissive keyword (such as Alert) on the DingTalk robot side.

Q2: Getting sign not match (signature error)?

A: The DingTalk robot is using “Signature” mode, but Nightingale by default does not append sign/timestamp parameters. Switch to “Custom Keyword” mode if possible; if you must use signing, fill the complete signed URL in access_token (in the form https://oapi.dingtalk.com/robot/send?access_token=xxx&timestamp=yyy&sign=zzz), or stitch the signature manually inside the message template (advanced).

Q3: Messages arrive but @ mentions don’t work?

A: DingTalk decides whether to @ based on the phone numbers in atMobiles, and those phones must belong to group members. Configure phone numbers under “User Management” in Nightingale, and in the channel’s “Variables → Contact Method” pick the corresponding user field.

Q4: Hitting rate limits?

A: DingTalk officially caps a single robot at 20 messages/minute. Recommendations:

• Enable alert suppression/aggregation;
• Split traffic across multiple groups by business;
• Send only P1/P2 alerts to DingTalk, route P3 to email or another async channel.

Q5: Can I just put the full URL into the access_token field?

A: Yes. The system is compatible with both forms — if the value starts with http:// or https://, it is treated as a complete Webhook URL and sent as-is; otherwise it is concatenated as https://oapi.dingtalk.com/robot/send?access_token=<your value>.

References

• DingTalk Open Platform · Custom Robot Access
• DingTalk Open Platform · Custom Robot Security Settings