Acknowledge Axis alarms without treating acknowledgment as event deletion

Bottom line: Treat acknowledgment as an alarm-workflow transition, not as a deletion instruction. Confirm the event-history requirement independently before allowing an operator interface to describe an acknowledged alarm as erased.

Source fact: documented behavior

Axis’s Event logger service says alarms are stored in a separate alarm log and also in the event log; acknowledgment removes an alarm from the alarm log while keeping it in the event log.

When an event matches both an ignore filter and an alarm filter, the documented outcome marks it as an alarm and stores it in the event log, overriding the ignore filter.

For the documented alarm filters, omitting controller UUIDs applies the filter to all controllers, while supplied UUIDs limit elevation to events from those controllers.

What the source does not establish

Do not infer permanent retention, tamper resistance or a regulatory deletion outcome from acknowledgment behavior. Confirm the exact controller, service and software scope before applying this model. Avoid extending a filter to every controller merely to simplify a test, and do not use a real security incident as a disposable test event.

Applicability questions

• Which interface presents active alarms and which retrieves historical events?
• Does the operator’s acknowledge label accurately describe the intended operation?
• Which exact controller identities should each alarm or ignore filter cover?
• What separate retention and deletion requirements govern the event history?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends accepting the alarm lifecycle and historical-event lifecycle as separate checks.

1. Define a harmless, identifiable test event in an authorized nonproduction or isolated commissioning scope. Record its expected controller identity and the intended filter match. Export or document the current filters before changing them. Specify the wording that the operator should see when acknowledging the test alarm, and keep data-retention policy outside that button’s assumed meaning.
2. Generate the approved test input and capture the active-alarm and historical-event views before acknowledgment. Acknowledge through the supported interface, then inspect both views again. Compare the same event identity rather than counting rows alone. Record a missing historical entry, an unexplained duplicate or a scope mismatch as an unresolved result requiring investigation.
3. Where filter precedence matters to the design, prepare a separate controlled case that deliberately matches both proposed filter classes. Keep its controller scope explicit. Compare the observed alarm and event records with the documented precedence. Restore the approved filters after the exercise and have the operator owner review both the interface wording and the resulting history.

Verification and evidence

Retain sanitized filter definitions, controller identities, the test-input description and paired before/after records. Preserve acknowledgment time separately from event time. Have a reviewer locate the same historical record after the acknowledgment step instead of accepting a screenshot of an empty active-alarm list as the entire result.

For the proposed overlap case, retain enough filter detail to explain why both matches were expected and which controllers were in scope. Do not claim a general retention period from that one exercise. Resolve any disagreement between active alarms, historical events and the operator’s display before adopting the workflow.

Official references

• Event logger service — Axis Communications; official VAPIX documentation.

Source review completed October 29, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.