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.
\nThe OPNsense Monit guide 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.
\nThis 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.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE 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.
\nUse 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.
\nKeep 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.
\nFor 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.
\nProposed 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.
\nCompare 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.
\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: what the authority says\nThe OPNsense Monit guide 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich exact process or endpoint is being monitored, and what does the selected probe actually observe?\nWho permits a restart, and which other services might need coordination before that action?\nWhat polling interval and repeated-restart boundary fit the workload?\nWho must investigate when automatic recovery stops, including outside staffed hours?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nUse 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.\nKeep 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.\nFor 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.\nVerification and evidence\nProposed 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.\nCompare 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.\nOfficial references\n\nOPNsense — Monit — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: what the authority says\n\nThe [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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Which exact process or endpoint is being monitored, and what does the selected probe actually observe?\n\n- Who permits a restart, and which other services might need coordination before that action?\n\n- What polling interval and repeated-restart boundary fit the workload?\n\n- Who must investigate when automatic recovery stops, including outside staffed hours?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE 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.\n\nUse 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.\n\nKeep 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.\n\nFor 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.\n\n## Verification and evidence\n\nProposed 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.\n\nCompare 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.\n\n## Official references\n\n- [OPNsense — Monit](https://docs.opnsense.org/manual/monit.html) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/bound-an-opnsense-monit-restart-rule-before-enabling-recovery/", "url": "https://update.dsesecurity.com/updates/bound-an-opnsense-monit-restart-rule-before-enabling-recovery/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-28" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/bound-an-opnsense-monit-restart-rule-before-enabling-recovery/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "IT", "item": "https://update.dsesecurity.com/topic/it/" }, { "@type": "ListItem", "position": 3, "name": "Bound an OPNsense Monit restart rule before enabling recovery", "item": "https://update.dsesecurity.com/updates/bound-an-opnsense-monit-restart-rule-before-enabling-recovery/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/bound-an-opnsense-monit-restart-rule-before-enabling-recovery/#article", "identifier": "https://update.dsesecurity.com/updates/bound-an-opnsense-monit-restart-rule-before-enabling-recovery/", "url": "https://update.dsesecurity.com/updates/bound-an-opnsense-monit-restart-rule-before-enabling-recovery/", "headline": "Bound an OPNsense Monit restart rule before enabling recovery", "description": "OPNsense documents a Monit restart example with an explicit unmonitor threshold; decide when automatic recovery must stop and reach an operator.", "abstract": "OPNsense documents a Monit restart example with an explicit unmonitor threshold; decide when automatic recovery must stop and reach an operator.", "articleBody": "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.\nSource fact: what the authority says\nThe OPNsense Monit guide 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich exact process or endpoint is being monitored, and what does the selected probe actually observe?\nWho permits a restart, and which other services might need coordination before that action?\nWhat polling interval and repeated-restart boundary fit the workload?\nWho must investigate when automatic recovery stops, including outside staffed hours?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nUse 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.\nKeep 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.\nFor 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.\nVerification and evidence\nProposed 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.\nCompare 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.\nOfficial references\n\nOPNsense — Monit — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T00:10:13+00:00", "dateModified": "2026-10-29T00:10:34+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/bound-an-opnsense-monit-restart-rule-before-enabling-recovery/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/bound-an-opnsense-monit-restart-rule-before-enabling-recovery/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Bound an OPNsense Monit restart rule before enabling recovery" }, "articleSection": [ "IT", "Networks & Infrastructure" ], "keywords": [ "IT", "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 575, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "OPNsense — Monit", "url": "https://docs.opnsense.org/manual/monit.html" } } ] } }