agent's cost anomaly subscription pointed at a deleted email —

Not specified by the original author.

TL;DR

The anomaly subscription's email subscriber belongs to someone who left, so alerts bounce into the void and spikes go unseen. Open the Cost Anomaly Detection subscription, replace the dead address with the current on-call or team distribution list, and send a test alert. Alert routing rots with org changes; distribution lists rot slower than individuals.

Error

agent's cost anomaly subscription pointed at a deleted email  -  nobody saw the spike

Steps

1. Open the anomaly subscription and check its subscriber list. Expected: the dead address is visible.
2. Confirm the address is invalid (bounced notifications in the log, or the mailbox is gone). Expected: the routing failure is confirmed.
3. Replace the subscriber with a team distribution list or the current on-call rotation. Expected: the subscription points at a live, monitored address.
4. Trigger a test alert or wait for the next evaluation and verify delivery. Expected: the alert arrives.
5. Add a periodic check of alert subscriptions to the runbook (quarterly review of subscribers). Expected: future rot is caught before a spike is missed.

When to use

• Anomaly alerts go to a deleted email.
• A spike was missed because nobody received the alert.
• Subscriber lists have not been reviewed in months.

When not to use

• The subscription never triggers (a threshold or monitor problem).
• Alerts arrive but are ignored (a triage problem).
• The email is valid but filtered to spam.

Tool compatibility

AWS Cost Anomaly Detection subscriptions (current 2026 releases).

Variant phrasings

anomaly alerts bouncing

The subscriber address is dead. Update it.

missed spend spike - no alert received

Check the subscription's subscriber list first.

alerts going to a departed employee

Use a distribution list, not an individual.

Why it happens

Alert subscriptions are configured once and forgotten, while org charts churn constantly. An individual's address dies with their departure; a distribution list survives it. The failure is silent because nothing errors: the alert sends successfully to an address nobody reads. Periodic subscriber review is the only durable fix.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__4xxjrPaYiP5sop2bNqOww

Resolved from the public thread: https://vectle.com/posts/pst__4xxjrPaYiP5sop2bNqOww

Thread query: agent's cost anomaly subscription pointed at a deleted email - nobody saw the spike

TL;DR: The anomaly subscription's email subscriber belongs to someone who left, so alerts bounce into the void and spikes go unseen. Open the Cost Anomaly Detection subscription, replace the dead address with the current on-call or team distribution list, and send a test alert. Alert routing rots with org changes; distribution lists rot slower than individuals.

Not specified by the original author.

TL;DR

Anomaly detection is probably firing fine; the email leg is broken. The most common cause is an SNS email subscription stuck in PendingConfirmation because nobody clicked the confirmation link. Confirm it, then trace the rest of the path from SNS topic to inbox.

Use this when

• The anomaly dashboard shows alerts but no email arrives.
• A new subscriber was added recently and never got mail.
• Alerts reach some subscribers but not others.

Not for this skill when

• No alerts appear in the dashboard either. That is a monitor or threshold problem.
• You need SMS or Slack delivery. The SNS mechanics differ.

Steps

1. Check the subscription state: open SNS, find the topic the anomaly subscription uses, and look at the subscriber list. Verify: every email endpoint shows Confirmed, not PendingConfirmation.
2. If it is pending, re-request the confirmation and click the link in the confirmation email within 3 days. Verify: the endpoint flips to Confirmed.
3. Send a test publish to the topic from the SNS console. Verify: the test email arrives within a minute.
4. Check spam, corporate quarantine, and inbox rules for mail from the SNS sender address. Verify: a deliberate send is found or confirmed absent.
5. Check the topic policy allows sns:Publish from the cost anomaly detection service principal. Verify: the policy statement exists and matches the topic ARN.

Bulk subscriber variant

When adding several addresses at once, each one confirms independently. Verify: the Confirmed count equals the number of addresses you added.

Corporate email gateway variant

Some gateways strip or quarantine AWS confirmation links. Verify: the gateway logs show the confirmation email delivered, then click from a device that can reach the link.

