Can an AI agent read CloudWatch alarms through Tares and explain them?

Yes, Tares lets an AI agent read CloudWatch alarms and explain them, with the alarms reaching Tares through the webhook connector and a CloudWatch setup in EventBridge. The agent asks Tares for a correlated timeline over MCP and gets each alarm event with its full payload and your labels. The agent needs no CloudWatch connector or AWS credentials, because it only talks to Tares.

How it works

Tares has no connector of its own for CloudWatch today. Alarms arrive through the webhook connector: EventBridge posts each alarm state change as a JSON body to a webhook source’s ingest URL. The connector parses it whatever the Content-Type and stores the payload lossless.

The event carries the fields EventBridge sends:

• detail-type and source, which are top-level fields.
• time, region, account and resources, which hold the alarm ARN.
• detail, which holds alarmName, the state with its value and reason, the previousState and the configuration.

Labels are the part you choose. A label maps a payload field into the event, and detail.alarmName works as a one-level dotted label. detail.state.value is two levels deep, so flatten it with an input transformer on the rule target if you want it as a label or in a text template. Set event_time_field to time so the event is placed on the timeline at the moment of the alarm.

The agent side is the Tares MCP endpoint. Its read tool returns a correlated, time-ordered timeline across all sources that match a label selector. When the alarm shares a label such as service with your logs, metrics and findings, the agent sees them in one read and explains the alarm from that context. The client never talks to CloudWatch, so it holds no AWS credentials and needs no CloudWatch connector. See Connecting agents for the tools and the client snippets, and AI SRE for the wider workflow.

Set it up

1. Start Tares and the MCP endpoint. On a local Tares, run each command in its own terminal:

tares up
tares mcp --transport streamable-http

2. Create a webhook source for the alarms. Add it under Sources, or ask a connected agent to create it, then copy its ingest URL. This example reads the event type from detail-type, the timestamp from time and labels each event by alarm:

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

3. In EventBridge, create an API destination. Its endpoint is the Tares ingest URL, which must be public HTTPS, and its method is POST.
4. Give the API destination a connection, which EventBridge requires. Use API key authorization with the header name Authorization and the value Bearer followed by an ingest-scoped API key. The key value 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 its target. Add an input transformer on the target if you want detail.state.value as a label.
6. Connect your client to the MCP endpoint, http://localhost:8788/mcp on a local Tares. A secured instance needs a read-scoped API key sent as a Bearer header.
7. Ask the agent: “Use tares: which CloudWatch alarms fired in the last hour, and what else changed around them?”

What you get

• Each alarm state change is an event the agent can read, with the alarm name, the new state and its reason, the previous state, the region, the alarm ARN and the time.
• The full payload is kept as sent, so the agent can quote any field, including ones you did not turn into labels.
• The agent can read alarms next to logs, metrics and findings that share your labels, and explain them in one answer instead of switching between tools.
• One MCP connection works for Claude Code, Codex, Cursor and any other MCP client. You can swap clients without touching the alarm setup.
• The AWS side stays in EventBridge. Tares and the agent never hold AWS credentials.

When something else fits

• CloudWatch alarm actions that publish to SNS do not fit this route. An SNS HTTPS subscription cannot send a custom header, and its SubscriptionConfirmation message would never be confirmed, so use an EventBridge rule with an API destination instead.
• If you need metrics rather than alarm events, a polled connector or OTLP fits better. This page covers only alarm state changes.

Related