AWS CloudWatch integration

Turn CloudWatch alarms into phone calls, Telegram and escalation

Subscribe an SNS topic to WardenPoint over HTTPS. CloudWatch alarms arrive as SNS notifications, the alarm state maps to severity, an OK state posts a Resolved notice, and unacknowledged alarms escalate across voice, Telegram, SMS and email.

Start free View API examples
Setup
SNS HTTPS
State
ALARM / OK
Recovery
Resolved ping

Anatomy of a CloudWatch alarm

LIVE
CloudWatch → SNS
CPUUtilization > 90% on web-01
WardenPoint
map state · escalate · resolved notice
Telegram
Voice call
Email

Setup

Three steps in AWS

SNS can't send custom headers, so the integration secret rides in the subscription URL — paste it once and you're done.

  1. 1Step 1

    Create or pick an SNS topic

    In Amazon SNS create a Standard topic (or reuse the one your alarms already notify). This is the topic your CloudWatch alarms will publish to.

    $ SNS › Topics › Create topic › Standard
  2. 2Step 2

    Subscribe WardenPoint over HTTPS

    Add a subscription with protocol HTTPS and the endpoint set to your WardenPoint URL with ?secret=<your secret> appended. WardenPoint auto-confirms the subscription the moment AWS sends the handshake.

    $ Endpoint › https://wardenpoint.com/api/v1/integrations/alerts/…?secret=…
  3. 3Step 3

    Point alarms at the topic

    On each CloudWatch alarm, set the Alarm action (and optionally the OK action) to publish to that SNS topic. WardenPoint receives the alarm on state change automatically.

    $ Alarm › Actions › Send to SNS topic

Wire format

SNS notification envelope

SNS wraps the CloudWatch alarm as a JSON string inside Message. WardenPoint unwraps it, maps NewStateValue to firing or resolved, and dedupes on the AlarmArn.

SNS → WardenPoint
sns-notification.jsonJSON
// SNS delivers the alarm as a JSON string inside "Message"
{
"Type": "Notification",
"Message": "{\"AlarmName\":\"High CPU on web-01\",\"NewStateValue\":\"ALARM\",\"NewStateReason\":\"Threshold Crossed\",\"Region\":\"us-east-1\",\"AlarmArn\":\"arn:aws:cloudwatch:us-east-1:000000000000:alarm:High CPU on web-01\",\"Trigger\":{\"Namespace\":\"AWS/EC2\",\"MetricName\":\"CPUUtilization\"}}"
}
WardenPoint fan-out
WardenPoint response202
{
"status": "queued",
"notification_uuid": "notif_8h2k7yQrxJp",
"channels_planned": [
"telegram_voice",
"voice_call",
"email"
],
"escalation_chain_id": "esc_4j2k9bMcvL"
}

Routing recipes

Three patterns for CloudWatch → WardenPoint

Run different alarm groups or AWS accounts through separate WardenPoint integrations, each wired to its own escalation chain.

Severity

ALARM → phone first

An ALARM state maps to WardenPoint 'high' — phone call first, Telegram voice second, email at minute three. INSUFFICIENT_DATA stays on a quieter channel.

match
NewStateValue = ALARM
→ route
severity: high
Account

One topic per AWS account

Create a dedicated WardenPoint integration per account or environment, each subscribed to that account's SNS topic, so prod and staging alarms route to different chains.

match
AWSAccountId = prod
→ route
→ prod chain
Recovery

OK posts a Resolved notice

When the alarm returns to OK, SNS publishes again to the same topic. WardenPoint dedupes on the AlarmArn, marks the alert resolved and posts a Resolved notice to your chain.

match
NewStateValue = OK
→ route
→ Resolved notice

CloudWatch FAQ

Common CloudWatch integration questions

AWS SNS HTTPS subscriptions can't add an Authorization header, so the integration secret rides in the endpoint URL as ?secret=<your secret>. The URL lives only in your own SNS subscription config and travels over TLS. A request with a wrong or missing secret is rejected with 401.
Free plan

Wire one CloudWatch alarm before you depend on it

Subscribe the SNS topic, trigger a test alarm and read the audit line. No credit card. No production risk.

Start free Back to integrations
  • State maps to severity
  • OK posts a Resolved notice
  • Per-account routing