🚀 Automated Health Check & Customer Report

[samirshah1]

What if checking the health of a Check Point environment before and after maintenance didn't mean manually collecting and comparing outputs from multiple commands?

The Automated Health Check & Customer Report standardizes the process. It collects relevant operational evidence, compares pre- and post-change snapshots, analyzes results against defined expectations, preserves raw evidence, and presents the outcome in an easier-to-review format.

For Check Point administrators, that means a more repeatable approach to reviewing gateway health, installed policy, ClusterXL, SecureXL, CoreXL, system resources, interfaces, and routing evidence, where applicable to the environment.

Most importantly, the initial model is deliberately read-only. The tool collects and reports what it observes rather than automatically changing policy, gateway configuration, cluster state, or making remediation decisions.

Connect. Collect. Analyze. Compare. Report.
A simpler way to turn gateway health checks into repeatable operational evidence.

Operational runbook · Version 1.0

Automated Health Check & Customer Report

A controlled, repeatable approach to capture Check Point Security Gateway health evidence before and after planned maintenance.

Executive overview

The proposed utility collects operational evidence from Check Point Security Gateways, compares results against customer-defined expectations, and generates structured reports for technical and executive review.

Purpose: Make gateway validation consistent, documented, and repeatable while keeping collection separate from configuration changes.

 

Benefits

Consistent validation: Use the same approved checks across gateways and engineers.

Faster evidence collection: Collect multiple health indicators in one controlled execution.

Clear change validation: Compare equivalent pre-change and post-change snapshots.

Customer-friendly outcomes: Present PASS, WARNING, FAIL, INCOMPLETE, and INFORMATIONAL states.

Raw evidence retained: Preserve source output for audit and troubleshooting.

Reduced operational risk: The initial operating model is read-only and does not remediate automatically.

 

Scope and principles

In scope: System, firewall, ClusterXL, SecureXL, CoreXL, and network evidence as applicable; report generation; optional comparison.

Out of scope: Policy installation, object changes, reboot, cluster state change, Gaia configuration, or automatic remediation.

Decision model: The tool reports evidence. Customer change control and engineering judgment determine the response.

 

Workflow

Connect -> Collect -> Analyze -> Compare -> Report

 

Prerequisites

Requirement	Expectation
Execution host	Approved administrative workstation or jump host with connectivity to target gateways.
Runtime	Supported Python 3 release defined by the completed tool package.
Access	Approved credentials and least privilege where technically feasible.
Topology	Confirmed gateway roles, expected interfaces, and customer-defined operational expectations.
Data handling	Approved evidence location because reports may contain sensitive infrastructure details.

 

How to use the tool

Confirm scope

Verify targets, topology, maintenance reference, approved access, and report location.

Validate connectivity

Confirm the execution host can reach each target and authentication works.

Run the pre-check

python3 healthcheck.py --config config/config.yaml --mode precheck

Review exceptions

Investigate every WARNING, FAIL, ERROR, or INCOMPLETE result before maintenance.

Perform approved maintenance

Use the separate approved change plan. The health-check utility does not execute the change.

Run the post-check

python3 healthcheck.py --config config/config.yaml --mode postcheck

Compare snapshots

python3 healthcheck.py --compare customer-precheck.json customer-postcheck.json

Deliver and retain evidence

Share the HTML report with the intended audience and store JSON/raw evidence securely.

 

Health-check catalogue

Area	Example evidence	Proposed commands
System	Version, uptime, CPU, memory, disk	cpinfo -y all; cpstat os; df -h
Firewall	Firewall state and installed policy	cpstat fw; fw stat
ClusterXL	Member and interface state	cphaprob stat; cphaprob -a if
SecureXL	Observed acceleration state	fwaccel stat
CoreXL	Observed instance status	fw ctl multik stat
Network	Expected interfaces and routes	Customer-approved Gaia/Linux commands

Validation requirement: Confirm command availability, syntax, permissions, and interpretation for the customer release, gateway type, and topology before production use.

Status interpretation

PASS: Observed result matches the configured expectation.

WARNING: Review context and the customer's threshold.

FAIL: Investigate through the approved decision process.

INCOMPLETE: Manual validation required. Never infer PASS.

INFORMATIONAL: Evidence provided without a pass/fail policy.

 

Security and stop conditions

Protect credentials: Do not hard-code secrets. Use the customer-approved mechanism.

Protect reports: Reports can reveal hostnames, IP addresses, software information, and topology.

Preserve evidence: Record collection time, target, tool version, check ID, and outcome.

Stop condition: Pause and review unexpected critical pre-check findings. For unavailable commands or parser failures, preserve raw output and mark the check INCOMPLETE.

*** This is what the report will look like:

 What's there:

• checkpoint-health-check.py Collects the data, analyzes it and writes the report. It can get the data three ways:
  • --host or --inventory: over SSH. With an inventory file, you also get a index.html summary of all hosts.
  • --local: run directly on the Gaia box in Expert mode.
  • --input-dir: analyze output collected earlier by the Bash script.
• cp_health_collect.sh is a Bash-only collector to run on the box. It produces a .tgz you can analyze anywhere, which suits air-gapped sites.
• Checks: everything on your list, plus memory, connections table, Check Point processes, licenses/contracts, time sync, and the management server and its API (management servers only). It detects whether the box is a gateway, cluster member, management or standalone server and runs only the checks that apply.
• HTML report: an overall status banner, PASS/WARN/FAIL/INFO counts, system info, colour-coded results with details and recommendations, and the raw output of every command.
• Exit codes: 0 = all OK, 1 = WARN, 2 = FAIL, 3 = error, so you can use it from a scheduler.

Before you use it on real gateways:

1. Run pip install -r requirements.txt (installs paramiko for SSH mode).
2. The SSH user needs a bash shell, not clish: set user <name> shell /bin/bash. The tool detects clish and tells you.
3. Unknown SSH host keys are rejected by default. Use --accept-new-host-key the first time you connect to a box.
4. To flag gateways that are behind on hotfixes, copy config.example.json and set recommended_jhf per version. I didn't hardcode the numbers because they change often.

Try it on the sample data:

python checkpoint-health-check.py --input-dir samples/cp-gw01 --customer "ABC Company"