Alert webhook

Configure alert webhooks to receive HTTP callbacks at your specified URL when alerts have specific actions (such as triggering or closing). The callback content includes the latest key information about the alert, allowing integration with your custom tools.

I. Event Types

The following event types are currently supported, with more potentially being added in the future.

Event Type	Description
a_new	Integration pushes new event, triggering a new alert
a_update	Integration pushes new event, merging into an existing alert and updating its information (severity, status, labels, description, etc.)
a_merge	Merge alert into incident
a_close	Manually close alert

II. Push Description

Request Method

POST, Content-Type:"application/json"

Request Payload:

Field	Type	Required	Description
event_time	int64	Yes	Event occurrence time in `millisecond timestamp`
event_type	string	Yes	Event type, see Event Types for enumerated values
event_id	string	Yes	Event ID, `same event may retry multiple times due to timeout etc., receivers need to deduplicate`
person	Person	No	Operator, only present for manual actions
alert	Alert	Yes	Alert details

Person:

Field	Type	Required	Description
person_id	int64	Yes	Person ID
person_name	string	Yes	Person name
email	string	Yes	Email address

Alert:

Field	Type	Required	Description
alert_id	string	Yes	Alert ID
data_source_id	int64	Yes	Integration ID
data_source_name	string	Yes	Integration name
data_source_type	string	Yes	Integration type
channel_id	int64	Yes	Channel ID
channel_name	string	Yes	Channel name
title	string	Yes	Alert title
title_rule	string	No	Title generation rule
description	string	No	Alert description
alert_key	string	Yes	Alert correlation basis
alert_severity	string	Yes	Severity level, enum: Critical, Warning, Info
alert_status	string	Yes	Alert status, enum: Critical, Warning, Info, Ok
progress	string	Yes	Processing progress, enum: Triggered, Closed
created_at	int64	Yes	Creation time
updated_at	int64	Yes	Update time
start_time	int64	Yes	First trigger time (time of first event received by platform), Unix timestamp in seconds
last_time	int64	Yes	Latest event time (time of most recent event received by platform), Unix timestamp in seconds
end_time	int64	No	Alert recovery time (time when platform last received end-type event), Unix timestamp in seconds, defaults to 0
close_time	int64	No	Closure time, different from end_time, this indicates progress closure, not actual alert recovery. Unix timestamp in seconds, defaults to 0
labels	map[string]string	No	Label key-value pairs, both Key and Value are strings
event_cnt	int64	No	Number of associated events
incident	Incident	No	Associated incident

Incident:

Field	Type	Required	Description
incident_id	string	Yes	Incident ID
title	string	Yes	Incident title

Response

HTTP status code 200 indicates successful push.

Request Example

III. FAQ

Is there a response timeout for the service?

The service must respond within 1 second, after which the response is considered failed

Will failed pushes continue to be pushed?

Currently, FlashDuty pushes only once, though retry mechanisms may be introduced in the future. Retries may also occur due to middleware timeouts, so implement idempotent processing

How is push order guaranteed?

In theory, events for the same alert are pushed in chronological order, but retries and other situations 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 acceptable

Trusted IP whitelist for push sources?

{ip_whitelist}

May be updated in the future, please check periodically

Alert webhook

I. Event Types#

II. Push Description#

Request Method#

Request Payload:#

Response#

Request Example#

III. FAQ#