Skip to main content
Plan requirement: This feature requires an On-call Standard or higher subscription. Learn more
Configure incident custom actions, allowing you to quickly call external interfaces during incident troubleshooting to achieve self-healing, information enrichment, or any custom operations.

1. Create Action

  1. Login to Flashduty console, go to Integration Center - Webhook
  2. Click to add Custom Action integration
  3. Configure Action Name—this name will appear as a button in incident details
  4. Configure Managing Team—select the team that manages this integration; only team members can edit the integration configuration
  5. Configure Channels—you can configure multiple, but each channel can have at most 5 Custom Actions
  6. Configure Endpoint and custom Headers
  7. TLS Verification is enabled by default. If the target service uses a self-signed certificate or a certificate issued by an internal CA, you can disable the TLS Verification toggle so the system will not validate the server certificate
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.
  1. Save to complete
Each channel can have a maximum of 5 custom actions. If a channel has reached this limit, it cannot be selected when adding a new custom action.

2. Push Description

Request Method

POST, Content-Type:“application/json”

Request Payload:

Person:Responder:Incident:Alert:

Request Response

HTTP status code 200 indicates successful push.

Request Example

3. Custom Request Body and Value Mapping

Custom request body (custom_body)

By default, the system pushes the complete JSON data following the Payload structure described above. If your receiver requires a specific data format, you can use a custom request body to reorganize the push content. Use {{field.path}} syntax to reference any field from the default Payload. The system replaces variables with actual values at push time. Variable syntax:
  • Use . to separate path levels, e.g. {{incident.title}} references the incident title
  • Array index access is supported, e.g. {{incident.responders.0.email}} references the first responder’s email
  • When the entire value is a single variable (e.g. "{{incident.labels}}"), the original data type is preserved (object, array, number, etc.)
  • When a variable is mixed with other text (e.g. "Incident: {{incident.title}}"), the variable is converted to a string for concatenation
Example:
If a variable path does not exist in the default Payload, the system keeps the original {{...}} text without replacement. It is recommended to first check the actual default Payload via a test push to confirm available field paths.

Value mapping (value_mapping)

Value mapping automatically transforms field values during variable resolution in the custom request body. Value mapping is configured per field path. Example:
Used with "severity": "{{incident.incident_severity}}" in the custom request body, when the incident severity is Critical, the severity field in the push result will be P0. Values that do not match any mapping are sent as-is.

4. Use Cases

Restart Host

When host memory or CPU is maxed out, trigger a host restart script to quickly complete the restart.

Information Enrichment

When an incident occurs, callback to your service to retrieve Tracing, Logging, topology and other information based on alert details, then proactively 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, if it’s determined to be caused by a change, directly trigger a callback to your deployment platform to start the rollback process and accelerate incident recovery.

Update Status Page

When an incident is confirmed to impact production services, trigger external status page updates to promptly notify your customers or upstream/downstream parties.

5. FAQ

  1. Is there a response timeout?
    • Service needs to return response within 1 second; exceeding 1 second 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. Trusted IP whitelist for push source?
    • May be updated in the future, please check regularly