Technical summary
How should Retention days setting (auto-delete older logs) + manual cleanup button be configured in Aegisify WAF, and what is the current default? provides security telemetry and forensic context for inspected, logged, challenged, rate-limited, blocked, and operational events across WAF subsystems. This article is grounded in the supplied Aegisify WAF 1.20.13 plugin package. It documents current behavior and defaults rather than relying on older FAQ wording.
Where administrators configure or verify it
Primary wp-admin path: wp-admin → Aegisify WAF → Logs. Exact controls can be distributed across the related tab/page when the feature is composed of multiple engines.
Current 1.20.13 defaults and related controls
The table below lists settings in the supplied current source that are directly related to this topic. The current default/bound/status shown is code-derived. Where the product does not define a named Medium preset, the shipped default is documented as the baseline operating point rather than inventing a value.
| Setting | Current default / bound / status | Why this default | How to tune safely |
|---|---|---|---|
logs.flat_file_retention_days |
7 | The shipped value of 7 is the current storage/forensics baseline, balancing historical visibility against database or filesystem growth. | Increase for longer forensic/compliance history at the cost of more storage; decrease to control growth, understanding that older evidence will be unavailable sooner. |
logs.retention_days |
30 | The shipped value of 30 is the current storage/forensics baseline, balancing historical visibility against database or filesystem growth. | Increase for longer forensic/compliance history at the cost of more storage; decrease to control growth, understanding that older evidence will be unavailable sooner. |
logs.dashboard_window_days |
7 | The shipped value of 7 is the current timing baseline used to balance responsiveness, user impact, and processing overhead. | For the same event limit, a longer accumulation window or lockout/cooldown usually increases protection and user disruption; a shorter interval resets sooner. Tune together with the corresponding event threshold. |
logs.alert_rule.minimum_events_default |
3 | The shipped value of 3 is the exact current default encoded by the plugin and should be treated as the baseline unless site evidence supports a change. | For abuse/rate thresholds, a lower number is generally more aggressive and can stop attacks sooner but may affect legitimate bursts; a higher number is more tolerant but allows more activity before intervention. Change incrementally and validate against logs. |
logs.alert_rule.minimum_events_max |
Maximum: 100 | 100 is the current code-enforced maximum/capacity boundary for this control, not a normal operating default. | Do not treat this cap as a target. Operate below it unless the legitimate site requirement needs more capacity; reaching the cap means the current implementation will clamp, truncate, stop adding rows, or reject additional input depending on the control. |
logs.alert_rule.minimum_events_min |
Minimum: 2 | 2 is the current code-enforced minimum boundary, not a recommended default. Values below it are clamped or rejected by the current save path. | Do not tune below this boundary. Adjust the corresponding primary setting at or above this minimum and validate legitimate traffic/workload. |
logs.include_operational_events |
ON / true | Enabled in the shipped baseline because the control provides broadly useful visibility, validation, compatibility, or protection without requiring a site-specific value. | ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. |
api_security.audit_log_level |
metadata | “metadata” is the exact shipped value in the current version. It is preserved as the baseline because the plugin code defines it as the default rather than deriving it from the old FAQ text. | Keep the shipped value unless a documented site requirement calls for a different mode or identifier. Validate the change in the feature’s logs/status view and roll back if behavior becomes less reliable. |
Adjustment strategy
Change one control at a time, save it through the product UI, reproduce the legitimate and malicious/test flow, and review the product log/status surface. For enforcement controls, use Monitor/Observe first when normal behavior is uncertain; move to Block only after the signal is reliable. For thresholds, do not jump directly from the default to an extreme unless an active incident requires emergency containment and a recovery path exists.
Operational guidance
Use the feature’s logs and current request evidence as the tuning source. Compare normal traffic with the event that triggered the control, then change only the smallest setting required.
Technical keywords
Aegisify WAF, 1.20.13, archive, audit, auto, button, cleanup, days, delete, event, events, history, log, logging, logs, manual
Source baseline
Verified package: Aegisify WAF 1.20.13. Primary source files: includes/class-aegiswaf-storage.php; includes/class-aegiswaf-ai-security.php; includes/class-aegiswaf-api-security.php; includes/class-aegiswaf-managed-rules.php; includes/ddos/class-aegiswaf-ddos-storage.php; includes/admin/pages/class-aegiswaf-page-waf-rules.php; includes/admin/pages/class-aegiswaf-page-logs.php; includes/admin/pages/class-aegiswaf-page-access.php. If a future plugin version changes these settings, support should re-read the installed version rather than carry these defaults forward automatically.