Connecting CloudWatch turns an alarm into a starting point. Instead of paging
someone to go look, WeWatch picks up the alarm and traces it through your
topology to find what caused it and what else it affects.
Requirements
CloudWatch isn’t a separate connection — it’s a capability you switch on for an
AWS account you’ve already connected. So AWS comes
first, and the account has to be healthy. Without one, the setup says so and
stops:
The role also needs CloudWatch read permissions — cloudwatch:DescribeAlarms
and cloudwatch:DescribeAlarmHistory. WeWatch checks for them before enabling
and tells you if they’re missing.
Enable it
Start the flow
Integrations → Add Integration → Alert Integration, then choose
CloudWatch.
Pick the AWS connection
Choose which connected account’s alarms to monitor. Accounts that already
have CloudWatch enabled are shown greyed out — one CloudWatch integration
per account.
Enable
Choose Enable CloudWatch Alarm. WeWatch subscribes to that account’s
alarms; new alarm activity creates incidents automatically.
Monitoring several accounts? Repeat the flow once per AWS connection — each
one is enabled independently.
What happens when an alarm fires
The alarm arrives as an incident. WeWatch investigates it against the live
topology and attaches what it finds — the likely cause, the resources
downstream of it, and recent changes that correlate.
If Slack is connected, your team can ask follow-up
questions about the incident in the channel.
Turning it off
Disabling CloudWatch for an account stops new alarms from creating incidents.
It doesn’t touch the underlying AWS connection — the topology and chat keep
working.
Removing the AWS connection itself also removes its CloudWatch integration.
