Webhook adapters

CloudWatch via EventBridge

Send CloudWatch alarms to WarnFire through Amazon EventBridge — a header-authenticated alternative to SNS that carries the same alarms.

This is a second way to send Amazon CloudWatch alarms to WarnFire, using Amazon EventBridge instead of SNS. Both open an incident when an alarm fires and close it when the alarm returns to OK — pick whichever fits your AWS setup.

Alarms, not logs. Like the SNS path, this consumes CloudWatch alarm state changes — not raw logs or metric streams.

When to choose EventBridge over SNS : EventBridge can send your integration key in a normal Authorization header, so the key never sits in the URL. It also lets you route many alarms with one rule and filter which ones page. If you already publish alarms to an SNS topic, the SNS page is simpler; if you’re standardizing on EventBridge, use this.

An alarm delivered by either path lands on the same incident — WarnFire correlates on the alarm’s identity — so you can migrate from one to the other without double-paging.

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 EventBridge connection, API destination, and rule.

Connect EventBridge to WarnFire

1. In the AWS console, open Amazon EventBridge → API destinations → Connections and create a connection:
   • Authorization type: API key
   • API key name: Authorization
   • Value: Bearer wf_live_your_integration_key_here
2. Create an API destination that uses that connection:
   • API destination endpoint: https://api.warnfire.com/v1/integrations/webhooks/eventbridge
   • HTTP method: POST
3. Create a rule on the default event bus with this event pattern, and set its target to the API destination above:

{
  "source": ["aws.cloudwatch"],
  "detail-type": ["CloudWatch Alarm State Change"]
}

That’s it. Every alarm state change in the account now flows to WarnFire. To page on only some alarms, narrow the pattern (for example, match specific alarmName values).

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.
• Repeated deliveries of the same state are recognized and ignored, so an EventBridge retry can’t double-page anyone.

What shows up on the incident

WarnFire maps your alarm to the incident automatically:

Verify it worked

1. Follow Test before you connect , choose eventbridge, and confirm the preview maps the expected action, title, severity, correlation key, and metadata. Preview does not select or verify a service.
2. Choose the intended service for Send test, send the confirmed test, and verify that one test incident opens for that service and pages its on-call responder.
3. Put a disposable CloudWatch alarm into ALARM, then return it to OK. Confirm that EventBridge delivers both changes, one WarnFire incident opens, and that same incident closes.

Send test and a delivered alarm follow the real incident and escalation path. They can page responders; selected SMS and voice deliveries consume allowance or prepaid credits and can invoke configured auto-recharge. Notify the responder before testing.

If EventBridge gets an error back

EventBridge expects a response within a few seconds and retries on failure, so a brief WarnFire hiccup won’t lose an alarm.

Next steps

Use Preview a mapping again before changing the EventBridge rule or target in production.