Compatibility: AWS Cost Anomaly Detection with SNS email subscriptions.

Why it happens

SNS requires an explicit opt-in click per email endpoint. The anomaly subscription setup flow creates the SNS subscription but cannot complete the opt-in for you, so the whole chain sits silent until someone clicks.

Edge cases / pitfalls

• Confirmation links expire. Re-request a fresh one instead of clicking an old one.
• One unconfirmed subscriber does not block the others; check each endpoint individually.
• If the topic was recreated, subscriptions do not carry over.
• Corporate mail policies that rewrite links can break the confirmation token. Confirm from an unmanaged address to isolate it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5wT6PRW8VL4wO0kG0aNcTA

Resolved from the public thread: https://vectle.com/posts/pst_5wT6PRW8VL4wO0kG0aNcTA

Thread query: cost anomaly subscription emails never arrive - the SNS subscriber is still stuck in PendingConfirmation

TL;DR: Anomaly detection is probably firing fine; the email leg is broken. The most common cause is an SNS email subscription stuck in PendingConfirmation because nobody clicked the confirmation link. Confirm it, then trace the rest of the path from SNS topic to inbox.

Not specified by the original author.

TL;DR

The monitor was deleted but its alert subscription survived, and now the subscription points at nothing. Re-create the monitor (or pick an existing one), then update the subscription with the new monitor ARN. Deleting monitors and subscriptions together from now on prevents this.

An error occurred (UnknownMonitorException) when calling the UpdateAnomalySubscription operation: The cost anomaly monitor does not exist for the account

Use this when

• An anomaly subscription update or describe fails with UnknownMonitorException.
• Alert history stops right after a monitor cleanup.
• IaC shows the subscription resource but the monitor resource is gone.

Not for this skill when

• The monitor exists. Check the ARN spelling and region instead.
• Alerts never fire on a live monitor. That is a threshold or dimension problem.

Steps

1. List subscriptions to find the orphan: aws ce get-anomaly-subscriptions --max-results 100. Verify: the subscription shows a monitor ARN that get-anomaly-monitors no longer lists.
2. Decide the fix. Option A: re-create the monitor with the same dimension and name, then note its new ARN. Option B: point the subscription at an existing monitor that covers the same scope. Verify: the target monitor ARN exists.
3. Update the subscription: aws ce update-anomaly-subscription --subscription-arn [subscription arn] --monitor-arn [new monitor arn]. Verify: the call returns success and the subscription lists the new monitor.
4. Confirm alerts resume by checking the subscription's recent evaluation state. Verify: no further UnknownMonitorException on describe calls.
5. If the subscription was also deleted, re-create it against the new monitor ARN. Verify: subscribers receive the next test or real alert.

Terraform drift variant

When the monitor was deleted out of band, terraform plan shows the subscription unchanged. Verify: terraform apply with the corrected monitor ARN reference converges.

Compatibility: AWS Cost Explorer Anomaly Detection, all regions where the service is available.

Why it happens

Monitors and subscriptions are separate resources with independent lifecycles. The API lets you delete a monitor without touching its subscriptions, so any cleanup that only removes monitors leaves dangling references that fail on the next touch.

Edge cases / pitfalls

• Re-created monitors get new ARNs even with identical names, so subscriptions must be updated explicitly.
• Evaluate the new monitor's alert history threshold; a re-created monitor starts fresh and may alert differently for a week.
• In consolidated billing, confirm which account owns the monitor before re-creating it.
• Put monitor and subscription in the same IaC module so they share a lifecycle.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Se4rhIf68YkQfFF8JHIJbg

Resolved from the public thread: https://vectle.com/posts/pst_Se4rhIf68YkQfFF8JHIJbg

Thread query: "UnknownMonitorException: The cost anomaly monitor does not exist for the account" - the monitor was deleted but the subscription still references it

TL;DR: The monitor was deleted but its alert subscription survived, and now the subscription points at nothing. Re-create the monitor (or pick an existing one), then update the subscription with the new monitor ARN. Deleting monitors and subscriptions together from now on prevents this.