Skip to main content
Connect AWS CloudWatch alarms to CloudThinker so that alarm state changes enter Pulse as Signals. The recommended approach uses Amazon EventBridge to route CloudWatch alarm events to your CloudThinker webhook URL with no Lambda function.

How it works

When a CloudWatch alarm changes state, EventBridge forwards the event through an API Destination. CloudThinker parses the event into a Signal, Pulse correlates and routes the problem, and an eligible Incident can start RCA automatically.
Why EventBridge? EventBridge sends clean JSON directly to your webhook with built-in retry logic, dead-letter queues, and IAM-based security. Unlike SNS, no subscription handshake or Lambda transform is needed.

Prerequisites

  • An AWS account with permissions to create EventBridge rules, API destinations, and connections
  • A CloudWatch alarm configured for the metric you want to monitor
  • A CloudThinker webhook URL (created in the steps below)

Setup

1

Create a CloudThinker webhook

  1. In CloudThinker, go to Resolve → Integrations
  2. Click Connect on the AWS CloudWatch card
  3. Enter a name (e.g., “Production CloudWatch Alerts”)
  4. Review the pre-configured field mappings — these are set for the EventBridge format:
  1. The default auth method is API Key with header x-api-key — this matches the EventBridge connection setup
  2. Configure severity mapping and auto-trigger settings as needed
  3. Click Create and copy the Secret Key
The secret key is only shown once during creation. Copy it immediately — you’ll paste it as the API key value in the EventBridge connection in the next step.
2

Create an EventBridge connection

  1. In the AWS Console, go to Amazon EventBridge → Integration → Connections
  2. Click Create connection
  3. Configure the connection:
    • Name: cloudthinker-webhook
    • Authorization type: API Key
    • API key name: x-api-key
    • API key value: Paste the Secret Key from the CloudThinker webhook creation dialog
3

Create an API destination

  1. Go to Amazon EventBridge → Integration → API destinations
  2. Click Create API destination
  3. Configure:
    • Name: cloudthinker-incidents
    • API destination endpoint: Paste your CloudThinker webhook URL
    • HTTP method: POST
    • Connection: Select the cloudthinker-webhook connection created above
    • Invocation rate limit: 100 per second (adjust as needed)
4

Create an EventBridge rule

  1. Go to Amazon EventBridge → Rules
  2. Select the default event bus and click Create rule
  3. Configure:
    • Name: cloudwatch-alarms-to-cloudthinker
    • Rule type: Rule with an event pattern
  4. Define the event pattern:
  1. Select target:
    • Target type: EventBridge API destination
    • API destination: Select cloudthinker-incidents
    • Execution role: Create a new role or use an existing one with events:InvokeApiDestination permissions
  2. Click Create rule
5

Test the integration

Use the AWS CLI to simulate an alarm state change:
Within a few seconds, you should see a new Signal in Pulse with the alarm details. An actionable Cluster can then route into an Incident. Reset the alarm with the same command and --state-value OK.

Event payload

EventBridge delivers CloudWatch alarm events as JSON. The default field mappings read these parts of the structure:

Severity mapping

CloudWatch alarm states map to CloudThinker severity levels. The default mapping is: You can customize this mapping in the webhook configuration under Severity Mapping.

Filtering alarms

Control which alarms raise Signals by refining the EventBridge rule’s event pattern. Add a detail block to the base pattern: By alarm name prefix:
By specific alarm states:
By metric namespace:

Multi-region setup

CloudWatch events are regional — alarms only emit events to the EventBridge bus in their own region. For multi-region monitoring, either forward alarm events from each source region to one central event bus and route to CloudThinker from there, or create an API destination and rule in every region pointing at the same CloudThinker webhook URL.

Troubleshooting

  1. Check the EventBridge rule — Go to EventBridge → Rules → select your rule → Monitoring tab. Verify the rule is matching events (Invocations metric > 0)
  2. Check the API destination — Go to API destinations → select yours → verify the endpoint URL matches your CloudThinker webhook URL
  3. Check CloudThinker delivery history — Go to Resolve → Integrations, select the platform and webhook, then review its delivery history
  4. Test with CLI — Run aws cloudwatch set-alarm-state to simulate an alarm and verify the full chain
Verify the field mappings match the EventBridge event format. CloudWatch events routed through EventBridge use the detail.* prefix:
  • Title: detail.alarmName (not AlarmName)
  • Severity: detail.state.value (not NewStateValue)
  • Description: detail.state.reason (not NewStateReason)
If you previously used SNS, update the field mappings to the EventBridge format.
  • Ensure the event pattern uses "detail-type": ["CloudWatch Alarm State Change"] (exact string, case-sensitive)
  • Ensure the rule is on the default event bus — CloudWatch sends events to the default bus
  • Verify the alarm is in the same region as the EventBridge rule
  • 401/403: Verify the EventBridge connection’s API key value matches the webhook’s secret key, and the key name is x-api-key
  • 422: The payload format may not match expected field mappings — check the event payload structure
  • 429: You’ve exceeded the webhook rate limit — increase the rate limit in CloudThinker webhook settings

Alternative: SNS route

CloudThinker also supports receiving CloudWatch alarms via SNS, which is useful if you already have SNS topics configured for your alarms. Add your CloudThinker webhook URL as an HTTPS subscription on the SNS topic. CloudThinker confirms the subscription automatically within seconds and unwraps the SNS envelope to extract the alarm payload.
The EventBridge route is recommended over SNS because it provides a cleaner event format, native filtering, and no subscription handshake.

Webhook Integrations Overview

Learn about all supported platforms and general webhook configuration.

Root Cause Analysis

Review how an eligible CloudWatch Incident can start automatic RCA.