Splunk On-Call allows to integrate with external tools of your choice through custom outbound webhooks. These webhooks are highly flexible, providing full control over the URL, HTTP method, content type, and payload structure. To ensure that the data sent to third-party systems is relevant and real-time, dynamic variables can be incorporated. These variables are categorized by event types—such as Incident, Chat, or Paging and must be enclosed in the ${{VARIABLE_NAME}} syntax. For example, to include the total number of alerts within an incident, ${{STATE.ALERT_COUNT}} variable should be used.
Dynamic variables within webhook payloads allows to ensure third-party systems receive real-time, context-specific information. Please note that the available variables change depending on the Event Type selected during configuration. To correctly reference a variable, use the ${{variable_name}} syntax. For example, to pass the total number of alerts in an incident, you would use ${{STATE.ALERT_COUNT}}.
Built-in variables allow alerting platform to dynamically pass incident data to external or third-party systems. The variables used in the payload depend on the specific event type chosen for the webhook.
Variables by Event Type
| Event Type | Variable | Meaning |
| Chat Events | CHAT.USER_ID | ID of the user sending/receiving chat |
| CHAT.TEXT | Chat message text | |
| CHAT.IS_ROBOT | Whether the message came from a bot | |
| Incident Events(Any-Incident, Incident-Triggered, Incident-Acknowledged, Incident-Resolved) | INCIDENT.ENTITY_TYPE | Type of entity (e.g., server, database) |
| ALERT.SERVICESTATE | Service health state (CRITICAL/WARNING/OK) | |
| ALERT.VO_ALERT_RCV_TIME | When the alert was received | |
| ALERT.entity_display_name | Alert entity name | |
| ALERT.entity_state | Entity health status | |
| ALERT.message_type | Trigger/acknowledge/resolve type | |
| ALERT.monitor_name | Which monitor triggered the alert | |
| ALERT.monitoring_tool | Monitoring system name | |
| ALERT.routing_key | Routing key for integrations | |
| Incident State Details (Any-Incident, Incident-Triggered, Incident-Acknowledged, Incident-Resolved) | STATE.ACK_MSG | Acknowledgement message |
| STATE.ACKED_AT | Who acknowledged it | |
| STATE.RESOLVED_AT | When it was resolved | |
| STATE.RESOLVED_BY | Who resolved it | |
| STATE.ALERT_COUNT | Number of alerts in the incident | |
| STATE.CURRENT_ALERT_PHASE | Current alert lifecycle phase | |
| STATE.HOST | Host where the issue occurred | |
| STATE.INCIDENT_NAME | Incident title | |
| STATE.INCIDENT_TIMESTAMP | Creation time of the incident | |
| On-Call Events (Any-On-Call, Off-Call, On-Call) | ONCALL.GROUP_ID | On-call group identifier |
| ONCALL.USER_ID | ID of on-call user | |
| ONCALL.STATE | Current on-call status | |
| ONCALL.TEAM_NAME | On-call team name | |
| Paging Events(Any-Paging, Paging-Start, Paging-Stop) | PAGE.USER_ID | User being paged |
| PAGE.STARTED | Paging start time | |
| PAGE.ID | Unique paging ID | |
| PAGE.ATTEMPT_NUMBER | Attempt count | |
| PAGE.METHODS.0.TYPE | First paging method (SMS/Phone/Email) | |
| PAGE.METHODS.0.LABEL | First method display label | |
| PAGE.CANCELLATION | Whether paging was canceled |
Payload Construction:
When including variables in the payload, wrap them with ${{variable_name}}. For example, to include the number of alerts in an incident, use ${{STATE.ALERT_COUNT}}. Other incident-specific fields such as ${{ALERT.field_name}} can also be used.
| Revision | Publish Date | Comments |
|---|---|---|
1.0 |
01-Oct-2026
|
Initial Release |