Exclusion Rules

Excluded events are dropped before they're written to the database. Use this to silence routine activity that would otherwise crowd your log.

Find it at Logify > Settings > Exclusions.

Available Exclusions

• Excluded User IDs — comma-separated list. Useful for service accounts, bots, or your own admin account during heavy maintenance.
• Excluded User Roles — multi-checkbox list of every role on the site. Tick the ones whose actions you want to ignore. Administrators are usually worth keeping.
• Excluded IP Addresses — one rule per line. Supports:
  • Exact match — 192.168.1.42
  • IPv4 wildcards — 192.168.1.*
  • Trailing-dot prefix — 10.0. matches anything starting with 10.0.
• Excluded Event Types — multi-checkbox over Logify's event categories (user, post, plugin, theme, comment, attachment, term, menu, widget, option, security). Tick whole categories to drop them.
• Excluded Post Types — multi-checkbox over the site's public post types. Applies only to post event tracking.
• Excluded Post Statuses — multi-checkbox over WordPress post statuses (publish, draft, pending, auto-draft, and so on). Useful for excluding auto-draft and inherit noise.

Common Patterns

• "Stop logging Editor activity during a content push" — tick the Editor role temporarily.
• "Filter out my own admin actions" — add your user ID to Excluded User IDs.
• "Drop draft autosave noise" — tick Auto Draft and Inherit in Excluded Post Statuses.
• "Stop logging cron pings from a monitoring service" — add the monitoring IP to Excluded IP Addresses.

How It Works

Exclusions are checked just before the row is inserted. If any rule matches, the event is silently dropped — it never hits the database and never appears in dashboards, exports, or notifications. The check is enforced by the central LogFilter, so every Logify feature respects the same rules.

Notes

• Exclusions are applied to future events. Existing entries in the log are unaffected.
• Severity, user agent, and session ID are still computed before the exclusion check, so a developer-side filter can override one rule conditionally — see kc_lf_should_log.