Keep the installation observable and its recovery path ready.

Establish a routine with named owners

Use an account with platform:manage for platform settings and general job management. Identity management, connector management, audit verification, and firewall administration have separate permissions. The available Platform tabs reflect those rights; an absent tab does not establish a service failure.

• Review Platform > Overview for available security detections and actionable delivery or integrity notices. An unavailable status needs its offered retry; it is not a healthy result.
• Review unfinished or failed work using Jobs and recovery. Keep an owner for each unresolved vendor outcome before admitting another change.
• Check encrypted backup freshness and a verified off-host copy using the backup routine. Periodically exercise the retained recovery point.
• Track license expiry and the installed version. Use Licensing for replacements and Upgrades and recovery for a planned update.
• After connector, identity, mail, or logging changes, check the affected workflow and its recorded outcome. Keep configuration ownership and the recovery material outside the application host.

Overview shows logging exceptions rather than a permanent all-clear card. No warning is not proof that an external destination has received every event. Audit history and integrity are covered by Audit and evidence.

Configure and test the saved SMTP settings

Open Platform > Settings > Email. Platform management allows access; changing the connection or credentials, or restoring defaults, also requires identity:manage. Configure an organization-approved SMTP service before relying on email invitations and local password recovery.

1. Under SMTP, enter the agreed host, port, TLS settings, account, and sender. Production requires encrypted delivery: port 465 uses implicit TLS; other ports use STARTTLS when TLS is enabled.
2. Supply the intended password when setting or replacing it. A stored password is not displayed. Read any replacement, clearing, or retention confirmation when changing the connection; a new destination does not silently receive an old credential.
3. Choose Save and wait for confirmation. Resolve any validation or stale-configuration error before proceeding.
4. Enter one intended recipient under Send test to and choose Send test email. This tests the saved configuration, so first save or undo remaining edits.
5. Confirm receipt in that mailbox, including its spam or quarantine view. Successful submission to SMTP does not establish delivery to the inbox.

Use the displayed safe error category to distinguish authentication, certificate, or recipient problems. Keep passwords and full mail-server replies out of support requests. Follow Sign-in and security for the account workflow after mail delivery works. Restore defaults appears while SMTP values are saved here; it removes them and returns to the deployment settings, so review that change before confirming it.

Configure an external log destination and prove receipt

Naradox writes structured application logs to standard output. External forwarding is optional and off by default. Use your organization's collector or relay to receive events and route them to the intended SIEM. Open Platform > Settings > Logging.

Logging configuration, delivery checks, recovery, and diagnostics require the Advanced Observability license capability as well as platform management. Check the installed entitlement using Licensing if they are unavailable.

1. Under External log destination, select Enable external log destination and enter the HTTPS destination URL.
2. Supply the destination's bearer token if required. Select Send audit events and, if needed, Also send application logs. Review the information your organization intends to forward.
3. Use Advanced & troubleshooting for any required proxy, private-CA, or mutual-TLS configuration. Credential paths must be available to the runtime. Read the confirmation when changing a destination or trust route.
4. Choose Save changes and wait for the saved settings and deployment status to refresh.
5. Choose Test saved destination, inspect Last destination test, and use Copy event ID to find that exact test downstream.

Local queue acceptance and HTTP acceptance are separate outcomes. Confirm parsing and indexing at the final destination before calling delivery operational. A test uses saved settings; unsaved edits do not change its route.

Audit forwarding uses a durable database queue while enabled. It can deliver the same event more than once, so deduplicate downstream using event_id. Application-log forwarding uses a process-local queue and has different loss and restart behavior; it does not replace the audit archive. External forwarding is separate from Check Point traffic logs.

Recover audit delivery after correcting its destination

Follow Log delivery needs attention from Overview, or open Logging and Advanced & troubleshooting. Inspect the audit-delivery section separately from Process diagnostics. A saved route change can block older queued events until an administrator explicitly reviews where they should go.

1. Correct and save the intended destination, test it, and confirm the test event downstream.
2. If Recoverable is positive, review Resume delivery and confirm the intended route. This returns eligible deliveries to the queue; it is not confirmation that they reached the destination.
3. Check the refreshed backlog and last-delivered time, then verify representative event IDs in the destination. Recovery works on a bounded set; continue with the offered action if eligible deliveries remain.
4. If the section reports events that require investigation, download diagnostics and escalate through your incident or support process. Payload-integrity failures cannot be resumed with this action.

Ordinary transient retries can recover automatically. Do not change retention or delete evidence to hide a backlog. An event present in Naradox but missing downstream is a delivery investigation; use the audit guide when investigating the stored event itself.

Collect diagnostics for the affected operation

Open Process diagnostics for worker and configuration status. Under Advanced & troubleshooting, Download diagnostics bundleproduces sanitized logging configuration, delivery status, retention, and recent integrity coverage. It is not a full audit export or a complete historical integrity report.

Keep the visible error, time and timezone, version, and relevant request, audit-event, or job identifiers. Review the bundle before sharing it through a support request. If temporary DEBUG logging was needed, restore the normal levels after collecting the relevant evidence.

Optional local file logging also needs host collection, space, and rotation monitoring. Standard output remains available. Use deployment settings removes only that subsection's saved overrides, returning it to deployment configuration or defaults; it is not a reset of all settings.

Use optional lab and diagnostic tools deliberately

Platform > Settings > Utilities controls Enable Check Point utilities. Tool use needs global access management and direct firewall administration; selecting lab targets also requires connector management. These tools are separate from ordinary delegated rule work.

Lab rulebase generator

Select a dedicated lab target, then open Platform > Lab & diagnostics and choose New lab rulebase. Start with a small dataset and follow its job before opening the generated package in Rulebase. Generation publishes packages, objects, and disabled rules; it does not install policy or generate traffic. Use the run's Deleteaction when cleanup is intended and keep the utility and target enabled until cleanup finishes. Cancellation does not undo submitted Check Point changes; follow job recovery for uncertain outcomes.

Read-only API Explorer

API Explorer additionally requires unrestricted log-viewing authority. Select the instance, enter an admitted Check Point v2.1 read command under Endpoint, supply its JSON payload, and choose Send. For a small host listing, use show-hosts with {"limit":20,"offset":0,"details-level":"standard"}. Follow-up task and log-page requests are explicit; the Explorer does not poll or retry for you. Never enter credentials or session identifiers into its payload.