Inspect logged activity and understand what a watch has measured.

1. Prepare indexed logs and separate access rights

Start with the connected Management instance and Linux firewall scope from Connect Check Point and Access and permissions. Confirm that your deployment's license includes the log and Watchlist features you intend to use. The comment-only pilot leaves both permissions off; ask the access administrator to enable them deliberately for this exercise.

• Have the Check Point administrator enable Log Indexing and run Install Database on the Management/Log Server. Naradox reads indexed logs. Events in SmartConsole's raw Latest Log File view do not establish that this source is ready.
• Have the access administrator enable Rule logs for this team scope for the Linux scope, and confirm your current membership and field visibility. A grant uses its separate Rule logs for this grant setting and needs an exact rule selector.
• Enable Watchlist for this team scope for the same Linux scope, or Watchlist for this grant when using a grant. It requires visibility of at least one supported object-reference field, such as Destination. Watchlist access alone does not provide log access.

A successful connector connection check proves neither indexed-log availability nor your access to those logs. Rule visibility, rule editing, log reading, and Watchlist access are separate permissions. Use the existing change workflowto confirm publication and any required policy installation separately.

2. Inspect events for the agreed rule

1. Open Workspace > Team rules, select the Linux scope, and locate the agreed rule.
2. Open its row actions and choose View logs. On the Logs page, check the instance and selected rule before interpreting the results.
3. Choose a suitable time range, such as Last hour, or select Custom and set From and To. Choose Search and wait for the read to complete.
4. Inspect event times and the permitted Source, Destination, Service, and Action values. Open an event to examine its available details.

Limited readers see only fields their current access permits. Missing fields or unavailable raw event details can therefore be expected. A permitted search such as action:Acceptnarrows visible results; it cannot reveal hidden fields or expand your authorized traffic.

Read the action before interpreting a record. A logged acceptance does not establish that the application completed its work. An empty result does not establish that no traffic occurred. Check Point results page forward; repeat the search to return to the first page. If offered Restart search after an interrupted page, use it to begin a fresh read.

3. Choose the shared Watchlist context

Open Watchlist and select the Linux scope in Watchlist context. A single available delegated context may already be selected; still check its name. Assigned users share the watches in this context and can add or remove subscriptions. The Created by column identifies the creator without making the watch private.

A scoped measurement covers the selected target, within this grant or firewall scope, within your current personal log permissions, during its measurement period. Broader log rights or a second grant do not widen this selected context. Colleagues with different effective log rights may see different measurements for the same shared watch.

Scoped counts require records attributable to currently permitted rules. A matching host address alone is insufficient. Traffic dropped outside those rules is not counted in a scoped watch.

Users with general analytics rights can also have a Broad Watchlist context. Administrators with both analytics management and access management start in All watches. That inventory includes scoped subscriptions; choose Open context to inspect their current usage and actions. The inventory itself does not prove current coverage, and administrative Watchlist management does not grant logs. Select the Linux scope explicitly when following this example as an administrator.

4. Add a watch for an object already used by the rule

1. Choose Add watch and confirm the Linux scope under Grant or firewall scope. Its Instance follows that context.
2. Choose Network objects or Applications & URLs under Watch category. Only categories with supported references in currently visible rule fields are available.
3. Search or use Browse to select an existing referenced object. For example, select the host already used as a destination in the agreed Linux rule.
4. For a network target, set Log field to dst: (Destination) for that example. Use src: (Source) when you intend to follow the address as a source. Each direction has its own watch and measurement.
5. Choose Add, wait for the list to reload, and confirm the target, context, and direction under Watched items.

The selected object determines whether Naradox creates an individual watch or a group subscription. Supported groups follow their current members and appear under Group watches. Adding a watch is direct; it observes already permitted information and does not submit a rule change for approval.

Scoped selection requires an actual reference in a visible current rule field. Being allowed to select an object for a future rule edit is insufficient. Free IP or URL entry belongs to the broad context. Network ranges, CIDRs, Any, Internet, ordinary TCP/UDP services, service groups, and Content objects are unsupported watch targets.

URL watches identify a host or domain. A URL path or port does not narrow their matching, so check that this is the activity you intend to observe before adding one.

5. Check usage and read the measurement together with its coverage

Choose the item's Check usage action, or let the configured background collection continue. Wait for the result and the refreshed list. A usage check can finish with incomplete coverage; inspect the status instead of treating the click as a successful measurement.

• Not checked yet: there is no completed measurement to interpret. This is not a zero count.
• Checked — no matches: a valid checked period contains no authorized matching records. Read Last checked and the coverage before drawing a conclusion.
• Seen: matching records were observed. Last seen describes the latest matching event within the measurement.
• Incomplete coverage: the requested period has not been fully checked. Available counts describe only proven coverage; inspect the status explanation and check usage again to continue.
• No log access: usage figures are unavailable. Stale means the last successful check is older than expected for the configured refresh interval.

Hits is a cumulative count of matching log records within the valid measurement period. Its explanation shows the start and measured-through time when known. It is not a rolling refresh-interval count, packet total, connection total, or count of successful users. Blocked attempts can match too. One event may match several watches, so adding their totals does not produce a unique traffic count.

6. Open the matching events before making a decision

Choose View matching logs on the watched item. Naradox opens Logs for the selected target and carries over its measurement period when available. Check the instance, context, and time bounds. For incomplete coverage, the requested end can extend beyond the time already measured. Additional search text narrows results while current context and personal permissions still apply.

Examine the records' actions and times before deciding whether to investigate or propose a policy change. Scoped watch searches do not offer exports or field statistics. If access or the watched source changed, return to Watchlist and open the current context again.

Logs that arrive late at the source can appear in a later search without entering an already completed Watchlist count. Watchlist does not reconstruct those earlier counts retrospectively. A completed scan describes the available source records it checked at that time, so a later log search and the saved count can differ. Use Rulebase historywhen the investigation concerns published configuration changes.

Manage subscriptions with their shared ownership in mind

Use a group's Sync action to update its members. A failed synchronization is not evidence that the group is empty. Permission, rule, target, or membership changes can invalidate previous usage; refresh the current context before relying on its figures.

Review the confirmation before choosing Delete: a scoped deletion affects the shared list. Items owned only by groups cannot be deleted individually. Deleting the group subscription retains members still watched manually or through another group. Removing a manual subscription likewise retains monitoring supplied by a group. These actions remove subscriptions, without deleting firewall objects or rules. A zero count does not automatically remove anything.

Resolve missing results at the affected step

• No watchable objects: check the selected context, supported object types, and currently visible rule references. Retry an explicit category-loading error before interpreting it as an empty list.
• No figures or unavailable refresh: check current log access and Watchlist management authority. View-only access does not enable add, delete, or refresh actions.
• A watch was saved but the list refresh failed: use Retry refresh to reload the saved result. Do not add the same watch again.
• Empty logs or persistent incomplete coverage: verify the time window, permissions, indexed-log readiness, and displayed error using Logs and Watchlist troubleshooting.