How do I use the Codex CLI to investigate CloudWatch alarms with Tares?

Tares lets the Codex CLI investigate CloudWatch alarms: you connect Codex over MCP and ask about the service that alerted, and it reads the alarm with the evidence around it. CloudWatch alarms reach Tares through the webhook connector and an EventBridge setup on the AWS side. Tares has no connector of its own for CloudWatch today. Once the alarm is a labelled event on the service’s timeline, Codex gets it in the same read as the logs and metrics for that service.

How it works

• CloudWatch to Tares. An EventBridge rule matches CloudWatch alarm state changes and sends each one through an API destination to the ingest URL of a Tares webhook source. The webhook connector stores the JSON payload lossless.
• Labels tie the alarm to a service. The source carries a service label that every event it receives gets, plus an alarm label read from detail.alarmName. Other sources you label with the same service value land on the same timeline.
• Codex reads over MCP. Codex connects to the Tares MCP endpoint and discovers the Tares tools. When you ask about a service, it calls read with a label selector such as service set to checkout. It gets a correlated, time-ordered timeline across all matching sources, so the alarm arrives with the logs, metrics and findings around it.

See Connecting agents (MCP) for the full tool list and the webhook connector page for the source options.

Set it up

1. Start Tares and the MCP endpoint. Locally, the daemon alone does not serve /mcp, so run the MCP server as a second process.

   tares up
   tares mcp --transport streamable-http

2. Create a webhook source for the service. Add it under Sources, or ask a connected agent to create it. Copy the ingest URL from the source page.

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

   detail.alarmName is a one-level dotted field, so it works as a label. detail.state.value is two levels deep. If you want the alarm state as a label or in a text template, flatten it with an input transformer on the rule target.

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 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. Connect Codex to the MCP endpoint. Keep --url before the URL, because a bare URL registers a stdio server.

   codex mcp add tares --url http://localhost:8788/mcp

   For a secured instance or Tares Cloud, put an API key with the read scope in an environment variable and let Codex send it as the bearer token:

   export TARES_API_KEY=<api-key>
   codex mcp add tares --url https://<your-host>/mcp \
     --bearer-token-env-var TARES_API_KEY

7. Verify the connection, then ask about the service that alerted:

   Use tares: what are you ingesting right now?

   Use tares: what happened to checkout in the last 15 minutes?

   Codex calls catalog_list for the first question and read for the second. The alarm event appears in the answer next to whatever other sources you labelled with service set to checkout.

For a wider picture of the incident loop, with triggers that wake an agent for you, see Build an AI SRE.

What you get

• Each CloudWatch alarm state change is stored as an event on the service’s timeline, with the full EventBridge payload kept intact.
• Codex answers from one correlated read instead of from the alarm text alone. The alarm, logs, metrics and findings for the service sit on one clock.
• You can ask follow-up questions in the same Codex session, such as when the alarm fired and what else changed for the service.
• The read calls show up in the console under Reads, tagged client = mcp, so you can see what Codex looked at.
• Codex can write back what it learns. The remember and record_finding tools store an observation or a finding, so the next investigation starts from it.

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 rule and API destination above.
• If you want Tares to wake an agent when an alarm arrives instead of asking Codex yourself, add a trigger and follow Build an AI SRE.
• If your metrics or logs already flow through OTLP or another source, label them with the same service value so Codex sees them next to the alarm.

Related