Incident Webhook

Configure Incident Webhook to have the system callback your configured address via HTTP when specific incident operations (such as trigger, close) occur. The callback content will include the latest key information about the incident, allowing you to integrate with your own tools.

I. Event Types

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

Event Type	Description
i_new	Create incident (automatic or manual)
i_assign	Assign incident (automatic or manual)
i_snooze	Manually snooze incident
i_wake	Unsnooze incident
i_ack	Manually acknowledge incident
i_unack	Unacknowledge incident
i_storm	Trigger storm warning
i_custom	Trigger custom action
i_rslv	Close incident (automatic or manual)
i_reopen	Reopen incident
i_merge	Manually merge incidents
i_r_title	Update incident title
i_r_desc	Update incident description
i_r_impact	Update incident impact
i_r_rc	Update incident root cause
i_r_rsltn	Update incident resolution
i_r_severity	Update incident severity
i_r_field	Update incident custom fields

II. Push Description

Request Method

POST, Content-Type:"application/json"

Request Payload:

Field	Type	Required	Description
event_time	int64	Yes	Event occurrence `timestamp in milliseconds`
event_type	string	Yes	Event type, see Event Types for enumeration values
event_id	string	Yes	Event ID, `same event may retry multiple times due to timeout, receiver needs to deduplicate`
person	Person	No	Operator, exists only for manual actions
incident	Incident	Yes	Incident details

Person:

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

Responder:

Field	Type	Required	Description
person_id	int64	Yes	Person ID
person_name	string	Yes	Person name
email	string	Yes	Email address
assigned_at	int64	No	Assignment time
acknowledged_at	int64	No	Acknowledgment time

Incident:

Field	Type	Required	Description
incident_id	string	Yes	Incident ID
title	string	Yes	Incident title
description	string	No	Incident description
impact	string	No	Incident impact
root_cause	string	No	Incident root cause
resolution	string	No	Incident resolution
incident_severity	string	Yes	Severity level, enum: Critical, Warning, Info
incident_status	string	Yes	Incident status, enum: Critical, Warning, Info, Ok
progress	string	Yes	Processing progress, enum: Triggered, Processing, Closed
created_at	int64	Yes	Creation time
updated_at	int64	Yes	Update time
start_time	int64	Yes	Trigger time, Unix timestamp in seconds
last_time	int64	No	Latest event time, latest event push time of associated alerts, Unix timestamp in seconds, default 0
end_time	int64	No	Recovery time, incident auto-recovers when all associated alerts recover, Unix timestamp in seconds, default 0
ack_time	int64	No	First acknowledgment time, incident can be acknowledged by multiple people, this is earliest ack time. Unix timestamp in seconds, default 0
close_time	int64	No	Close time, end_time represents incident recovery time, close_time represents progress closure time. Recovery closes incident but closure doesn't affect recovery. Unix timestamp in seconds, default 0
snoozed_before	int64	No	Snooze end time
labels	map[string]string	No	Label key-values, both Key and Value are strings. No info for manual creation, for auto-creation it's the labels of first aggregated alert
fields	map[string]interface{}	No	Custom field key-values, Key is string, Value can be any type depending on field type
creator	Person	No	Creator info, exists only for manually created incidents
closer	Person	No	Closer info, exists only for manually closed incidents
responders	[]Responder	No	List of responder information
alert_cnt	int64	No	Number of associated alerts
channel_id	int64	No	Channel ID, 0 means not belonging to any channel
channel_name	string	No	Channel name
detail_url	string	Yes	Detail URL
group_method	string	No	Grouping method, enum: n: no grouping, p: rule-based grouping, i: intelligent grouping

Response

HTTP status code 200 indicates successful push.

Request Example

III. Common Questions

Is there a response timeout for the service?

The service must respond within 1 second, otherwise it will be considered as a failed response

Will pushes continue after a failed push?

Currently, FlashDuty pushes at most once. A retry mechanism may be introduced in the future, and retries may also occur due to middleware timeouts. You need to handle idempotency properly

How is push order guaranteed?

In theory, events for the same incident are pushed in chronological order, but retries and other situations may cause out-of-order delivery

The service can filter based on event_time. If a later event has been received, earlier events can be filtered out. Each push carries the latest and complete information, occasional event loss is tolerable

Trusted IP whitelist for push sources?

47.94.95.118, 123.56.8.183, 47.94.193.81, 1.13.19.96

May be updated in the future, please check periodically

I. Event Types#

II. Push Description#

Request Method#

Request Payload:#

Response#

Request Example#