Webhook adapters

Amazon CloudWatch

Send Amazon CloudWatch alarms to WarnFire through SNS — alarms open incidents, and a return to OK closes them.

Version 1.0 Status Needs verification For Integration operators webhooks aws cloudwatch sns

If you run on AWS and watch it with CloudWatch alarms, this page connects them to WarnFire so a firing alarm opens an incident and pages your on-call responder — and a return to normal closes it automatically.

Alarms, not logs. WarnFire consumes CloudWatch alarms — a metric alarm changing state. It does not read your raw CloudWatch Logs or metric streams. Set up the alarms that matter, and WarnFire pages on those.

CloudWatch delivers alarms through Amazon SNS (Simple Notification Service). You point an alarm at an SNS topic, subscribe WarnFire’s address to that topic, and WarnFire takes it from there.

Before you begin

A WarnFire service and integration key for these alarms. If you do not have one, create the service and its first key .
Permission in AWS to create an SNS topic, add an HTTPS subscription, and set an alarm action.

Your WarnFire address

Because SNS can’t attach a security header, your integration key is part of the address itself:

https://api.warnfire.com/v1/integrations/webhooks/cloudwatch/wf_live_your_integration_key_here

Treat that whole address as a secret — anyone who has it can open incidents on your service. If it’s ever exposed, revoke the key under Services and subscribe a fresh one.

Connect CloudWatch to WarnFire

In the AWS console, open Amazon SNS → Topics and create a Standard topic (for example, warnfire-alarms).
Open that topic, choose Create subscription, and fill it in:
- Protocol: HTTPS
- Endpoint: your WarnFire address from above
- Leave Enable raw message delivery off.
Create the subscription. WarnFire verifies AWS’s certificate and message signature, validates the integration key, binds that key to this topic ARN, and then confirms the subscription automatically. Within a few seconds the subscription shows as Confirmed in SNS. A different SNS topic cannot use the same CloudWatch address after this binding. Complete the ALARM → OK test below before relying on the subscription. If it stays Pending, see the troubleshooting table below.
Point your alarms at the topic. On each CloudWatch alarm, under Actions, add the warnfire-alarms topic to both:
- In alarm — so a firing alarm pages you, and
- OK — so recovery closes the incident.

That’s it. You can send every alarm through the one topic; WarnFire keeps each alarm’s incident separate.

To replace the SNS topic, create a fresh WarnFire integration key and subscribe the new topic to the address containing that key. After the new topic passes the test below, remove the old subscription and revoke the old key.

How your alarms become incidents

WarnFire turns each CloudWatch alarm into one incident, using the alarm’s identity so its states stay together:

When the alarm goes to In alarm (ALARM), the incident opens and paging starts.
When the alarm returns to OK, the same incident is closed.
When the alarm goes to Insufficient data, the incident opens at warning severity — CloudWatch has stopped getting the data it needs to judge the alarm.
Repeated deliveries of the same alarm state are recognized and ignored, so an SNS retry can’t double-page anyone.

What shows up on the incident

WarnFire maps your CloudWatch alarm to the incident automatically:

On the incident	Comes from
Title	The alarm name
Severity	The alarm state: `ALARM` → critical, `INSUFFICIENT_DATA` → warning, `OK` → resolves the incident
Description	The alarm’s reason for the state change (falls back to the alarm description)
Source	The alarm’s first metric dimension (falls back to the namespace or AWS account)
Component	The alarm’s metric name
Region	The alarm’s AWS region
Environment	An `environment`, `env`, or `stage` dimension, if you set one
Link	View in CloudWatch — a jump straight to the alarm
Labels · Details	The alarm’s dimensions, namespace, statistic, period, threshold, and comparison

To get the most out of this, give your alarms clear names and add an env (or environment) dimension so severity and grouping land the way you expect.

Verify it worked

Point a disposable CloudWatch alarm at the SNS topic and make sure its In alarm and OK actions both use that topic.
Put the alarm into ALARM. Confirm that one WarnFire incident opens for the intended service and its on-call responder is paged.
Return the alarm to OK. Confirm that the same WarnFire incident closes.

This test follows the real incident and escalation path. It can page responders; selected SMS and voice deliveries consume allowance or prepaid credits and can invoke configured auto-recharge. Notify the responder before changing the alarm state.

If the subscription won’t confirm or alarms don’t arrive

What you see	What it means
Subscription stays Pending confirmation	WarnFire rejected the integration key or AWS signature, the key is already bound to another SNS topic, the endpoint was unreachable, or SNS’s confirmation request failed. Re-check the complete endpoint. If this is a replacement topic, create a fresh integration key and use its CloudWatch address. Then choose Request confirmation again.
Alarms fire in AWS but no incident opens	The alarm’s In alarm action isn’t pointed at the SNS topic, or raw message delivery was turned on — turn it off.
Incidents open but never close	The alarm has no OK action pointed at the same topic. Add it.
The subscription is Confirmed, but no incident opens	The alarm action may point at a different topic, the key may have been revoked after confirmation, or the alarm payload may be invalid. Recreate the subscription with a current key, then validate an actual `ALARM` → `OK` lifecycle.
Nothing arrives and the key was recently rotated	Recreate the subscription with the current URL and key, delete the old subscription, and validate an actual `ALARM` → `OK` lifecycle.
SNS reports 429 delivery failures	The trigger-rate limit or maximum active-incident limit was reached. SNS retries these failures. Check Limits and protections and resolve stale incidents.

Next steps

Review Delivery Activity to confirm what WarnFire can prove after each paging provider accepts a notification.