Build CloudWatch composite alarm configurations combining multiple alarms with AND/OR logic and action suppression.
Output will appear here...The tool validates alarmName is present, childAlarms contains at least two entries, and constructs the AlarmRule boolean expression joining each child alarm's ALARM() state with the selected AND/OR operator, then layers in InsufficientDataActions-equivalent suppressor logic if a suppressor alarm and wait period are provided, mirroring the fields CloudWatch's PutCompositeAlarm API expects.
Build a CloudWatch composite alarm that combines multiple child alarm states with AND/OR logic into a single higher-level alarm, plus an optional AlarmRule-based suppressor that mutes the composite's actions during a known condition (like an active maintenance window) without touching any of the underlying child alarms. A composite alarm's own actions fire based on the combined boolean result of its child alarms, not by re-evaluating raw metrics itself, so it's the right tool for 'page only if CPU AND latency AND error-rate are all unhealthy simultaneously' correlation, cutting single-metric-flap noise that would otherwise page on any one alarm independently.
AND logic across genuinely independent failure signals (CPU, latency, errors) is the highest-value use of composite alarms, cutting single-metric noise, don't default to OR logic just because it seems more cautious, OR just reproduces the same alert-fatigue problem the composite alarm is meant to solve.
A suppressor alarm's own alarm/OK transitions are themselves worth monitoring, if the maintenance-window alarm that suppresses your critical composite gets stuck in ALARM state longer than intended, you've silently suppressed real incident notifications without realizing it.
Separate AlarmActions and OKActions destinations prevent 'recovered' notifications from cluttering the same channel used for actual pages, route them differently so on-call channels stay signal-heavy.
Practically, yes, a composite alarm combining just one child alarm with AND or OR logic adds no correlation value over watching that single alarm directly, defeating the purpose. The tool enforces a minimum of two child alarms for exactly this reason, since a composite alarm's entire value proposition is correlating multiple independent signals.
It suppresses the composite alarm's own actions (notifications, auto-scaling triggers, etc.) while the suppressor alarm is in ALARM state, it does NOT change the composite alarm's displayed state or stop it from being marked ALARM/OK based on its child alarms. This distinction matters: the composite alarm can still show as ALARM in the console during a suppression window, it just won't fire its configured actions, useful for maintenance windows where you still want visibility but not pages.
Neither directly, INSUFFICIENT_DATA is treated as a distinct state that composite alarm rules can reference explicitly (via ALARM(), OK(), or INSUFFICIENT_DATA() functions in the underlying AlarmRule expression), a composite alarm built with a simple AND of ALARM() conditions across children won't fire just because one child has insufficient data, it needs the referenced children to actually be in ALARM state specifically.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.