Dynatrace Alerts to On-Call

Dynatrace problem notifications become CallHeim alerts: repeats on the same problem collapse onto one incident, and the service the integration is bound to pages whoever is on call for it. CallHeim includes a payload mapping for Dynatrace’s webhook format, built and tested against sample payloads.

How the alert reaches on-call

Step 1A Dynatrace problem opens or its state changes.
Step 2Dynatrace's custom-integration problem notification renders your payload template and POSTs it to your CallHeim ingest URL.
Step 3CallHeim reads the problem's PID as the identity signal and maps its ProblemImpact to a severity.
Step 4Repeats on the same problem within five minutes collapse onto one incident.
Step 5The integration's bound service selects an escalation policy, which pages the on-call tier.

Setting it up

01
Add a problem notification integration in Dynatrace.
Settings (classic) > Integration > Problem notifications > Add notification > Custom integration.
02
Enter your CallHeim ingest URL and set a custom payload.
Create the Dynatrace integration in CallHeim first to get the exact ingest URL. Dynatrace needs a body template — include PID, ProblemID, ProblemTitle, State, ProblemImpact, ImpactedEntity and ProblemDetailsText, since those are the fields the CallHeim parser reads.
03
Send a test notification before saving.
Dynatrace's own "Send test notification" button confirms the template renders valid JSON before it goes live.

Example payloadJSON

{
  "PID": "-1234567890123456789_PID",
  "ProblemID": "P-2026...",
  "ProblemTitle": "Failure rate increase on payment-service",
  "ProblemImpact": "SERVICE",
  "State": "OPEN",
  "ImpactedEntity": "payment-service",
  "ProblemDetailsText": "Failure rate increased to 8% in the last 5 minutes"
}

Example shape written by us, in the fields our template asks Dynatrace to send; check Dynatrace's own documentation for the full placeholder list.

What CallHeim reads from the payload

Payload fields and what each one maps to on the incident
Payload field	Maps to	Note
ProblemTitle / title	incident title
ProblemImpact (ENVIRONMENT / APPLICATION / SERVICE / INFRASTRUCTURE)	severity	ENVIRONMENT or APPLICATION→P1, SERVICE→P2, INFRASTRUCTURE (or anything else)→P3, unless State is RESOLVED or CLOSED, which writes P4 instead. ProblemSeverity is not read.
ProblemDetailsText / ImpactedEntity / ProblemImpact	incident body
PID (or ProblemID, or ProblemURL)	identity signal

How CallHeim processes it

Routing

Each alert source is bound to a service, and the service’s escalation policy (or its team’s) sets who is paged.

Deduplication

Repeats of the same alert collapse onto one incident while they keep arriving within five minutes of each other. A repeat that arrives after a longer quiet gap opens a new incident. Identity is the problem's PID (or ProblemID), so repeated notifications about the same problem collapse.

Recovery

A resolved problem does not close the incident, even though the field is present. CallHeim reads a capitalised State field and writes P4 when it reads RESOLVED or CLOSED, but the generic close detector that would close the incident automatically checks a lowercase state field — a case difference that means it never sees Dynatrace's value. The incident stays open until a person resolves it.

Troubleshooting

Common problems and how to fix them
Problem	Fix
A resolved problem stays open, even at the right lower severity.	Expected — see Recovery above. The severity downgrade works; closing the incident automatically does not.
The body is empty.	No custom payload template was set on the notification — Dynatrace sends nothing usable without one (see setup).
Every problem lands at P3.	ProblemImpact was missing from the template; confirm it is included and spelled exactly as Dynatrace names it.
HTTP 400 on send.	Curly-brace placeholders like {ImpactedEntities} and {ProblemDetailsJSON} are JSON data types in Dynatrace's template syntax and must not be wrapped in quotes — a quoted placeholder breaks the JSON once substituted.
HTTP 401 once you enabled signing.	Dynatrace's custom integration supports additional HTTP headers, so add X-ItOnCall-Signature there if you enable signing.

Security

CallHeim verifies an HMAC-SHA256 signature on each source’s requests once you enable signing on that integration (the sending tool must be able to sign). Dynatrace's custom integration supports additional HTTP headers, so you can add X-ItOnCall-Signature there if you enable signing. Until you do, the ingest URL itself is the credential.

Vendor documentation checked

Dynatrace: Webhook integration (problem notifications) — checked 2026-09-24

The thresholds it passes through

Dedup window: 300s
Flap threshold: 4 transitions / 600s
Title correlation: similarity ≥ 0.6, same source and service
Group window default: 600s

All defaults are published. You can turn title correlation off or change its threshold, and set the window on your own noise rules; the dedup window and the flap settings are fixed. How alerts are processed →

Send Dynatrace alerts to on-call with CallHeim.