Bottom line: Review the health-check meaning before relying on a backup table. Keep a failed individual host and a completely failed primary table as different cases in the failover plan.
\nThe OPNsense relayd reference groups hosts into tables and allows a host to belong to more than one table. A table check determines whether a host group is ready, with examples ranging from ICMP to an HTTP URI and response-code check. A virtual server can use primary and backup tables; the backup is used when all primary-table hosts are down according to the configured check. Its server type distinguishes transparent layer-three redirection from layer-seven relay operation.
\nThis article covers the documented table-check and backup-selection boundary. It does not provide an application availability guarantee, a universal probe design or permission to create a production failure to demonstrate failover.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE recommends describing the intended failure in operational terms before choosing a probe. Ask the application owner whether a network response or a named HTTP response is the observation needed for this particular service. Document the selected check and expected healthy response without treating either example as a universal availability test.
\nBuild a table-membership map that names every primary and backup host. Mark any host used in more than one table so the operator can explain the test population. Keep a single failed primary member and a fully unavailable primary table as separate proposed scenarios with separately written expectations.
\nReview the virtual server’s type and the relevant traffic path with the network owner. Select a harmless application transaction that can be observed independently of the health check. Avoid describing a successful probe as proof of every application dependency or promising an interruption duration that has not been measured.
\nUse an isolated relayd arrangement or an expressly approved maintenance exercise for failure testing. Name the person who may withdraw a test host and the condition for restoring it. Preserve the original table and check settings, and agree how the normal primary arrangement will be reconciled after the exercise.
\nProposed verification: record the initial host-check states and perform the approved partial-primary case. Observe the selected destination and application transaction without assuming the backup table should activate. Then, only within the approved exercise, test the complete-primary-unavailable case and compare the actual selection with the documented condition.
\nRetain check results, table membership, timestamps and the independent application observations for both cases. Restore the intended host population and verify the resulting normal arrangement separately. Keep an unexpected probe result or connection failure as an unresolved finding rather than modifying the check merely to produce a green display.
\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: Review the health-check meaning before relying on a backup table. Keep a failed individual host and a completely failed primary table as different cases in the failover plan.\nSource fact: what the authority says\nThe OPNsense relayd reference groups hosts into tables and allows a host to belong to more than one table. A table check determines whether a host group is ready, with examples ranging from ICMP to an HTTP URI and response-code check. A virtual server can use primary and backup tables; the backup is used when all primary-table hosts are down according to the configured check. Its server type distinguishes transparent layer-three redirection from layer-seven relay operation.\nWhat the source does not establish\nThis article covers the documented table-check and backup-selection boundary. It does not provide an application availability guarantee, a universal probe design or permission to create a production failure to demonstrate failover.\nApplicability questions\n\nWhat does the configured table check actually test?\nWhich hosts belong to the primary and backup tables?\nWhat should happen when one primary host fails versus all primary hosts?\nWhich server type and application observation are required for this service?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends describing the intended failure in operational terms before choosing a probe. Ask the application owner whether a network response or a named HTTP response is the observation needed for this particular service. Document the selected check and expected healthy response without treating either example as a universal availability test.\nBuild a table-membership map that names every primary and backup host. Mark any host used in more than one table so the operator can explain the test population. Keep a single failed primary member and a fully unavailable primary table as separate proposed scenarios with separately written expectations.\nReview the virtual server’s type and the relevant traffic path with the network owner. Select a harmless application transaction that can be observed independently of the health check. Avoid describing a successful probe as proof of every application dependency or promising an interruption duration that has not been measured.\nUse an isolated relayd arrangement or an expressly approved maintenance exercise for failure testing. Name the person who may withdraw a test host and the condition for restoring it. Preserve the original table and check settings, and agree how the normal primary arrangement will be reconciled after the exercise.\nVerification and evidence\nProposed verification: record the initial host-check states and perform the approved partial-primary case. Observe the selected destination and application transaction without assuming the backup table should activate. Then, only within the approved exercise, test the complete-primary-unavailable case and compare the actual selection with the documented condition.\nRetain check results, table membership, timestamps and the independent application observations for both cases. Restore the intended host population and verify the resulting normal arrangement separately. Keep an unexpected probe result or connection failure as an unresolved finding rather than modifying the check merely to produce a green display.\nOfficial references\n\nOPNsense — Relayd — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "Bottom line: Review the health-check meaning before relying on a backup table. Keep a failed individual host and a completely failed primary table as different cases in the failover plan.\n\n## Source fact: what the authority says\n\nThe [OPNsense relayd reference](https://docs.opnsense.org/manual/relayd.html) groups hosts into tables and allows a host to belong to more than one table. A table check determines whether a host group is ready, with examples ranging from ICMP to an HTTP URI and response-code check. A virtual server can use primary and backup tables; the backup is used when all primary-table hosts are down according to the configured check. Its server type distinguishes transparent layer-three redirection from layer-seven relay operation.\n\n## What the source does not establish\n\nThis article covers the documented table-check and backup-selection boundary. It does not provide an application availability guarantee, a universal probe design or permission to create a production failure to demonstrate failover.\n\n## Applicability questions\n\n- What does the configured table check actually test?\n\n- Which hosts belong to the primary and backup tables?\n\n- What should happen when one primary host fails versus all primary hosts?\n\n- Which server type and application observation are required for this service?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends describing the intended failure in operational terms before choosing a probe. Ask the application owner whether a network response or a named HTTP response is the observation needed for this particular service. Document the selected check and expected healthy response without treating either example as a universal availability test.\n\nBuild a table-membership map that names every primary and backup host. Mark any host used in more than one table so the operator can explain the test population. Keep a single failed primary member and a fully unavailable primary table as separate proposed scenarios with separately written expectations.\n\nReview the virtual server’s type and the relevant traffic path with the network owner. Select a harmless application transaction that can be observed independently of the health check. Avoid describing a successful probe as proof of every application dependency or promising an interruption duration that has not been measured.\n\nUse an isolated relayd arrangement or an expressly approved maintenance exercise for failure testing. Name the person who may withdraw a test host and the condition for restoring it. Preserve the original table and check settings, and agree how the normal primary arrangement will be reconciled after the exercise.\n\n## Verification and evidence\n\nProposed verification: record the initial host-check states and perform the approved partial-primary case. Observe the selected destination and application transaction without assuming the backup table should activate. Then, only within the approved exercise, test the complete-primary-unavailable case and compare the actual selection with the documented condition.\n\nRetain check results, table membership, timestamps and the independent application observations for both cases. Restore the intended host population and verify the resulting normal arrangement separately. Keep an unexpected probe result or connection failure as an unresolved finding rather than modifying the check merely to produce a green display.\n\n## Official references\n\n- [OPNsense — Relayd](https://docs.opnsense.org/manual/relayd.html) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 30, 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/match-relayd-backup-activation-to-the-primary-health-check/", "url": "https://update.dsesecurity.com/updates/match-relayd-backup-activation-to-the-primary-health-check/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-30" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/match-relayd-backup-activation-to-the-primary-health-check/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Business Continuity", "item": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "ListItem", "position": 3, "name": "Match relayd backup activation to the primary health check", "item": "https://update.dsesecurity.com/updates/match-relayd-backup-activation-to-the-primary-health-check/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/match-relayd-backup-activation-to-the-primary-health-check/#article", "identifier": "https://update.dsesecurity.com/updates/match-relayd-backup-activation-to-the-primary-health-check/", "url": "https://update.dsesecurity.com/updates/match-relayd-backup-activation-to-the-primary-health-check/", "headline": "Match relayd backup activation to the primary health check", "description": "Review what relayd’s table check measures before relying on its all-primary-hosts-down condition to activate a backup table.", "abstract": "Review what relayd’s table check measures before relying on its all-primary-hosts-down condition to activate a backup table.", "articleBody": "Bottom line: Review the health-check meaning before relying on a backup table. Keep a failed individual host and a completely failed primary table as different cases in the failover plan.\nSource fact: what the authority says\nThe OPNsense relayd reference groups hosts into tables and allows a host to belong to more than one table. A table check determines whether a host group is ready, with examples ranging from ICMP to an HTTP URI and response-code check. A virtual server can use primary and backup tables; the backup is used when all primary-table hosts are down according to the configured check. Its server type distinguishes transparent layer-three redirection from layer-seven relay operation.\nWhat the source does not establish\nThis article covers the documented table-check and backup-selection boundary. It does not provide an application availability guarantee, a universal probe design or permission to create a production failure to demonstrate failover.\nApplicability questions\n\nWhat does the configured table check actually test?\nWhich hosts belong to the primary and backup tables?\nWhat should happen when one primary host fails versus all primary hosts?\nWhich server type and application observation are required for this service?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends describing the intended failure in operational terms before choosing a probe. Ask the application owner whether a network response or a named HTTP response is the observation needed for this particular service. Document the selected check and expected healthy response without treating either example as a universal availability test.\nBuild a table-membership map that names every primary and backup host. Mark any host used in more than one table so the operator can explain the test population. Keep a single failed primary member and a fully unavailable primary table as separate proposed scenarios with separately written expectations.\nReview the virtual server’s type and the relevant traffic path with the network owner. Select a harmless application transaction that can be observed independently of the health check. Avoid describing a successful probe as proof of every application dependency or promising an interruption duration that has not been measured.\nUse an isolated relayd arrangement or an expressly approved maintenance exercise for failure testing. Name the person who may withdraw a test host and the condition for restoring it. Preserve the original table and check settings, and agree how the normal primary arrangement will be reconciled after the exercise.\nVerification and evidence\nProposed verification: record the initial host-check states and perform the approved partial-primary case. Observe the selected destination and application transaction without assuming the backup table should activate. Then, only within the approved exercise, test the complete-primary-unavailable case and compare the actual selection with the documented condition.\nRetain check results, table membership, timestamps and the independent application observations for both cases. Restore the intended host population and verify the resulting normal arrangement separately. Keep an unexpected probe result or connection failure as an unresolved finding rather than modifying the check merely to produce a green display.\nOfficial references\n\nOPNsense — Relayd — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-30T06:04:46+00:00", "dateModified": "2026-10-30T06:05:13+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/match-relayd-backup-activation-to-the-primary-health-check/" }, "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/match-relayd-backup-activation-to-the-primary-health-check/#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": "Match relayd backup activation to the primary health check" }, "articleSection": [ "Business Continuity", "Networks & Infrastructure" ], "keywords": [ "Business Continuity", "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 530, "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 — Relayd", "url": "https://docs.opnsense.org/manual/relayd.html" } } ] } }