Events & Audit

NetLock RMM keeps two separate logs, each answering a different question.

• Events answers "what happened on the devices?" — antivirus detections, job outcomes, sensor breaches, uptime-monitor failures, port-scan findings, device online/offline transitions.
• Audit answers "what happened in the console?" — who logged in, who changed a policy, who approved a patch, who deleted a user.

This split is deliberate. Events is operational; Audit is administrative. Events is filterable by severity and device; Audit is filterable by user and entity type. Events can be marked read or exported; Audit is append-only and cannot be pruned from the UI. Keep the two pages separate in your head and you will always be on the right one.

12.1 Scope split

Events and Audit are not duplicates of each other. The following split is the single source of truth:

Script execution is the classic case of a record landing in both logs. The Audit entry records that a console user initiated the run (action = execute, entity_type = script). The Events entry is emitted by the device after the script finishes (type = job), with the outcome and any output. Read one without the other and you are missing half the picture.

Application Control and Device Control blocks are surfaced in Events and on their own Blocked tabs — see 12.5.

12.2 Events

Manage Events at /events is the operational log.

List columns

The list shows:

Filter controls

A filter bar across the top of the page narrows the view:

• Time span — start and end date. Defaults to the last 7 days.
• Severity — Any, critical, high, moderate, or low.
• Type — Any, antivirus, job, sensor, Uptime Monitoring, or Port Scanner.
• Tenant — dynamically populated from the tenants you have access to.
• Location — dynamically populated from the selected tenant.
• Show read events — checkbox, off by default. When off, events you have already opened are hidden.
• Show website uptime events — checkbox, on by default.
• Show port scanner events — checkbox, on by default.

The six event types

Events are categorised by type. The Type filter exposes five of them; a sixth exists but is not included in the dropdown:

The Show website uptime events and Show port scanner events checkboxes are independent of the Type dropdown. If you pick Uptime Monitoring from the Type dropdown, the events are shown regardless of the checkbox state — the dropdown wins when it names a type explicitly.

Hidden jobs are excluded

Jobs marked Hidden in their library entry (see Chapter 8.2) are excluded from the Events view at query time. There is no checkbox that brings them back — they are not visible on this page at all, regardless of filter state. Use hidden jobs for background work that feeds Custom Fields or other non-operational data flows; use non-hidden jobs when you want the outcome surfaced here.

Event Details dialog

Clicking a row opens the Event Details dialog and marks the event as read.

The dialog has two tabs:

• Monaco — the event content rendered in a Monaco code editor with syntax highlighting. Best for output that is JSON, XML, or otherwise structured.
• RAW — the plain-text form of the same content. Use this when Monaco's highlighter guesses wrong or when you want to copy content verbatim.

When AI is enabled in Settings → AI/LLM, a third control appears: the Analyze with AI button. Clicking it hands the event content to the AI chat with the event context pre-filled, so you can ask the model to explain the event without copying and pasting it by hand.

Toolbar actions

The Events toolbar exposes:

• Refresh — re-queries the server for the current filter.
• Mark all as read — marks every event currently visible as read.
• Export — exports the currently-filtered list as JSON or HTML.

There is no acknowledge affordance beyond mark-as-read and no delete affordance. Events remain on the server until retention rules (configured in Settings) remove them.

Permissions

Tenant scoping is applied through the standard tenant-list permission, so a user with access to tenants A and B will see events from devices in those tenants only.

12.3 Audit

Audit at /audit is the administrative log.

List columns

The list shows:

Filter controls

• Time span — default last 7 days.
• Severity — Any, Info, Warning, or Critical.
• Action — Any plus the ten action categories.
• Entity Type — Any plus the 18 entity types.
• User — drawn from the accounts that have ever produced an audit entry.

Action categories

Every audit entry has one of these ten actions:

Entity types

Every audit entry has one of these 18 entity types:

Immutability

There is no delete affordance on the Audit page. You cannot remove individual entries, bulk-delete, or clear the log from the UI. The log is treated as append-only.

Viewing the Audit log is itself audited. When you open the page, an entry is written with action = view and entity_type = audit_log, recording which user accessed the log and from what IP. This means the auditors can be audited — you can see who has been reading the log.

Retention

Retention is not configurable on the Audit page. The date-range picker filters what you see; it does not delete anything. Retention is a global setting under Settings → Logging (see Appendix A.9).

Audit Details dialog

Clicking a row opens the Audit Details dialog. It shows the full record: date, severity, user, source IP, action, entity type, entity ID, entity name, tenant scope, and the formatted details payload. If the details field contains valid JSON, it is pretty-printed; otherwise it is rendered as plain text. The dialog has a single Close button.

Permissions

12.4 Cross-reference: which Phase-2 feature lands where

A single console action often produces records in both logs. The table below maps common operations to the records they write — use it when you are tracking a change across systems.

12.5 Application Control and Device Control blocks

When the agent blocks an unknown application or USB device, the block is surfaced in two places at once.

On the Events page. Each block is logged as an event. It shares the antivirus type with Microsoft Defender events, so the Type filter dropdown has no separate Application Control or Device Control entry — selecting antivirus, or leaving the filter on its default, includes them. Identify them by the Reported by column, which reads Application Control [<mode>] or Device Control [<mode>].

On a dedicated Blocked tab. The same block also lands on a block-and-approve tab inside Collections:

• Application Control blocks appear on the Blocked Applications tab of Manage Application Control Rulesets — see Chapter 8.6.
• Device Control blocks appear on the Blocked Devices tab of Manage Device Control — see Chapter 8.7.

The two surfaces serve different purposes. The Events entry is the operational timeline — what happened, when, and on which device. The Blocked tab is the workflow surface — a blocked attempt is an input to the approval process, where you decide whether to whitelist it. Use Events to spot a block; use the Blocked tab to act on it.

If the policy has tray-icon notifications enabled, the on-device user additionally sees a notification at the moment of the block — configured per policy in Chapter 6.

Permissions

See Appendix X.2 for the full permission catalogue.

Related chapters

• Chapter 5 — Automations explains why automation-driven policy changes show up as update on policy rather than as events.
• Chapter 6 — Policies covers what a policy edit actually changes, producing the update on policy audit entries referenced in 12.4.
• Chapter 7 — Patch Management covers the approval workflow whose state changes surface as update on patch entries.
• Chapter 8 — Collections documents the Collections features whose executions appear as job, sensor, and antivirus events, and whose block logs live in their own tabs rather than in Events.
• Chapter 13 — AI Chat is where the Analyze with AI button on Event Details lands you.
• Appendix A.9 — Logging & protocols covers the retention controls that determine how long events and audit entries are kept.