Webhook integration

Dynatrace offers several out-of-the-box integrations that automatically push problem notifications to third-party incident-management and ChatOps systems. If however your third-party system isn't supported with an out-of-the-box integration, you can easily set up a customizable webhook integration. Using this approach, whenever Dynatrace detects a problem in your environment that affects real users, a webhook triggers an HTTP POST request to a target URL that you specify. The payload message of the HTTP POST request is completely customizable. By default, requests use valid JSON syntax except that you define a different HTTP content type header. In case you define a different HTTP content type header, Dynatrace will skip the JSON validation. In such cases, Dynatrace doesn't escape the payload based on JSON syntax. Information placeholders, such as {ProblemTitle} and {State}, are used to fill the custom JSON with the dynamic information of each detected problem.

To integrate problem-notifications using a custom webhook:

  1. Navigate to Settings > Integration > Problem notifications.

  2. Select Set up notifications, and then select Custom integration.

The Set up custom integration page is displayed.

  1. Type the following information to set up a webhook integration

    • Name User-defined display name that distinguises this unique integration from other integrations.
    • Webhook URL Target URL where the HTTP POST should push the payload. This URL can contain HTTP parameters such as an authentication token, in case the destination system works with authentication tokens instead of basic authentication.
    • optional Additional HTTP headers
      Specify additional HTTP header fields, such as 'Content-Type' or 'Authorization'. These custom HTTP header fields can be used if the target endpoint needs an authentication token within the HTTP header or if you would like to send different content type such as 'text/plain' or 'application/xml'.
    • optional Create basic authorization header
      Basic authorization HTTP headers represents a username password pair that is concatenated by a colon character and finally base64 encoded. Given an example of a username 'alice' that comes with a password 'hello.my.pwd'. Both values are combined with a colon 'alice:hello.my.pwd' and base64 encoded, which finally results in 'YWxpY2U6aGVsbG8ubXkucHdk'. The basic authorization HTTP will therefore look like: 'Authorization' : 'basic YWxpY2U6aGVsbG8ubXkucHdk'. To save you the time to repeat the process for your own username and password, the UI button 'Create basic authorization header' automatically generates that specific HTTP header for you just by entering your username and password.
    • Custom payload
      Once a problem is detected or resolved, this customizable payload is pushed through an HTTP POST to the target system. Use specific placeholders to dynamically populate the payload with problem-related information, such as problem state or title.
  2. Finalize, send a test notification, and select Save.

  3. Use the Notification level switches to control the types of problem notifications that are sent to the target system (problems with Applications, Services, and Infrastructure).

  4. Before saving your custom integration setup, select Send test notification to perform a test run and ensure that the destination address is available.

Available placeholders

  • {ImpactedEntities}: Details about the entities impacted by the problem in the form of a JSON array. Not available for SaaS environments.
  • {ImpactedEntity}: Entity impacted by the problem (or x impacted entities when there are multiple).
  • {PID}: Unique system identifier of the reported problem.
  • {ProblemDetailsHTML}: All problem event details including root cause as an HTML-formatted string. Not available for SaaS environments.
  • {ProblemDetailsJSON}: All problem event details including root cause in form of a JSON object. Not available for SaaS environments.
  • {ProblemDetailsMarkdown}: All problem event details including root cause as a Markdown-formatted string. Not available for SaaS environments.
  • {ProblemDetailsText}: All problem event details including root cause as a text-formatted string. Not available for SaaS environments.
  • {ProblemID}: Display number of the reported problem.
  • {ProblemImpact}: Impact level of the problem. Possible values are APPLICATION, SERVICE, or INFRASTRUCTURE.
  • {ProblemSeverity}: Severity level of the problem. Possible values are AVAILABILITY, ERROR, PERFORMANCE, RESOURCE_CONTENTION, or CUSTOM_ALERT.
  • {ProblemTitle}: Short description of the problem.
  • {ProblemURL}: URL of the problem within Dynatrace.
  • {State}: Problem state. Possible values are OPEN or RESOLVED or in some cases MERGED when the problem has been merged into another problem.
  • {Tags}: Comma-separated list of tags that are defined for all impacted entities.


Here is a valid JSON web hook problem-notification definition example. After a problem has been detected, the placeholders are populated with the actual values and results, as shown in this example payload:

  "ImpactedEntities": [
    {"type": "HOST", "name": "MyHost1", "entity": "HOST-XXXXXXXXXXXXX" },
    {"type": "SERVICE", "name": "MyService1", "entity": "SERVICE-XXXXXXXXXXXXX"}
  "ImpactedEntity": "MyHost1, MyService1",
  "PID": "99999",
  "ProblemDetailsHTML": "<h1>Dynatrace problem notification test run details</h1>",
  {"ID" : "99999" }
  "ProblemID": "999",
  "ProblemImpact": "INFRASTRUCTURE",
  "ProblemTitle": "Dynatrace problem notification test run",
  "Problem URL": "https://example.com",
  "State": "OPEN",
  "Tags": "testtag1, testtag2"

Note: {ImpactedEntities} and {ProblemDetailsJSON} are JSON data types and must not have quotes around them.