Cloud platforms

Send AWS CloudWatch Alarm (via SNS) alerts to on-call with CallHeim.

CloudWatch alarm published to SNS → HTTPS subscription. CallHeim maps the payload, collapses repeats within five minutes, and pages whoever is on call for the service it belongs to.

cloudwatchalarmalso accepts: cloudwatch-sns, cw-sns, sns-cloudwatch

AWS CloudWatch alarms, delivered through an SNS topic, 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 SNS-delivered path, not CallHeim's own internal EventBridge rule — that internal rule only carries CallHeim's own operational alarms, not a customer account's.

How the alert reaches on-call

Step 1A CloudWatch alarm changes state and publishes to an SNS topic in your account.
Step 2SNS delivers the notification as an HTTP(S) POST to your CallHeim ingest URL (the SNS envelope, with the alarm JSON stringified inside its Message field).
Step 3CallHeim parses the inner Message, reads AlarmName as the identity signal, and maps NewStateValue to a severity.
Step 4Repeats of the same alarm, account and region 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 a standard SNS topic in the same AWS account and region as the alarm.
CloudWatch alarms can only publish to an SNS topic in the same account and region. Make it a standard topic: a FIFO topic cannot deliver to HTTPS.
02
Subscribe your CallHeim ingest URL to the topic with protocol HTTPS.
Create the CloudWatch Alarm (via SNS) integration in CallHeim first to get the exact ingest URL. Raw message delivery can be on or off: CallHeim reads the notification envelope, or the bare alarm message, either way.
03
Confirm the subscription.
SNS sends a SubscriptionConfirmation message to the endpoint first; CallHeim confirms the subscription automatically, usually within a few seconds of you creating it. If it stays "Pending confirmation", choose Request confirmation.
04
Point the alarm's ALARM and OK actions at the same SNS topic.
For the alarm (or a whole set of alarms), add a Notification with alarm state trigger "In alarm" that notifies the topic, and a second Notification with alarm state trigger "OK" that notifies the SAME topic. The OK notification is what resolves the incident. Without it the incident stays open until a person resolves it — see Recovery below.
05
Leave the INSUFFICIENT_DATA action off this topic.
That state counts as firing and would open an incident (at P3, see the field mapping); it never resolves one. Notify this topic on "In alarm" and "OK" only.
06
(Alternative) Route through an EventBridge rule instead of SNS.
AWS also lets you forward CloudWatch Alarm State Change events with an EventBridge rule and an API destination. That route has its own integration and guide, AWS CloudWatch (EventBridge): the rule sends the event exactly as EventBridge emits it, with no input transformer, so there is nothing to reshape.

Example payloadJSON

{
  "Type": "Notification",
  "MessageId": "8f5a1c2e-...",
  "TopicArn": "arn:aws:sns:us-east-1:111122223333:alarms",
  "Subject": "ALARM: prod-api-5xx",
  "Message": "{\"AlarmName\":\"prod-api-5xx\",\"AlarmDescription\":\"5xx errors elevated\",\"NewStateValue\":\"ALARM\",\"NewStateReason\":\"5xx > 10 for 2 datapoints\",\"Region\":\"us-east-1\",\"AWSAccountId\":\"111122223333\"}",
  "Timestamp": "2026-06-28T00:00:00Z"
}

Example shape written by us, matching the SNS envelope AWS documents; check AWS's own documentation for the full notification format.

What CallHeim reads from the payload

Payload fields and what each one maps to on the incident
Payload field	Maps to	Note
Message (inner AlarmName, or Subject)	incident title
Message.NewStateValue (ALARM / OK / INSUFFICIENT_DATA)	severity	ALARM→P2, INSUFFICIENT_DATA→P3, OK→P4.
Message.NewStateReason / AlarmDescription / Subject	incident body
Message.AlarmName + AWSAccountId + Region	identity signal	Scopes the same alarm name in two different accounts or regions to separate incidents.

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 it came from, so the same alarm firing again on the same resource collapses onto the open incident.

Recovery

When the alarm returns to OK, CallHeim resolves the incident. INSUFFICIENT_DATA does not resolve it; it is recorded at P3. Checked with a real CloudWatch alarm and SNS HTTPS subscription on 25 September 2026. An alarm with no OK action never sends the OK, so its incident stays open until a person resolves it.

Troubleshooting

Common problems and how to fix them
Problem	Fix
No alerts arrive at all.	Check the SNS subscription status in the AWS console — an unconfirmed subscription (still "Pending confirmation") delivers nothing; choose Request confirmation. Check too that the topic is a standard topic: a FIFO topic cannot deliver to HTTPS.
The alert body is empty or unreadable.	Something other than SNS is posting to the URL, or the alarm is publishing to a different topic than the one subscribed. CallHeim reads the SNS envelope shape shown in the sample, or the bare alarm message when raw message delivery is on.
An OK state does not close the incident.	Check that the alarm's OK action notifies the same SNS topic, and that the OK comes from the same alarm, account and region as the ALARM that opened the incident.
An alarm with no data opens an incident.	The alarm's INSUFFICIENT_DATA action notifies this topic. That state counts as firing and would open an incident: remove that action, and keep only the "In alarm" and "OK" notifications on this topic.
Two different AWS accounts' alarms with the same name collapse together.	They shouldn't — the fingerprint includes AWSAccountId and Region. Check both alarms are actually publishing the account id in the inner Message (a hand-rolled EventBridge-to-SNS bridge can drop it).
Alerts stop after a period of quiet, then duplicate.	A gap over five minutes between alarm transitions opens a new incident by design — that is not a bug.

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 Alarm (via SNS) 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