Skip to main content
Plan requirement: This feature requires an On-call Standard or higher subscription. Learn more
Configure alert Webhook. When specific operations occur on alerts (such as trigger or close), the system makes an HTTP callback to your configured address. The callback content includes the alert’s latest key information, allowing integration with your custom tools.

​
1. Event Types

The following event types are currently supported; more may be added in the future.
Event TypeDescription
a_newIntegration pushes new event, triggering a new alert
a_updateIntegration pushes new event, merges into an alert, and updates alert info (severity, status, labels, description, etc.)
a_mergeMerge alert into incident
a_closeManually close alert (system event, automatically triggered when an alert is manually closed, not selectable in the UI)

​
2. Push Description

​
Request Method

POST, Content-Type:“application/json”

​
Request Payload:

FieldTypeRequiredDescription
event_timeint64YesEvent timestamp in milliseconds
event_typestringYesEvent type, enum values see Event Types
event_idstringYesEvent ID, the same event may retry multiple times due to timeout, receiver needs to deduplicate
personPersonNoOperator, only exists for human actions
alertAlertYesAlert details
Person:
FieldTypeRequiredDescription
person_idint64YesPerson ID
person_namestringYesPerson name
emailstringYesEmail address
Alert:
FieldTypeRequiredDescription
alert_idstringYesAlert ID
data_source_idint64YesIntegration ID
data_source_namestringYesIntegration name
data_source_typestringYesIntegration type
channel_idint64YesChannel ID
channel_namestringYesChannel name
titlestringYesAlert title
title_rulestringNoTitle generation rule
descriptionstringNoAlert description
alert_keystringYesAlert association key
alert_severitystringYesSeverity, enum: Critical, Warning, Info
alert_statusstringYesAlert status, enum: Critical, Warning, Info, Ok
progressstringYesProgress, enum: Triggered, Closed
created_atint64YesCreated time
updated_atint64YesUpdated time
start_timeint64YesFirst trigger time (time of first event received by platform), Unix seconds timestamp
last_timeint64YesLatest event time (time of latest event received by platform), Unix seconds timestamp
end_timeint64NoAlert recovery time (time platform last received end-type event), Unix seconds timestamp, default 0
close_timeint64NoClose time, different from end_time, this is progress close, doesn’t mean alert truly recovered. Unix seconds timestamp, default 0
labelsmap[string]stringNoLabel KV, both Key and Value are strings
event_cntint64NoAssociated event count
incidentIncidentNoAssociated incident
Incident:
FieldTypeRequiredDescription
incident_idstringYesIncident ID
titlestringYesIncident title

​
Request Response

HTTP status code 200 indicates successful push.

​
Request Example

curl -X POST 'https://example.com/alert/webhook?a=a' \
-H 'Content-Type: application/json' \
-H 'X-Customize-Header-A: a' \
-d '{
    "alert":{
        "alert_id":"645c3affd2b92d989a0bd824",
        "alert_key":"d21d9e3126f5ae94",
        "alert_severity":"Warning",
        "alert_status":"Warning",
        "channel_id":1163577812973,
        "channel_name":"Order System",
        "close_time":0,
        "created_at":1683766015,
        "data_source_id":1571358104973,
        "data_source_name":"Aliyun SLS",
        "data_source_ref_id":"",
        "data_source_type":"aliyun-sls.alert",
        "description":"Test sending to Flashduty alert trigger",
        "end_time":0,
        "event_cnt":1,
        "incident":{
            "incident_id":"645db17c9759374196929314",
            "title":"123123123"
        },
        "labels":{
            "a":"a",
            "alert_type":"sls_alert",
            "alert_url":"https://sls.console.aliyun.com/lognext/project/sls-api-testing/alert/alert-1683548531-071659",
            "aliuid":"1082109605037616",
            "check":"Test sending to Flashduty",
            "fire_results":"{\"_col0\":\"true\"}",
            "fire_results_count":"1",
            "project":"sls-api-testing",
            "raw_condition":"Count:__count__ \u003e 0; Condition:",
            "region":"cn-beijing",
            "resource":"d18195cd567c6e8b-5fb6a5e6fb8ad-1f269e0",
            "severity":"6"
        },
        "last_time":1683809153,
        "progress":"Triggered",
        "start_time":1683766013,
        "title":"Test sending to Flashduty alert trigger",
        "title_rule":"$resource::$check",
        "updated_at":1683809170
    },
    "event_id":"ffcf1d47a8d853dc800d000c87e5568b",
    "event_time":1683890681639,
    "event_type":"a_merge",
    "person":{
        "email":"zhangsan@flashcat.cloud",
        "person_id":82138731581973,
        "person_name":"Flashcat"
    }
}' -v

​
3. Configuration Guide

Go to Integration Center → Webhook → Add or edit an Alert Webhook integration.

​
Basic Settings

Enter the integration name and description for easy management.

​
Webhook Settings

Config ItemDescription
Managing TeamSelect the team that manages this integration; only team members can edit the integration configuration
EndpointHTTP/HTTPS address to receive callbacks, must start with http:// or https://
TLS VerificationEnabled by default. When disabled, TLS certificate verification of the target server is skipped; suitable for test environments or self-signed certificates
HeadersCustom request headers in Key-Value format; multiple headers supported
ChannelsSelect All Channels or Specific Channels. When specific channels are selected, only alert events in those channels trigger callbacks
Event TypesCheck the event types to subscribe to (see Event Types); select all is supported. Only checked event types trigger callbacks
Disabling TLS certificate verification may expose you to man-in-the-middle attacks. Only disable it in test environments or when using self-signed certificates.

​
4. Invocation History

Alert Webhook provides a complete invocation history, helping you troubleshoot push delivery and debug callback interfaces.

​
View Invocation History

Go to the Alert Webhook integration detail page and switch to the Invocation History tab.
FilterDescription
Time RangeSelect from last 1 hour, 6 hours, 1 day, 7 days, or custom range (up to 7 days of data)
Alert IDEnter an alert ID for exact search
Event TypeFilter records by event type
Request StatusFilter by success or failure

​
History Record Fields

FieldDescription
Trigger TimeTime when the event was triggered
Event TypeThe triggered event type (e.g., a_new, a_update, etc.)
Alert IDAssociated alert ID; click to jump to alert details
Event IDUnique identifier for this callback; used for deduplication
Request StatusSuccess or failure, with HTTP status code
DurationRound-trip request time
Attempt CountIncludes initial request and retries

​
View Invocation Details

Click View Details on a record to see the complete request and response information:
  • Request: Includes Endpoint, Request Headers, and Request Payload
  • Response: On success, shows Response Headers and Response Body; on failure, shows Error Message

​
5. FAQ

  1. Is there a response timeout?
    • Service needs to return response within 2 seconds; exceeding 2 seconds is considered a failure
  2. Will pushes continue after failure?
Retries for specific network errors, max 1 retries:
  • context deadline exceeded (excluding awaiting headers)
  • i/o timeout
  • eof
  1. How to ensure push order?
    • Theoretically, events for the same alert are pushed in chronological order, but retries may cause out-of-order delivery
    • Services can filter based on event_time; if a later event has been received, earlier events can be filtered out. Each push carries the latest complete information, so occasional event loss is tolerable
  2. Trusted IP whitelist for push source?
    • May be updated in the future, please check regularly