Review notification and backup side effects before starting a Checkmk simulation copy

Bottom line: Prepare the copied site before startup: simulation changes monitoring queries but leaves notifications, scheduled backups and some distributed behavior active; do not treat it as total isolation.

Source fact: what the authority says

The Checkmk simulation-mode guide uses cached service data instead of live host queries, and missing cache data makes the affected service UNKNOWN. Active network queries are redirected to 127.0.0.1; ping-based hosts therefore appear UP, and HTTP checks contact the monitoring server itself. Notifications, Event Console processing and scheduled backup jobs continue during simulation. Other sites continue ordinary monitoring unless a distributed setup with central configuration passes simulation mode to them.

What the source does not establish

This article reviews the documented simulation boundary, not proof that a copied site is isolated. It does not approve production network access, notification delivery or backup destinations for a test copy.

Applicability questions

• Which copied site and cache population are intended for the exercise?
• What notifications and scheduled backup jobs remain configured there?
• Which distributed configuration relationship could affect other sites?
• Who approves the test destinations and prevents unintended external actions?

DSE recommendation: controlled next steps

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

DSE recommends reviewing the copied site’s remaining actions before its first startup. Inventory notification destinations, scheduled jobs and distributed relationships alongside the simulation setting. Keep the test copy’s identity and purpose explicit so a familiar production configuration is not accepted without examining its operational side effects.

Arrange approved test notification recipients or disable the unwanted notification path through the managed configuration process. Review backup destinations separately and exclude valuable production targets from the trial. Name the person who can stop the copied site if an unexpected external action occurs; do not rely on simulation as the whole containment plan.

Inspect the intended cache population before choosing the test cases. Include one representative cached host and a deliberately missing-cache case in the written exercise. Treat the simulated status display as an input to the upgrade evaluation, with fresh application or device health outside that conclusion.

Review the central-versus-remote configuration relationship with the monitoring owner before activating changes. Keep the trial limited to the approved site population. Preserve the original copied configuration and record what was deliberately changed, so the eventual production upgrade does not inherit test recipients or an unnoticed simulation setting.

Verification and evidence

Proposed verification: start only the approved isolated copy and inspect its effective simulation setting, selected cached data and actual test-service results. Compare the cached and missing-cache cases with the written expectations. Keep any localhost probe result explicitly labeled as part of the simulation exercise.

Observe the approved notification and job controls independently, recording actual destinations without disclosing credentials. Reconcile distributed-site scope with the owner and check the final configuration before ending the trial. Retain the copied-site identity, settings and unresolved side effects; this exercise does not establish current production host health.

Official references

• Checkmk — Simulation mode — 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.