Outbound channels
Feishu, DingTalk, WeCom, Slack, Teams, email, webhook and other channels routed by severity, delivery records with retry, report schedule, and ticketing (ServiceNow, Jira) configuration.
Outbound channels govern how messages leave the product: investigation verdicts, operations reports, budget alerts and baseline failures, routed by severity to the targets whose threshold they meet. Admins configure; analysts can test-send.
Targets
| Channel | Form | Notes |
|---|---|---|
| Feishu | Bot webhook with signature | Interactive card |
| DingTalk | Bot webhook with HMAC signature | oapi.dingtalk.com |
| WeCom | Bot webhook | qyapi.weixin.qq.com |
| Slack | Incoming Webhook | Block Kit card: title, severity bar, summary, Open in Copilot button. hooks.slack.com |
| Microsoft Teams (Beta) | Workflows or Incoming Webhook | Adaptive Card 1.4. *.logic.azure.com, *.webhook.office.com, and from 2.0.14 *.environment.api.powerplatform.com |
| Recipient list | Global SMTP below | |
| Generic webhook | JSON POST | Custom SOAR or SIEM |
Each target has a severity threshold and receives only messages at or above that level. Webhook URLs live in storage/passwords; the list shows only the host, and an empty field on edit keeps the stored value. Test send posts a simulated alert and shows the channel's own error inline on failure (for example Feishu code=19001).
Domain allow-lists are fixed per channel; the generic webhook is unrestricted.
SMTP
One global configuration: host, port, encryption (starttls, ssl, none), user, password (storage/passwords), sender. Email targets carry only recipients.
Deliveries
One record per delivery (KV copilot_notify_deliveries): target, content type, state (sent, retrying, dead), attempts, last error. Retryable errors (DingTalk 130101 and 45009, Slack and Teams 5xx, network errors) back off and retry automatically; dead deliveries can be resent by hand.
Schedule
Scheduled generation and push of operations reports: hour and time zone. Reports are pushed at the configured hour in the configured time zone (IANA name, default Asia/Shanghai). The report period itself (day, week or month) still starts at 00:00 UTC, so in a zone ahead of UTC an hour earlier than the UTC offset (for example 07:00 in Asia/Shanghai) is reached on the next day. If the Splunk Python runtime has no time-zone database (some Windows installs), the zone is saved unchecked and the hour is taken as UTC; Splunk's internal log shows a warning.
Ticketing
From 1.9.0, the Ticketing tab configures ServiceNow or Jira; Jira Data Center is supported from 2.0.14. Ticketing is still Beta.
| Item | ServiceNow | Jira Cloud | Jira Data Center |
|---|---|---|---|
| URL | https://<instance>.service-now.com | https://<site>.atlassian.net | The on-prem URL; the host must be listed in copilot.conf [tickets] allowed_hosts |
| Auth | Basic (user and password) or OAuth token | Email and API token (Basic) | Personal access token (PAT) |
| Target | incident table | Project key and issue type | Project key and issue type |
| Mapping | Severity to urgency and impact | Severity to priority | Severity to priority |
Credentials go to storage/passwords; Test connection shows the account name the other side returns. Tickets are opened from the investigation dialog and the reports page: the body is the incident report (ADF for Jira Cloud, keeping bold text and links; for Jira Data Center, wiki markup in alert data is shown as plain text from 2.0.16); the returned key and link are stored on the investigation record. Egress policy is [tickets]: SaaS domains are allowed by default, on-prem hosts must be listed in allowed_hosts, private CAs use verify_tls = 0.
Audit log
One metadata event per AI call with operator, action, index, latency, outcome and tokens. A server-aggregated dashboard, thumbs-down review, usage and budget.
Settings
Index allow-list, the three masking modes, audit forwarding, version. There is no data-source connection block; the Splunk connection is implicit inside the app.