What should CloudWatch alarms about a cron job that stopped include for an AI SRE?

Tares gives an AI SRE the most to work with when a stopped cron job alarm carries an alarm name, a state with its reason, a time, and a service label you set on the source. CloudWatch alarms reach Tares through the webhook connector and an EventBridge setup, because Tares has no connector of its own for CloudWatch today. The alarm event supplies the name, state, reason and time. You supply the service name on the Tares source so the alert lands on the right timeline.

How it works

An EventBridge rule on the default event bus matches the CloudWatch alarm state change events and posts each one as a JSON body to an API destination. That destination points at the ingest URL of a Tares webhook source. The webhook connector parses the body whatever the Content-Type and stores it lossless.

The event carries these fields:

• detail.alarmName, the alarm that fired. It works as a one-level dotted label.
• detail.state.value and detail.state.reason, the new state and why CloudWatch changed it. These are two levels deep, so they are not usable as labels or in text_template until you flatten them.
• time, region, account and resources, which identify when and where the alarm fired.
• source and detail-type, top-level fields that identify the kind of event.

The event has no service name field and no severity field. The service name is what lets an agent tie the alarm to evidence. In the AI SRE setup, sources that carry the same service label merge into one timeline per service, with metrics, logs and alerts on one clock. A stopped cron job alarm that carries a service label lands next to that service’s logs and metrics, and the agent reads them together.

Because one webhook source carries one fixed service name, create one source per service. Name each alarm after the job, since the alarm name becomes a label and shows the agent which job stopped.

Set it up

1. In EventBridge, create an API destination whose endpoint is the Tares ingest URL and whose method is POST. The endpoint must be public HTTPS.
2. 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 only matters when Tares has auth on.
3. 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.
4. In Tares, add a webhook source (Sources → Add source → webhook) with a primary service label, a label for the alarm name, and the event time read from the time field:

- name: cron-alarms
  connector: webhook
  config:
    event_time_field: time
    labels:
      - { name: service, const: billing-cron, primary: true }
      - { name: alarm, field: detail.alarmName }

5. If you want the state value or the reason as a label or in text_template, add an input transformer on the rule target that flattens them to top-level fields. Fields two levels deep do not map directly.
6. Copy the ingest endpoint from the source page into the API destination. When an alarm fires, open the source page and check Recent events and Fields. They show which payload fields arrive and how often, so you can confirm the labels map.

Do not route the alarm through an SNS action instead. An SNS HTTPS subscription cannot send a custom header, and its SubscriptionConfirmation message would never be confirmed, so it does not work with this source.

What you get

• Each alarm event stored lossless on the source, so the full payload, including the state reason, stays available to the agent.
• A service label that places the alarm on that service’s timeline, next to the logs and metrics the agent already reads.
• An alarm label that names the cron job that stopped.
• An event time taken from the time field, so the agent can order the alarm against deploys and errors on the same clock.
• The state value and reason, once flattened, available in labels and in a text summary built with text_template.
• A source you can use in a trigger, so the alarm wakes an agent with the correlated timeline.

When something else fits

• If your alarms already flow through Alertmanager, the alertmanager connector makes one event per alert and may fit better than the EventBridge route.
• If you can have the cron job itself post a flat JSON object with its service name and a summary, the webhook connector takes that directly and you skip the input transformer.

Related