The CJA Alert Manager: reviewing and triaging what fired

When you need this

Every organization with more than one or two live alerts needs a standing habit of reviewing the Alert Manager, not just reacting to individual notification emails as they land - a single view of every active alert, its recent trigger history, and its current status is what lets you tell "this alert is healthy and quiet" from "this alert has been silently misfiring for a month and everyone stopped reading the emails."

It's also the tool for the specific moment an alert notification arrives: before escalating, the Alert Manager's detail view is where you confirm what actually happened - the metric's value, the threshold or expected range, and the exact time window - rather than acting on the headline of the notification alone.

How to work with it correctly

1. When an alert fires, open its detail view before escalating anywhere. Confirm the actual metric value against the threshold or expected range, the exact time window the anomaly covers, and whether the underlying data view has any known collection gaps for that period - a genuine tracking outage can trip a business-metric alert for reasons that have nothing to do with the business.

1. What triggered: metric value vs. threshold/expected range
2. Time window: exact start/end of the flagged period
3. Scope: which data view, segment, dimension breakout
4. Cross-check: any other alert on a related metric firing at the same time?
   (a shared cross-metric spike usually points at a tracking issue,
    not five unrelated business problems at once)

2. Review the alert's trigger history periodically, not only when it fires. A pattern of frequent, low-severity triggers is a signal the threshold or sensitivity needs retuning (see the Alert Builder guide) - waiting for someone to complain about noise is slower than catching it in a scheduled review.

3. Close the loop on every trigger with a documented outcome. Real issue found and fixed, false positive with threshold adjusted, or known cause with no action needed - each of those is a different outcome, and recording which one applied is what makes the Alert Manager's history useful the next time a similar alert fires.

4. Retire alerts that no longer serve a decision. A metric the business stopped tracking, or an alert whose owner left and was never reassigned, should be disabled rather than left to fire into an unmonitored inbox - a stale alert is worse than no alert, because its false confidence ("we'd know if something broke") is actively misleading.

How to verify it worked

• Cross-reference a fired alert's flagged window against Analysis Workspace directly - the numbers in the Alert Manager's detail view should match what Workspace shows for the same data view, segment, and dates.
• If the trigger was a tracking issue, confirm the fix by watching the same alert stay quiet through its next scheduled evaluation after the tag or pipeline fix ships.
• Every alert in the Manager has a status and a recent trigger record someone can explain in one sentence - an alert nobody can currently explain the last trigger of is a candidate for the retuning-or-retire review, not something to leave as is.

Illustrative, not a measured result: a monthly Alert Manager review might surface that two alerts on related checkout metrics always fire together, prompting a merge into one alert with a clearer combined signal instead of two separate notifications every time.

Alert Manager's status labels and trigger-history retention vary by CJA release - verify current behavior against Adobe's own documentation.

FAQ

Who should have access to review the Alert Manager?

At minimum, whoever owns each alert's assigned metric - but a periodic cross-review by someone who sees the whole alert set (not just their own) is what catches redundant or conflicting alerts that no single metric owner would notice on their own.

Can a triggered alert be silenced temporarily without deleting it?

Yes - alerts can typically be paused or have their notification suppressed for a known period (a planned migration, a scheduled maintenance window) without losing the underlying configuration, which is the right move for a known, temporary cause rather than permanently deleting a healthy alert.