This post focuses on specific problem in thin AP monitoring: an AP could disappear, the platform could detect it, and yet the intended alert could still fail to complete because the AP was removed from the database before the alert's "must exist for" window had elapsed.
That was the root issue. Detection was happening, but the object lifecycle and the alert lifecycle were not aligned.
AP disappears → alert starts evaluating → AP removed too early → alert never fires.
The precise problem
The original issue was straightforward. If the polling interval was shorter than the alert's "must exist for" duration, a disappeared thin AP could be dropped from the database on the next processing cycle before the alert had enough time to mature.
So this was not only an alert-template issue. It was a timing problem between how long a disappeared AP remained available in the database and how long the alert engine needed to confirm the condition.
Visual: one clock for poll interval and one clock for "must exist for" duration.
How the failure happened step by step
The failure path looked like this:
- on the first poll after the controller stopped reporting the AP, the platform detected the condition and marked the AP as disappeared,
- on the next poll, if the AP still had not reappeared and no retention window existed, the AP could be removed from the database,
- once the AP object was gone, the alert no longer had an object to evaluate against, so the "must exist for" condition could never complete.
A simple timeline makes the problem obvious:
Time | What happens |
|---|
12:00 | The WLC reports the AP normally. |
12:10 | The WLC stops reporting the AP, and the AP is marked as disappeared. |
12:20 | The AP is still absent, but the alert still needs more time to satisfy the "must exist for" condition. |
12:30 | Without the right retention model, cleanup can overtake alert evaluation; with TTL in place, deletion waits until the configured condition is met. |
Visual: a horizontal timeline showing polling rounds and the alert evaluation window.
Why this was tricky in real environments
The older workaround was to disable RemoveDisappearedAPs so the AP would remain in the database long enough for alerting to work. That preserved alertability, but it also left behind ghost APs that then had to be cleaned up manually or by script.
There was also a second layer of complexity in primary-secondary controller environments. An AP disappearing from one WLC does not always mean the AP is actually gone; it may simply have moved from the primary controller to the secondary controller during failover or maintenance.
So the platform needed to do three things at once: keep disappeared APs around long enough for alerting, avoid leaving them around forever, and distinguish a real AP outage from a normal controller transition.
Visual: tradeoff diagram showing "remove too soon" versus "keep forever," with failover as the third variable.
How the fix evolved across releases
The confirmed fix flow came together in two steps:
Release | Fix introduced | Why it mattered |
|---|
2024.2 | Advanced alerts for thin AP disappeared/down scenarios in primary-secondary WLC environments. | This reduced false positives during failover by allowing the secondary WLC to be checked before deciding the AP was truly gone. |
2025.1 | DisappearedAccessPointsTimeToLive was introduced in Advanced Configuration.
| This kept disappeared APs in the database long enough for alerts to mature, without requiring permanent retention. |
The flow matters. First, failover behavior was handled more cleanly in redundant controller environments. Then disappeared APs were retained long enough for alerting to work reliably. The existing out-of-box Thin AP down behavior remains relevant context, but it is not part of the confirmed release-fix sequence in this post.
Fix 1 (2024.2): handle primary-secondary WLC transitions correctly
The first step was to deal with redundant controller environments properly.
In these environments, an AP disappearing from the primary WLC does not necessarily mean it is gone. It may simply have moved to the secondary WLC.
That is why 2024.2 introduced two advanced out-of-box alerts: [Advanced] Thin AP Disappeared from WLC and [Advanced] Thin AP Down.
The mechanics are important:
[Advanced] Thin AP Disappeared from WLC waits for two consecutive poll rounds before triggering, so the secondary WLC has time to be polled before the platform concludes the AP is truly gone.- if the AP disappears from the primary and reappears on the secondary within those two poll rounds, no alert fires.
- if the AP does not appear on either WLC within that window, the alert fires.
[Advanced] Thin AP Down handles state transitions where the AP moves between controllers while still down, clearing the old alert context and creating the new one on the correct controller.
There is also an accompanying setting: TriggerThinApDisappearedEventByCollectorService. If you use the advanced disappeared-from-WLC logic and still see duplicate legacy events, that collector-driven event can be disabled to avoid conflicting behavior.
Visual: two-controller diagram showing AP failover from primary to secondary with a "wait 2 polls" gate.
Fix 2 (2025.1): keep disappeared APs long enough for alerting
The second step came in 2025.1 with DisappearedAccessPointsTimeToLive in Advanced Configuration.
This setting allows disappeared APs to remain in the database for a defined amount of time after the controller stops reporting them. That retention window gives the alert engine enough time to evaluate the condition and satisfy the "must exist for" requirement before cleanup occurs. In practice, TTL should be sized not only to satisfy the alert evaluation window, but also to leave enough time for operators to notice the alert and respond before the disappeared AP is cleaned up.
This was the key change that removed the need to rely on the old "leave disappeared APs around forever" workaround. The recommended model became: keep RemoveDisappearedAPs enabled, and use TTL to provide the alerting window instead.
The resulting behavior is much cleaner:
RemoveDisappearedAPs | DisappearedAccessPointsTimeToLive | Result |
|---|
ON | Not set | The AP is removed on the next processing round after disappearing, so short "must exist for" windows can still be a problem. |
ON | Set | The AP stays in the database until TTL expires, so the alert has time to fire and cleanup still happens automatically. |
OFF | Not set | The AP is never deleted, which preserves alertability but causes ghost AP buildup. |
OFF | Set | RemoveDisappearedAPs=OFF still wins, so APs remain indefinitely and TTL does not solve the ghost AP problem in this mode.
|
Visual: a 2x2 matrix with the preferred quadrant highlighted as ON + TTL set.
How the existing OOB Thin AP down alert fits into the story
The existing out-of-box Thin AP is down alert remains part of the overall alerting model and can be used alongside the newer fixes.
The important context is that the platform's processed thin AP status respects WLC node status, which means controller state can still influence how the AP condition is surfaced.
In practice, that means the confirmed release fixes in scope here are the failover-aware advanced alerts introduced in 2024.2 and the disappeared-AP retention model introduced in 2025.1, while the existing OOB Thin AP is down alert remains an operational building block that should be evaluated against your topology and alerting intent.
For experienced users, the practical takeaway is simple: use the advanced alerts when you need cleaner behavior in primary-secondary WLC environments, and use the existing OOB alert with a clear understanding that processed AP status is not completely isolated from controller status.
Putting the confirmed fixes together
These confirmed changes solve the two main gaps in the workflow:
- 2024.2 handles primary-secondary controller transitions cleanly.
- 2025.1 keeps a disappeared AP in the database long enough for alerting to work.
- The existing OOB
Thin AP is down behavior remains part of the operating model, but it should be understood in the context of processed AP status that can still reflect WLC state.
End to end, the intended model now looks like this:
- The WLC stops reporting the AP.
- The AP is marked as disappeared.
- The AP remains in the database during the TTL window instead of being removed immediately.
- In primary-secondary setups, the advanced alerts add a two-poll confirmation gate before treating the disappearance as genuine.
- Alerting is evaluated with the retained AP state still available, while operators choose between the advanced failover-aware alerts and the existing OOB alert behavior based on topology and intent.
- If the AP does not return, the alert fires and cleanup happens only after the retention window expires.
Visual: one end-to-end flowchart from disappearance to alert to cleanup.
What to change in your environment
For environments using these fixes together, the cohesive configuration is:
Setting or action | Recommended value | Why |
|---|
RemoveDisappearedAPs
| Keep it ON. | Cleanup should stay enabled; TTL now provides the alerting window without requiring permanent retention. |
DisappearedAccessPointsTimeToLive
| Set it to your alert's "must exist for" duration plus operational buffer. | This gives the alert enough time to mature and remain visible long enough for someone to see it and act before cleanup occurs. |
Alert trigger actions | Add email notification where operator visibility is critical. | Even if a disappeared AP is later cleaned up from OSH, the notification still ensures the event is seen outside the UI. |
OOB Thin AP is down alert | Use it as an existing building block in the alerting model, and validate it against your topology and alerting intent. | The underlying processed thin AP status can still reflect WLC node status, so it should be evaluated in the context of controller behavior. |
[Advanced] Thin AP Down and [Advanced] Thin AP Disappeared from WLC
| Enable them for redundant WLC environments. | They prevent failover-related false positives and add the required two-poll confirmation model. |
TriggerThinApDisappearedEventByCollectorService
| Disable it if you use the advanced disappeared alert and still see duplicate legacy events. | This avoids the old collector-driven event conflicting with the newer alert logic. |
For primary-secondary setups, keep the WLC poll intervals aligned and, if possible, monitor both controllers with the same polling engine.
What the desired result looks like
The desired end state is simple:
- a disappeared AP is not removed so quickly that alerting breaks,
- a genuine AP-down condition can be surfaced in a usable alerting model,
- a normal primary-secondary failover does not create false positives,
- and stale AP records do not remain indefinitely just to make alerting work.
That is the real outcome of these changes. Thin AP alerting becomes reliable because retention, alert evaluation, and controller transition handling finally work as one model instead of separate behaviors.
Closing takeaway
The problem was that detection alone was not enough. The platform also needed to retain the AP long enough for alerting, avoid mistaking a controller transition for an outage, and use the existing OOB alert with a clear understanding of how processed AP status relates to controller state.
Once those pieces were aligned, the workflow matched much more closely how experienced wireless operators expect thin AP alerting to behave.
Additional References
