What does an event from CloudWatch alarms look like once it reaches Tares?

Tares stores a CloudWatch alarm as one event that keeps the full EventBridge JSON lossless, with labels and text mapped from the fields you declare. CloudWatch reaches Tares through the webhook connector and an EventBridge setup, because Tares has no connector of its own for CloudWatch today. Top-level fields such as source and detail-type, and one-level dotted fields such as detail.alarmName, work as labels. Deeper fields need flattening first.

How it works

EventBridge posts each alarm state change to your Tares ingest URL as a JSON body. The webhook connector parses it whatever the Content-Type and stores the payload lossless. The event you see in Tares has three parts:

• Payload. The whole EventBridge event stays intact. It has version, id, detail-type (CloudWatch Alarm State Change), source (aws.cloudwatch), account, time, region, resources and a detail object. Inside detail you find alarmName, state with its value and reason, previousState and configuration.
• Labels. You declare which payload fields become labels and mark one as primary. Top-level fields work directly. A one-level dotted field such as detail.alarmName also works. detail.state.value is two levels deep, so it does not work as a label or in text_template until you flatten it with an input transformer on the rule target.
• Event type and text. Without extra settings the event type is webhook_event. Set event_type_field to a top-level field such as detail-type to read the type from the payload. The text_template setting reads top-level fields only.

One EventBridge delivery is one event. If you want one event per alert from an Alertmanager-style batch, the Alertmanager connector does that, but CloudWatch uses the webhook route.

Set it up

1. Create a webhook source. Ask a connected agent to create one, or use Sources, Add source, webhook. Declare the labels you want and mark one primary. This example reads the event type from detail-type and maps the alarm name, account and region:

- name: cloudwatch-alarms
  connector: webhook
  config:
    event_type_field: detail-type
    labels:
      - { name: alarm, field: detail.alarmName, primary: true }
      - { name: account, field: account }
      - { name: region, field: region }

2. Copy the ingest endpoint from the source page. EventBridge must be able to reach it, so it has to be public HTTPS.
3. In EventBridge, create an API destination whose endpoint is the Tares ingest URL and whose method is POST.
4. Give the API destination a connection, which EventBridge requires on every API destination. Use API key authorization with header name Authorization and the value Bearer followed by an ingest-scoped API key. The key only matters when Tares has auth on.
5. Create a rule on the default event bus that matches source aws.cloudwatch and detail-type CloudWatch Alarm State Change. Set the API destination as the rule’s target.
6. If you want the alarm state as a label or in text_template, add an input transformer on the rule target that flattens detail.state.value to a top-level field, then declare a label for it.
7. Check the mapping. Post a sample payload to the ingest endpoint, then read Recent events and Fields on the source page. Fields shows which payload fields arrive and how often, which helps you pick a reliable primary label.

curl -X POST http://localhost:8787/ingest/<ingest_key> \
  -H 'Content-Type: application/json' \
  -d '{"action": "deploy", "sender": "ci", "pipeline": "web"}'

The curl call is the generic webhook test. Real alarm events come from the EventBridge rule.

What you get

• Every alarm state change that matches your rule arrives as an event with the complete EventBridge payload preserved, including detail.state and previousState.
• Labels such as the alarm name, account and region let Tares correlate alarms with your other sources and key them to an entity.
• Fields shows what your alarms actually carry, so you can promote more labels later without losing anything already stored.
• The alarm events are available to the rest of your setup. See AI SRE for how Tares uses events across sources.

When something else fits

• CloudWatch alarm actions that publish to SNS do not fit. An SNS HTTPS subscription cannot send a custom header, and its SubscriptionConfirmation message would never be confirmed. Use the EventBridge route above.
• If your alerts already pass through Alertmanager, use the Alertmanager connector for one event per alert with firing and resolved status.
• To pull data from an API instead of receiving pushes, the http_poll connector or OTLP are other routes.

Related