Costom action

Custom incident actions allow you to quickly invoke external interfaces during incident troubleshooting for incident self-healing, information enrichment, and other custom operations.

I. Creating Actions

Click to add a Custom Action integration

Configure the action name, which will appear as a button in the incident details

Configure channels (multiple can be configured, but each channel can have up to three custom actions)

Configure Endpoint and custom Headers

Save to complete

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, fixed value `i_custom`
event_id	string	Yes	Event ID, `same event may retry 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	Root cause
resolution	string	No	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, 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 progress closure time. Incident recovery triggers closure, but closure doesn't affect recovery. Unix timestamp in seconds, default 0
snoozed_before	int64	No	Snooze deadline time
labels	map[string]string	No	Label KV pairs, both Key and Value are strings. Not present for manually created incidents, for auto-created incidents contains labels from the first aggregated alert
fields	map[string]interface{}	No	Custom field KV 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
alerts	Alert	No	Associated alerts
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

Alert:

Field	Type	Required	Description
alert_id	string	Yes	Alert ID
data_source_id	int64	Yes	Integration ID
title	string	Yes	Alert title
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 latest event received by platform), Unix timestamp in seconds
end_time	int64	No	Alert recovery time (time of last end-type event received by platform), Unix timestamp in seconds, default 0
close_time	int64	No	Close time, different from end_time, this is processing progress closure, doesn't mean alert actually recovered. Unix timestamp in seconds, default 0
labels	map[string]string	No	Label KV pairs, both Key and Value are strings

Response

HTTP status code 200 indicates successful push.

Request Example

III. Use Cases

Host Restart

When host memory or CPU is maxed out, trigger host restart scripts for quick recovery.

Information Enrichment

When an incident occurs, callback to your service to retrieve Tracing, Logging, topology, and other information based on alert details. Actively call FlashDuty Open API to update incident information, such as adding labels or setting custom fields to assist troubleshooting.

Rollback Changes

When an incident occurs and is confirmed to be caused by a change, directly trigger a callback to your deployment platform to initiate rollback process for faster incident recovery.

Update Status Page

When an incident is confirmed to affect online services, trigger external status page updates to prompt

Costom action

I. Creating Actions#

II. Push Description#

Request Method#

Request Payload:#

Response#

Request Example#

III. Use Cases#

Host Restart#

Information Enrichment#

Rollback Changes#

Update Status Page#