Does Tares need a public URL to receive CloudWatch alarms?

Yes, Tares needs a public HTTPS address to receive CloudWatch alarms, because EventBridge pushes each alarm to a Tares ingest URL that it must be able to reach. CloudWatch alarms reach Tares through the webhook connector and an EventBridge setup, since Tares has no connector of its own for CloudWatch today. A local Tares on http://127.0.0.1:8787 is not reachable from AWS, so put Tares behind a public HTTPS hostname first.

How it works

Tares sources either pull or push. A polled source, such as prometheus_alerts or http_poll, reaches out from Tares to the system on an interval, so Tares only needs to reach that system. A pushed source works the other way: the sender posts to a Tares ingest URL, so the sender must be able to reach Tares.

CloudWatch alarms are a push case. EventBridge calls an API destination, and its endpoint must be public HTTPS. The path looks like this:

• A CloudWatch alarm changes state and EventBridge emits an event with the detail-type CloudWatch Alarm State Change.
• A rule on the default event bus matches source aws.cloudwatch and that detail-type, and targets the API destination.
• The API destination POSTs the event as a JSON body to /ingest/ followed by the ingest key of a webhook source.
• Tares parses the body whatever the Content-Type and stores the payload lossless.

CloudWatch alarm actions that publish to SNS are a different route and do not fit. An SNS HTTPS subscription cannot send a custom header, and its SubscriptionConfirmation message would never be confirmed.

Set it up

1. Make Tares reachable over public HTTPS. The deployment guide shows a server setup with a compose file and a Caddy reverse proxy. Set TARES_DOMAIN to a real hostname, point its DNS A record at the host, and Caddy enables automatic HTTPS. The console is then at your domain over HTTPS, and ingest is served on the same hostname.
2. Create a webhook source in Tares under Sources → Add source → webhook, or ask a connected agent to create it. Declare a label per payload field you want to correlate on and mark one primary. detail.alarmName works as a one-level dotted label, and detail-type is a top-level field, so it can be the event type field.

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

3. Copy the ingest endpoint from the source page. Its path is /ingest/ followed by the ingest key.
4. In EventBridge, create an API destination whose endpoint is that public HTTPS ingest URL and whose method is POST.
5. 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, but EventBridge asks for a connection either way.
6. Create a rule on the default event bus that matches source aws.cloudwatch and detail-type CloudWatch Alarm State Change, and set the API destination as its target.
7. Check the source first with a test post, then watch Recent events for a real alarm change:

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

detail.state.value is two levels deep. If you want it as a label or in text_template, flatten it with an input transformer on the rule target.

What you get

• CloudWatch alarm state changes land in Tares as events, with the full EventBridge payload kept lossless.
• Labels on fields such as detail.alarmName let you correlate an alarm with the rest of your signals and use it in triggers, as described in AI SRE.
• The Fields view on the source shows which payload fields arrive and how often, so you can pick a reliable key.
• A clear boundary: AWS reaches Tares over public HTTPS, while Tares itself can stay a single taresd with one data volume.

When something else fits

• If you cannot expose Tares publicly, use a polled source such as http_poll against an API instead, because polling starts from Tares and needs no inbound route.
• If your alarms already flow through Prometheus or Alertmanager, the prometheus_alerts poller or the alertmanager connector may fit better than adding an EventBridge rule.

Related