Whose email address is on your AWS root account? For many small SaaS companies the honest answer is a co-founder who left, or the agency that set everything up three years ago. That inbox is where AWS sends billing notices, security warnings and account recovery codes.

The other common failure is the opposite one. Alerts reach a Slack channel, but there are so many false alarms that the channel gets muted. I have seen a team get dozens of false alarms in one afternoon, followed by a real database crash. Nobody noticed, because by then the channel was background noise.

Different symptoms, same problem. An alert only works if a named person sees it and knows what to do.

Why it happens

Alerting is set up on day one and never revisited. Someone creates an SNS topic, subscribes an email, and points a few CloudWatch alarms at it. Staff change. The address becomes a shared mailbox that nobody opens, or belongs to a person who no longer works there.

Noise has a similar origin. Alarms are created with default thresholds and a single data point, so every brief CPU spike fires. After a week, people stop reading.

The cost is slow detection. You find out about outages from customers, and about a compromised account from the bill.

How to check your own account

Start with who AWS can reach. In the console, open the Account page and check the root email address and the alternate contacts for billing, operations and security. The contact details and alternate contacts are also available from the CLI:

aws account get-contact-information
aws account get-alternate-contact --alternate-contact-type BILLING
aws account get-alternate-contact --alternate-contact-type OPERATIONS
aws account get-alternate-contact --alternate-contact-type SECURITY

Next, look at who receives your alarms. List every SNS subscription:

aws sns list-subscriptions \
  --query 'Subscriptions[].[TopicArn,Protocol,Endpoint,SubscriptionArn]' \
  --output table

Read the Endpoint column. Is every address a person who still works for you, or a shared mailbox someone actually reads? A subscription that shows PendingConfirmation in the last column was never confirmed and receives nothing. Subscriptions are per region, so repeat this for each region you use.

Then find alarms that notify nobody:

aws cloudwatch describe-alarms \
  --query 'MetricAlarms[?length(AlarmActions)==`0`].AlarmName'

Also check which alarms are firing right now with aws cloudwatch describe-alarms --state-value ALARM. If many have been in alarm for weeks, nobody is acting on them.

Finally, open Billing and Cost Management, then Budgets, and open each budget. AWS now verifies email recipients added since 30 September 2026 before it sends anything. A mistyped or dead address sits at Pending and the alert never arrives. Addresses added before that date are not rechecked, so an old dead one may still be on your budgets.

Fixing it and keeping it fixed

Ten minutes covers most of the access problem:

  1. Move the root email to a shared alias on your own domain, not a person’s inbox.
  2. Fill in the billing, operations and security alternate contacts.
  3. Confirm every Budgets recipient and every SNS subscription is live.

For noise, split alerts into two tiers. The first tier pages someone: site down, database unreachable, error rate high for several minutes. Send it to a phone, not a channel. The second tier is everything else. It goes to a channel or a daily summary and wakes nobody.

Then tune the alarms. Set the evaluation period and “datapoints to alarm” so a spike that recovers in a minute does not fire, for example 3 out of 5 periods. Choose deliberately how missing data is treated. Delete alarms nobody has acted on in three months.

Finally, write down who is on point and test it. Trigger a harmless alarm once a quarter and see who actually responds.

If you want someone else to own the thresholds and the response, that is the core of ongoing AWS management.