# Bound an OPNsense Monit restart rule before enabling recovery > OPNsense documents a Monit restart example with an explicit unmonitor threshold; decide when automatic recovery must stop and reach an operator. - Canonical URL: https://update.dsesecurity.com/updates/bound-an-opnsense-monit-restart-rule-before-enabling-recovery/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T00:10:13+00:00 - Modified: 2026-10-29T00:10:34+00:00 - Last reviewed by DSE: 2026-10-28 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know OPNsense documents a Monit restart example with an explicit unmonitor threshold; decide when automatic recovery must stop and reach an operator. ## Potentially affected OPNsense Monit service monitoring; confirm the installed release, monitored service and permitted restart action. ## DSE recommendation DSE recommends pairing each automatic restart decision with a bounded retry condition and an attended investigation path. ## Article Bottom line: Choose both the failure condition and the point at which automated recovery must stop. A service owner should be able to explain what one failed probe authorizes, how repeated failures are bounded and who investigates after that boundary. ## Source fact: what the authority says The [OPNsense Monit guide](https://docs.opnsense.org/manual/monit.html) separates service configuration, test conditions and the action taken when a condition is met. Its FTP-proxy example uses a failed local TCP check to trigger Restart and a separate condition of five restarts within five cycles to trigger Unmonitor. The polling interval controls how often Monit checks monitored components. The status panel shows each active service and additional information when the service provides it. ## What the source does not establish This article uses the documented FTP-proxy example to frame a restart-policy decision. It does not prescribe those settings for another daemon or identify the cause of a failed probe. DSE treats service availability, application correctness and notification receipt as separate acceptance questions. ## Applicability questions - Which exact process or endpoint is being monitored, and what does the selected probe actually observe? - Who permits a restart, and which other services might need coordination before that action? - What polling interval and repeated-restart boundary fit the workload? - Who must investigate when automatic recovery stops, including outside staffed hours? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. DSE recommends writing a two-part rule before configuring the action: the observed condition that permits one restart, and the repeated condition that hands control back to an operator. Name the service, probe destination, interval and owner. Review the actual start and stop commands against the deployed service rather than copying the FTP-proxy command into a different application. Use three proposed review scenarios: a single transient probe failure, a service that repeatedly returns to the same failure, and a maintenance stop deliberately requested by an administrator. Have the owner state the permitted response for each. Decide how a deliberate maintenance stop will be handled; do not silently turn the example into authority to restart every stopped service. Keep the investigation path useful after the restart boundary is reached. Identify where the responder will find the failed probe, action history and service diagnostics. Coordinate with existing supervisors so the review names one recovery authority for the scenario. Require a deliberate decision before increasing the retry limit in response to repeated failures. For the repeated-failure review, keep the probe identifier, action count and operator handoff on one timeline. Ask the responder to identify the first unresolved condition, not just the last restart. Preserve any disagreement between that timeline and the status display for investigation. ## Verification and evidence Proposed verification: use a disposable or approved representative service and record its actual initial configuration. Exercise one agreed failure condition, then an approved repeated-failure case. Observe the probe, each action and the point at which monitoring changes state. Do not manufacture a production outage merely to generate the example sequence. Compare the observations with the written single-failure and retry-boundary decisions. Have the intended responder retrieve the resulting evidence and explain the next diagnostic step. Include the maintenance-stop scenario in the review, restore the approved test state and record any condition that remains untested. Retain sanitized timestamps and configuration identifiers rather than service credentials. ## Official references - [OPNsense — Monit](https://docs.opnsense.org/manual/monit.html) — official product documentation; confirm the installed release and configuration. Source review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: OPNsense — Monit - Authority: docs.opnsense.org - URL: https://docs.opnsense.org/manual/monit.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Bound an OPNsense Monit restart rule before enabling recovery,” DSE Security, https://update.dsesecurity.com/updates/bound-an-opnsense-monit-restart-rule-before-enabling-recovery/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.