Choose one important action
Start with a form whose failure creates a clear dead end: a contact request, quote enquiry, application or booking handoff. Protect the action itself rather than treating every page error as a form failure.
Document what healthy progress looks like, such as a confirmation state or a same-origin navigation. That evidence is more useful than a generic page-uptime check.
Keep the original form in control
A fallback script should not cancel submission, rewrite the request, replace validation or intercept the business's response. If monitoring cannot load, the site must continue exactly as its own code dictates.
SiteAirbag's runtime is designed around this fail-open boundary. Conservative evidence is required before an eligible configured backup can be shown.
Offer the smallest safe alternative
A direct alternate page or published phone route is lower risk than collecting more data. If an independent backup request is necessary, request only business-safe details needed to respond.
- Never request passwords, payment-card data, authentication codes, government identifiers or health information.
- Tell the visitor that a request is being captured, not that a booking, refund, cancellation or transaction is complete.
- Link the business's privacy notice and define who will respond.
Measure operational evidence, not revenue
Count detected incidents, fallback views and deliberate backup submissions separately. A backup request is not a conversion, sale or recovered revenue. Review false alarms and missed issues so detection can improve without inflating the business claim.
Verify before relying on it
Test the original action and configured backup on desktop and mobile after installation and after material site changes. Review the coverage page, installation instructions, and security model. SiteAirbag is a fail-open recovery layer, not a guarantee that every failure is detectable or every request becomes a business outcome.