How do I tie CloudWatch alarms to the right service?

Tares ties a CloudWatch alarm to a service through the primary label on a webhook source. Map the alarm’s detail.alarmName field to the same primary label your metrics and logs carry, such as service, and the alarm lands on that service’s timeline. CloudWatch reaches Tares through the webhook connector and an EventBridge setup, because Tares has no connector of its own for CloudWatch today.

How it works

Tares builds one timeline per entity, and the primary label picks the entity. Every source that carries the same primary label, with the same value, merges onto the same timeline. That is how metrics, logs and alerts for one service end up on a single clock. The AI SRE guide builds this end to end.

For CloudWatch, the path is:

• A CloudWatch alarm changes state and EventBridge emits a CloudWatch Alarm State Change event.
• An EventBridge rule sends that event to an API destination that points at your Tares ingest URL.
• A webhook source in Tares stores the JSON body lossless and applies the labels you declare.

The event carries source and detail-type as top-level fields. The alarm name sits one level down at detail.alarmName. Tares labels read one-level dotted fields, so detail.alarmName works directly as a label field. The state sits two levels down at detail.state.value, which a label or a text template cannot read as it is.

The join only works when the values match. If your metrics carry service with the value checkout, the alarm’s detail.alarmName has to be checkout too. Name the alarm after the service, or keep the service name as the alarm name, so the two sides agree.

Set it up

1. In Tares, create a webhook source (Sources, Add source, webhook) and declare the labels. Use the same primary label name your metrics and logs sources use. This example reads service from the alarm name and keeps the event source as a second label:

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

2. Save the source and copy its ingest URL 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. Choose API key authorization with the 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. Check the mapping before you rely on it. Use test_source with a sample payload, or let an alarm fire and open Recent events on the source. Fields shows which payload fields arrive and how often, so you can confirm that detail.alarmName carries the value your other sources use.

If you also want the alarm state as a label or in the text template, flatten it first. Add an input transformer on the rule target that lifts detail.state.value to a top-level field. Then declare a label for that field. Without the transformer the state stays in the stored payload, but it is not available to labels.

Do not route the alarm through an SNS topic with an HTTPS subscription. That route cannot send a custom header, and its subscription confirmation message would never be confirmed, so it does not fit. Use EventBridge with an API destination.

What you get

• Each alarm event lands on the timeline of the service named by its primary label, next to that service’s metrics and logs.
• A reader, whether you in Explore or an agent through MCP, sees “alarm fired at 14:04, errors started at 14:03” in one correlated read, with no joining by hand.
• The full CloudWatch event is stored lossless, so fields you did not label are still there when you need them.
• Triggers that watch the sources keyed by the same label can wake an agent per service when an alarm event arrives.
• Alarms that share a service name share a timeline, so a second alarm for the same service joins the first without any new setup.

When something else fits

• If your alarm names do not match the service values on your metrics and logs, the timelines will not join. Align the names first, or the alarm becomes its own entity.
• If you already run Prometheus or Alertmanager for alerting, the prometheus_alerts or alertmanager connectors keep that path and give you labels straight from alert labels, with no EventBridge hop.
• If you only need a quick look at one alarm, the stored event on the source page is enough, and you can skip the label design until you want the join.

Related