Cloud platforms

Send AWS CloudWatch alerts to on-call with CallHeim.

CloudWatch alarm state changes, via an EventBridge rule you create in your own AWS account. CallHeim maps the payload, collapses repeats within five minutes, and pages whoever is on call for the service it belongs to.

cloudwatchalso accepts: aws.cloudwatch, aws-cloudwatch

You build the connection

AWS CloudWatch has no native outbound webhook for this. It requires a forwarder, script or template that you set up; CallHeim provides the ingest URL and understands the payload shape once it arrives.

AWS CloudWatch alarms, forwarded through an EventBridge rule you create in your own AWS account, become CallHeim alerts: repeats of the same alarm 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 AWS CloudWatch’s webhook format, built and tested against sample payloads. This is the EventBridge route: it needs a rule and an API destination you build yourself, with no built-in forwarding. If building that rule is more than you want, the CloudWatch Alarm (via SNS) guide needs only a topic and an HTTPS subscription — no EventBridge rule at all.

How the alert reaches on-call

Step 1A CloudWatch alarm changes state; EventBridge's default event bus receives an aws.cloudwatch / "CloudWatch Alarm State Change" event for it automatically — no rule is needed to generate the event itself, only to forward it.
Step 2An EventBridge rule you create, matching that event pattern, sends it to an API destination target that POSTs the event JSON to your CallHeim ingest URL.
Step 3CallHeim reads detail.alarmName, scoped to the event's AWS account and region, as the identity signal and maps detail.state.value to a severity.
Step 4Repeats of the same alarm 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
Create the AWS CloudWatch (EventBridge) integration in CallHeim to get an ingest URL.
02
Create an EventBridge connection that uses an API key header CallHeim does not read.
Amazon EventBridge > API destinations > Connections > Create connection. Authorization type: API Key, with API key name X-Placeholder and any value. EventBridge requires one; CallHeim does not read it — the ingest URL itself is the credential. Do not use Authorization or an X-CallHeim- / X-ItOnCall- header name, which CallHeim does read. The Basic and OAuth authorization types send an Authorization header, so do not choose them.
03
Create an API destination pointed at that URL.
Amazon EventBridge > API destinations > Create API destination: the ingest URL as the endpoint, HTTP method POST, using the connection you created above.
04
Create an EventBridge rule on the default event bus that forwards ALARM and OK state changes.
Event pattern: {"source":["aws.cloudwatch"],"detail-type":["CloudWatch Alarm State Change"],"detail":{"state":{"value":["ALARM","OK"]}}}. Keep OK in the pattern: OK is what resolves the incident the ALARM opened. INSUFFICIENT_DATA is left out on purpose because it would open an incident. To page on only some alarms, add "alarmName":[{"prefix":"prod-"}] inside "detail" in the pattern.
05
Set the rule's target to the API destination.
Keep the target input as "Matched events" — no input transformer — so CallHeim receives the event exactly as EventBridge emits it. Let the console create the rule's execution role (it needs events:InvokeApiDestination on the destination). A rule with a target it cannot invoke fails silently from CallHeim's side — check EventBridge's own rule metrics if nothing arrives.
06
Leave the alarm itself alone, and repeat the setup per region.
The alarm does not need to know about EventBridge or CallHeim — EventBridge picks up its state changes automatically once a rule exists in the alarm's account and region. EventBridge rules, connections and API destinations are regional: repeat the connection, API destination and rule in every region you want covered.

Example payloadJSON

{
  "version": "0",
  "id": "6a7b8c9d-...",
  "detail-type": "CloudWatch Alarm State Change",
  "source": "aws.cloudwatch",
  "account": "111122223333",
  "region": "us-east-1",
  "time": "2026-06-28T00:00:00Z",
  "detail": {
    "alarmName": "prod-api-5xx",
    "state": { "value": "ALARM", "reason": "Threshold Crossed: 1 datapoint > 10.0" },
    "previousState": { "value": "OK" }
  }
}

Example shape written by us, matching the EventBridge envelope AWS documents for a CloudWatch Alarm State Change event; check AWS's own documentation for the full detail object.

What CallHeim reads from the payload

Payload fields and what each one maps to on the incident
Payload field	Maps to	Note
detail.alarmName	incident title	Falls back to "CloudWatch Alarm" if absent.
detail.state.value (ALARM / OK / INSUFFICIENT_DATA)	severity	ALARM→P2, OK→P4. INSUFFICIENT_DATA is not special-cased on this route the way it is on the SNS integration — it falls back to the same P2 as ALARM, not P3.
detail.state.reason	incident body
detail.alarmName + account + region	identity signal	Scopes the same alarm name in two different accounts or regions to separate incidents, the same as the SNS-based CloudWatch Alarm integration.

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. For this source the fingerprint is the alarm name scoped to the AWS account and region in the event, so the same alarm firing again collapses onto the open incident.

Recovery

When the alarm returns to OK, CallHeim resolves the incident. INSUFFICIENT_DATA does not resolve it, and an OK from another account or region leaves the incident open. Checked on 26 September 2026 with CloudWatch Alarm State Change events in EventBridge's format.

Troubleshooting

Common problems and how to fix them
Problem	Fix
Nothing arrives.	Check the EventBridge rule's own invocation and failed-invocation metrics before assuming CallHeim is at fault — a rule whose target role cannot invoke the API destination fails at EventBridge, before anything reaches CallHeim. Check too that the connection, API destination and rule exist in the region the alarm is in.
An OK state does not close the incident.	Check that the EventBridge rule forwards OK state changes as well as ALARM (an event pattern filtered to ALARM drops them), and that the OK comes from the same account and region as the alarm that opened the incident.
Alarms from a second AWS account with the same name collapse into the first.	They shouldn't — identity includes the event's account and region. Check that the rule forwards the unmodified EventBridge event (target input "Matched events", no input transformer), which carries both.
INSUFFICIENT_DATA alarms page at the same severity as a real ALARM.	The rule's event pattern lets INSUFFICIENT_DATA through. On this route INSUFFICIENT_DATA counts as firing at the same P2 as ALARM (see field mapping), so it opens an incident. Use the event pattern in setup, which forwards only ALARM and OK: INSUFFICIENT_DATA is left out on purpose because it would open an incident.
HTTP 401 once you enabled signing.	An EventBridge API destination target can attach a static header (HeaderParameters on the target), but not a per-request HMAC of the body — so it cannot produce the signature X-ItOnCall-Signature has to be for signing to pass. Leave signing off for this integration.

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 →

CallHeim

Point AWS CloudWatch at CallHeim and see what it does with your alerts.

Explore the platform, connect one source, and send yourself a test page by e-mail (early access).

Explore the platform All integrations

Early access · every workspace starts with a 14-day trial for up to 5 seats, no card required