Review each Checkmk site’s usage-data transmission before opting in

Bottom line: Preview actual usage JSON and determine which sites inherit the consent setting; enabled remote sites transmit independently rather than through one aggregated central upload.

Source fact: what the authority says

The Checkmk usage-analytics guide documents opt-in transmission from versions 2.5.0, 2.4.0p26 and 2.3.0p47 onward, with no transmission before active consent. The documented cmk-product-usage --dry-run command collects the report locally without sending it externally and is available regardless of the analytics setting. A remote site inherits the central consent setting when configuration is pushed to it; without replication, that central decision is not transferred. Each enabled site uploads its own usage data directly, while the central site uploads only its own report.

What the source does not establish

This article reviews the documented report and transmission controls, not an independent privacy or anonymization assessment. It does not claim that central consent covers every remote site or approve data sharing on an organization’s behalf.

Applicability questions

• Which installed versions provide the documented product-usage feature?
• What does the actual local JSON preview contain?
• Which remote sites inherit configuration and which maintain their own setting?
• Who may authorize each site’s collection and external transmission?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends reviewing the actual usage report before deciding whether to enable transmission. Name the responsible administrator and information owner, and keep the preview in an appropriately restricted location. Assess its real fields against the organization’s requirements rather than converting a vendor description into an independent privacy assurance.

Make a site-by-site consent map with the configuration-replication relationship beside each entry. Have the distributed-monitoring owner identify which sites receive the central setting and which need an independent decision. Keep a missing or unknown setting unresolved instead of assuming that a single central choice covers the environment.

Review the intended outbound path separately for every site authorized to transmit. Coordinate the proxy or network requirements through the existing approved process without changing consent merely to test connectivity. Preserve the prior setting and designate who may revise or withdraw the decision when the report or site population changes.

Use harmless local previews for the initial exercise, with external transmission outside that trial unless separately authorized. Record the installed release and reviewed report identity. Keep site inventory, report-content review and any actual transmission observation as distinct evidence so a successful local collection cannot be described as proof of a remote upload.

Verification and evidence

Proposed verification: generate the approved local preview and inspect its actual fields with the designated reviewer. Retain a redacted field inventory or controlled report reference rather than copying sensitive content into an ordinary ticket. Compare the consent map with the effective settings on the central and selected remote sites.

Where transmission is separately approved and exercised, inspect the relevant site’s actual result and configured route without inventing an upload observation for the other sites. Reconcile inherited and independent settings explicitly. Record unperformed uploads as unperformed and preserve the decision, version and review trigger without claiming universal anonymity or compliance.

Official references

• Checkmk — Product usage analytics — official product documentation; confirm the installed release and configuration.

Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.