How do I use Claude Code to investigate CloudWatch alarms with Tares?

Tares lets Claude Code investigate CloudWatch alarms by reading the alarm together with the logs and metrics around it in one timeline over MCP. CloudWatch reaches Tares through the webhook connector and an EventBridge setup, and Tares has no connector of its own for CloudWatch today. Connect Claude Code to the Tares MCP endpoint, then ask about the service that alerted.

How it works

• An EventBridge rule on the default event bus matches CloudWatch alarm state changes and sends each one to an API destination. The destination points at your Tares ingest URL.
• A Tares webhook source receives the event and stores the JSON payload lossless. The webhook connector parses the body whatever the Content-Type.
• The source carries labels. A label that has the same name and value as the label on your logs and metrics, such as service, puts the alarm on that service’s timeline.
• Claude Code connects to the Tares MCP endpoint and discovers the Tares tools. The read tool returns a time-ordered timeline across all sources that match a label selector, so the alarm arrives with the evidence around it. The build-an-incident-agent walkthrough in AI SRE shows the same pull path end to end.
• source and detail-type are top-level fields in the event. 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 text_template.

Set it up

1. Start Tares and its MCP endpoint. Locally, the daemon alone does not serve /mcp, so run the MCP server as a second process. On Tares Cloud or a server deployment the MCP server is already running, and the console’s Connect page shows your endpoint.

   tares up
   tares mcp

2. Create a webhook source for the alarms. Add it under Sources, Add source, webhook, or ask a connected agent to create it. The service label here is a constant. Set it to the value your other sources use for the service, and use one source per service. The alarm label reads the alarm name from the payload.

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

3. Copy the ingest URL from the source page. EventBridge needs it to be public HTTPS.

4. In EventBridge, create an API destination with that URL as the endpoint and POST as the method.

5. Give the destination a connection, which EventBridge requires on every API destination. 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.

6. 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.

7. Connect Claude Code. The default path is the Tares plugin: run /plugin marketplace add glassflow/tares, then /plugin install tares@tares, and give it your MCP endpoint when it prompts. It connects over HTTP, so nothing else needs installing locally. You can also register the endpoint with the claude CLI over MCP. On a secured instance, add the credential described in the authentication section of the agents page.

8. Verify the connection. Ask Claude Code: Use tares: what are you ingesting right now? It calls catalog_list and lists your sources, including the CloudWatch one.

9. Investigate. When an alarm fires, ask: Use tares: what happened to checkout in the last 15 minutes? Claude Code calls read with the service label and answers from the correlated timeline.

What you get

• Each alarm state change lands as one event on the service’s timeline, next to its logs and metrics, so Claude Code reads the alert and the evidence in a single call.
• The full alarm payload is stored lossless. The alarm name, the state reason and the previous state stay available even when you only map a few fields to labels.
• Claude Code starts from the service name instead of from a pile of consoles. You ask in plain language and it works from the correlated read.
• The same setup works from Codex, Cursor and any other MCP client. Only the connect step changes.
• The same timeline is available to a trigger that wakes an agent, if you later want the push side as well as the pull side.

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. Use the EventBridge route above.
• If your alarms already pass through Alertmanager or Grafana Alerting, the alertmanager connector may be the simpler path.
• For metrics that live in CloudWatch itself, an http_poll source against an API, or OTLP, can bring them in. The alarm route only carries state changes.

Related