OpsGenie v2 event handler

OpsGenie is an incident response orchestration platform for DevOps & ITOps teams. Kapacitor can be configured to send alert messages to OpsGenie.

This page is specific to OpsGenie’s v2 API. If still using their v1 API, view the OpsGenie v1 event handler documentation.


Configuration as well as default option values for the OpsGenie v2 event handler are set in your kapacitor.conf. Below is an example configuration:

  enabled = true
  api-key = "mysupersecretapikey"
  teams = ["team1", "team2"]
  recipients = ["recipient1", "recipient2"]
  url = ""
  recovery_action = "notes"
  details = false
  global = false


Set to true to enable the OpsGenie v2 event handler.


Your OpsGenie API Key.


Default OpsGenie teams. Can be overridden per alert.


Default OpsGenie recipients. Can be overridden per alert.


The OpsGenie API URL. This should not need to be changed.


The recovery action specifies which action to take when alerts recover. Valid values include:

  • notes - Add a note to the alert.
  • close - Close the alert.
  • custom - Use the .RecoveryAction() method to specify the recovery_action in a TICK script.


If true, the alert details field is sent as the OpsGenie alert description field. If false, details are encoded as description.


If true, all alerts are sent to OpsGenie without specifying opsgenie2 in the TICKscript. The team and recipients can still be overridden.


The following OpsGenie v2 event handler options can be set in a handler file or when using .opsGenie2() in a TICKscript.

teams-listlist of stringsList of teams.
recipients-listlist of stringsList of recipients.

Example: handler file

id: handler-id
topic: topic-name
kind: opsgenie2
    - 'team1'
    - 'team2'
    - 'recipient1'
    - 'recipient2'

Example: TICKscript

  // ...
    .teams('team1', 'team2')
    .recipients('recipient1', 'recipient2')

OpsGenie Setup

To allow Kapacitor to send alerts to OpsGenie, create an OpsGeneie API Integration. Use the generated API key as the api-key in the [opsgenie2] section of your kapacitor.conf

Using the OpsGenie event handler

With the OpsGenie v2 event handler enabled and configured in your kapacitor.conf, use the .opsGenie2() attribute in your TICKscripts to send alerts to OpsGenie or define an OpsGenie v2 handler that subscribes to a topic and sends published alerts to OpsGenie.

The examples below use the following OpsGenie configuration defined in the kapacitor.conf:

OpsGenie v2 settings in kapacitor.conf

  enabled = true
  api-key = "mysupersecretapikey"
  teams = ["engineering"]
  recipients = ["supervisor1", "supervisor2"]
  url = ""
  recovery_action = "close"
  global = false

Send alerts to OpsGenie from a TICKscript

The following TICKscript uses the .opsGenie2() event handler to send the message, “Hey, check your CPU”, to OpsGenie whenever idle CPU usage drops below 10%.


    .crit(lambda: 'usage_idle' < 10)
    .message('Hey, check your CPU')
      .teams('engineering', 'support')

Send alerts to OpsGenie from a defined handler

The following setup sends an alert to the cpu topic with the message, “Hey, check your CPU”. An OpsGenie v2 handler is added that subscribes to the cpu topic and publishes all alert messages to OpsGenie.

Create a TICKscript that publishes alert messages to a topic. The TICKscript below sends an alert message to the cpu topic any time idle CPU usage drops below 10%.


    .crit(lambda: 'usage_idle' < 10)
    .message('Hey, check your CPU')

Add and enable the TICKscript:

kapacitor define cpu_alert -tick cpu_alert.tick
kapacitor enable cpu_alert

Create a handler file that subscribes to the cpu topic and uses the OpsGenie v2 event handler to send alerts to OpsGenie.


id: opsgenie-cpu-alert
topic: cpu
kind: opsgenie2
    - 'engineering'
    - 'support'

Add the handler:

kapacitor define-topic-handler opsgenie2_cpu_handler.yaml

Was this page helpful?

Thank you for your feedback!

The future of Flux

Flux is going into maintenance mode. You can continue using it as you currently are without any changes to your code.

Flux is going into maintenance mode and will not be supported in InfluxDB 3.0. This was a decision based on the broad demand for SQL and the continued growth and adoption of InfluxQL. We are continuing to support Flux for users in 1.x and 2.x so you can continue using it with no changes to your code. If you are interested in transitioning to InfluxDB 3.0 and want to future-proof your code, we suggest using InfluxQL.

For information about the future of Flux, see the following: