Did the Alert Recover by Itself, or Was It Closed by a Rule? Reviews Cannot Treat Them as One State

A Review Gets Stuck on One Question

Twenty minutes before the morning meeting, operations lead Xiao Zhou is asked a very specific question: for yesterday afternoon's batch of API timeout alerts, did the service recover, or were the alerts automatically closed by a rule?

He has the alert list and the closure rate. The red dots have disappeared from the list, and several alerts are no longer active. But as the team keeps tracing downward, the room gets stuck: some alerts were closed by the on-call engineer, some were pushed back by recovery events, and a few aggregated alerts were automatically closed after passing the inactivity window.

At this point, "they are all ended" becomes the least useful answer.

What an alert review really needs to trace is not whether the red dot is still there, but why it left the scene.

The Root Cause: The Ending Is Too Coarse

In daily alert handling, many teams first focus on unassigned, pending, and in-progress alerts. That action is reasonable. During on-call response, the scariest thing is an active alert with no owner.

But a review is not an on-call dashboard. A review needs to answer another set of questions:

• Who took over this alert?
• Did anyone make a handling decision?
• Did the system receive a recovery event?
• If there is no recovery evidence, was it only closed by a timeout rule?

If every ended state is compressed into "handled," the closure rate may look good, but the diagnostic value becomes very low. That is exactly the problem Xiao Zhou faces: the list is quiet, but each alert became quiet for a different reason.

One: Manual Ending

First Check Who Took It Over

After an alert enters multi-person collaboration, its state cannot rely on verbal agreement.

If an unassigned alert can be closed directly, the review will not know who took it over. If a pending alert shows as complete without anyone claiming it, the responsibility chain breaks. If an in-progress alert is repeatedly reassigned, it becomes hard to know who made which decision at which stage.

BK Lite Alert Center separates alert states into unassigned, pending, in progress, resolved, closed, auto closed, and auto recovered. State transitions also have clear boundaries: assignment moves an alert from unassigned to pending, claiming moves it from pending to in progress, reassignment moves it from in progress back to pending, closure moves it from in progress to closed, and recovery moves it from in progress to resolved.

Operations with invalid preceding states are rejected. This constraint is not meant to make the process heavy. It prevents alerts from being casually changed into a result that only looks complete.

Manual Closure Needs Operation Records

Manual closure and manual recovery both mean someone made a judgment, but they still need to be read together with operation records.

When an alert is closed, it may mean the fault has been handled, or it may mean the team will not continue following it for now. What Xiao Zhou really needs in the review is not just the words "closed," but when the alert entered in progress, who claimed it, whether it was reassigned, and who finally closed it.

Only when this handling chain is clear does a manual ending have review value.

Two: Auto Recovery

Recovery Is Not Repair

Auto recovery is easy to misunderstand.

It does not mean the platform fixed the fault for the team. It means recovery evidence appeared in the alert chain. After an external alert source is connected, standard events are generated and then aggregated into alerts by fingerprint. Recovery events use external_id to associate with historical creation events. Only when all creation events are covered by later recovery events does the alert enter the auto recovered state.

This means auto recovery answers an event-chain question: were both the abnormal event and the recovery event standardized and sent in, and can the two be associated reliably?

Auto Recovery Helps Inspect Event Quality

If a certain type of alert often auto recovers, Xiao Zhou can continue checking where the recovery events came from, whether they share a stable identifier with creation events, and whether the timing relationship is reasonable.

If a certain type of alert rarely auto recovers, the team should not immediately conclude that frontline engineers failed to handle it. More likely checks include whether the external alert source only reports alert events but not recovery events, or whether field changes prevent recovery events from reliably matching creation events.

Auto recovery is not a root-cause conclusion, but it gives the review an important evidence line.

Three: Auto Closure

A Rule Timing Out Is Not Business Recovery

Auto closure and auto recovery differ by only a few words, but their meanings are completely different.

For aggregated alerts, correlation rules can automatically close alerts based on close_minutes, with scheduled tasks as a fallback. By default, close_minutes is 120 minutes and auto closure is enabled.

This mechanism is necessary. Aggregated alerts are designed to converge similar events into one handling object. If no new events appear for a long time, keeping the alert in the active list only interferes with on-call judgment.

But auto closure does not provide recovery evidence. It only means the aggregated alert met the closure condition defined by the rule.

Frequent Auto Closure Means Rules Need Review

When Xiao Zhou finds that a batch of alerts mainly ended through auto closure, the review direction changes.

At that point, the team should not simply say "the alerts were all handled." It should continue asking:

• Are recovery events missing?
• Is close_minutes too short or too long?
• Did the aggregation rule make similar alerts exit too early?
• Is the reporting logic of the external alert source stable?

One boundary also needs separate attention: instant alerts do not participate in auto closure. Events that hit an instant alert policy directly generate independent alerts. They do not enter the main aggregation path, their event count is always 1, and their lifecycle can only end through manual handling or auto recovery.

Technical Insight: State Is the Language of Review

Alert state is not just a field in a list. It should become the shared language for team reviews.

Review Lens	Corresponding States	Main Question
Active state	Unassigned, pending, in progress	Is the response chain stuck?
Manual ending	Resolved, closed	Did someone make a handling decision?
System recovery	Auto recovered	Is the recovery-event chain reliable?
Rule closure	Auto closed	Are the aggregation rule and closure window reasonable?

This table separates the confusion Xiao Zhou faces. Not every ending is recovery, and not every closure means someone handled it. The clearer the states are, the less the review depends on verbal explanation.

BK Lite's Entry Point

BK Lite Alert Center fills the state-language breakpoint in the alert lifecycle.

Multi-source events are first standardized into events and alerts. The alert list supports filtering by state, severity, source, resource, and time range. Alert details provide context such as original events and nearby alerts. The lifecycle preserves assignment, claiming, reassignment, closure, and recovery, while also preserving auto recovery and auto closure.

These capabilities are not there to add a few more labels to the page. They make sure every alert has an explainable path from entering the scene to leaving it.

For a review, that path is more valuable than a total closure rate.

Questions to Ask Before Using It

To make alert states truly useful, teams can first check these questions:

• Does the on-call dashboard distinguish unassigned, pending, and in-progress alerts instead of only showing the total alert count?
• Can manual closure and manual recovery be traced to the handler and time in operation records?
• Does the external alert source report both alert events and recovery events?
• Can recovery events associate with historical creation events through a stable identifier?
• Is the auto-closure ratio too high, and should the closure window and aggregation rules be reviewed?
• Are instant alerts being misunderstood as aggregated alerts, leading people to assume they can also be automatically closed?

These questions do not require turning alert governance into a large project all at once, but they help the team first establish a reviewable state language.

Conclusion

Alerts eventually end, but the reasons for ending cannot be flattened.

Manual closure means someone made a judgment. Auto recovery means the event flow contains recovery evidence. Auto closure means the rule reached its fallback condition. Once these three are separated, the team can know whether the next improvement should focus on response process, event reporting, or correlation rules.

What a review needs is not "the red dot disappeared," but a lifecycle that can be clearly explained.