Incident webhook

Configure incident webhooks to receive HTTP callbacks at your specified URL when incidents have specific actions (such as triggering or closing). The callback content includes the latest key information about the incident, 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
i_new	Create incident (automatically or manually)
i_assign	Assign incident (automatically or manually)
i_snooze	Manually snooze incident
i_wake	Unsnooze incident
i_ack	Manually acknowledge incident
i_unack	Unacknowledge incident
i_storm	Trigger alert storm notification
i_custom	Trigger custom action
i_rslv	Close incident (automatically or manually)
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 timestamp in `milliseconds`
event_type	string	Yes	Event type, see Event Types for enumerated values
event_id	string	Yes	Event ID, `same event may be retried multiple times due to timeout, receivers need 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 status, 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 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, incidents can be acknowledged by multiple people, this is the earliest acknowledgment time. Unix timestamp in seconds, default 0
close_time	int64	No	Close time, end_time represents incident recovery time, close_time represents processing status closure time. Incident recovery triggers closure, 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-value pairs, both Key and Value are strings. Not available for manually created incidents, for auto-created incidents contains labels from the first aggregated alert
fields	map[string]interface{}	No	Custom field key-value pairs, Key is string, Value can be any type depending on field type
creator	Person	No	Creator information, exists only for manually created incidents
closer	Person	No	Closer information, 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	Details 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. FAQ

Is there a response timeout for the service?

Services must respond within 1 second, responses after 1 second are 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 incident 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 complete, up-to-date information, so occasional event loss is acceptable

Trusted IP whitelist for push sources?

{ip_whitelist}

May be updated in the future, please check periodically

Incident webhook

I. Event Types#

II. Push Description#

Request Method#

Request Payload:#

Response#

Request Example#

III. FAQ#