# Weekday Slack triage digest for firing CloudWatch alarms

> Every weekday at 8am, we group your firing CloudWatch alarms, flag flappers and overnight fires, and post a triaged digest to your Slack ops channel.

- Workflow type: agent
- Services: Amazon CloudWatch, Slack Bot
- Categories: Engineering, Operations
- Published: 2026-07-17

## What it does

- Pulls every CloudWatch alarm currently in ALARM state so you only look at what is actually firing
- Reviews each alarm's recent history to spot fresh overnight fires and noisy flappers
- Groups related alarms by service or dimension so the picture is coherent, not a wall of noise
- Posts a Slack digest to a single ops channel with a 'what to look at first' section right at the top

## What you'll need

- An AWS account with read access to CloudWatch alarms
- A Slack workspace and one ops channel where the digest should land

## Prompt

Every weekday at 8am, pull my currently firing Amazon CloudWatch alarms, reason about them as a set, and post a triaged digest into a single Slack ops channel. The goal is a short, prioritized morning read, not a raw dump.

Start by calling Amazon CloudWatch's Describe Alarms with StateValue set to ALARM to get every alarm currently in the ALARM state. If nothing is firing, post a one-line 'all clear' message to the Slack ops channel using Slack Bot's Send a Message and stop. Do not invent problems.

For each firing alarm, call Amazon CloudWatch's Describe Alarm History with a 24-hour lookback and item type set to state update. Use the history to work out three things per alarm: when it first entered ALARM (so I know current state duration), how many state transitions it has had in the last 24 hours, and whether the most recent transition into ALARM happened overnight (roughly between 6pm the previous day and 8am today in the workspace's timezone).

Now reason about the whole list before writing anything. Group related alarms by service or dimension: same namespace, same EC2 instance, same load balancer, same RDS cluster, same Lambda function, and so on. Anything with more than three state changes in the last 24 hours goes into a 'flapping' bucket, since those usually mean a threshold or evaluation window that needs tuning rather than a live incident. Anything that transitioned into ALARM overnight goes into an 'overnight' bucket and is the most urgent. Everything else is 'ongoing'.

Post the digest to the Slack ops channel with Slack Bot's Send a Message. The top-line message text should be a single-sentence summary: total firing, how many are fresh overnight, how many are flapping, and the two or three most affected services. Underneath, list per-alarm detail grouped by service or dimension, with each alarm showing its name, current state duration, number of transitions in the last 24 hours, and its tag (overnight, flapping, or ongoing). End the message with a short 'what to look at first' section, usually the overnight fires, then anything affecting shared infrastructure, then the flappers.

Keep the digest tight. If two alarms clearly describe the same underlying incident (same host, same service, correlated timing), say that once in the summary instead of repeating detail for each. Do not paste raw AWS response fields into Slack.

## How to customize

- Change the schedule if 8am on weekdays does not match your on-call rhythm
- Point the digest at a different Slack channel, or fan out to per-team channels
- Adjust what counts as a 'flapper', for example more than three state changes in the last 24 hours

## FAQ

### What time does the digest post?

Every weekday at 8am in your workspace's timezone. You can change the schedule when you set up the workflow.

### Will it wake me up over stale, ongoing alarms?

No. The digest separates fresh overnight fires from alarms that have been ringing for hours, and calls out the overnight ones as most urgent.

### What if the same alarm keeps flipping in and out of ALARM?

It gets tagged as flapping in a dedicated section, so you can tune the threshold or evaluation window instead of chasing every state change.

### Does this need write access to my AWS account?

No. Read-only access to CloudWatch alarms is enough to pull the list and their state history.

### Can it post to more than one Slack channel?

Yes. Either duplicate the workflow for a second channel, or ask for a channel per team when you customize it.

Use this prompt in General Input: https://www.generalinput.com/prompts/weekday-slack-triage-digest-for-firing-cloudwatch-alarms