When a real estate closing depends on a remote notarization completing on schedule, platform availability becomes mission critical. A server failure, network outage, or regional disaster at the wrong moment can delay transactions, frustrate parties, and create legal complications. Understanding how RON platforms protect against these scenarios helps businesses evaluate providers and plan for contingencies.
This guide examines the infrastructure, processes, and safeguards that ensure online notarization platforms remain available when you need them most.
Why Availability Matters in Notarization
Traditional in-person notarization rarely faced availability concerns. If one notary was unavailable, another could step in. The process depended on people and paper, both of which proved remarkably resilient to technical failures.
Remote online notarization changes this equation entirely. The process depends on servers hosting the platform, databases storing documents and credentials, video conferencing infrastructure handling real-time communication, identity verification services confirming signer identity, and network connectivity linking all participants. A failure in any component can prevent a notarization from completing.
For time-sensitive transactions, the stakes are significant. A delayed closing might mean a buyer loses their rate lock, a seller misses their moving date, or a business deal falls through. These consequences extend far beyond the immediate inconvenience.
Understanding Availability Metrics
Platform providers express availability commitments through service level agreements (SLAs) that specify uptime percentages. Understanding what these numbers mean in practice helps evaluate provider commitments.
The Nines of Availability
Availability percentages are often expressed as “nines.” Each additional nine represents a tenfold improvement in reliability:
99% availability allows approximately 87.6 hours of downtime per year, or about 7.3 hours per month. This level might seem acceptable until you consider that those hours could occur at any time.
99.9% availability (three nines) reduces allowable downtime to approximately 8.76 hours per year, or about 43 minutes per month. Most commercial SaaS platforms commit to this level.
99.99% availability (four nines) limits downtime to approximately 52 minutes per year, or about 4.3 minutes per month. Achieving this level requires sophisticated redundancy and failover mechanisms.
99.999% availability (five nines) allows only about 5.26 minutes of downtime per year. This level is typically reserved for critical infrastructure and requires substantial investment in redundancy.
What SLAs Actually Cover
Service level agreements define what constitutes downtime and what remedies apply when commitments are missed. Reading the fine print reveals important nuances.
Most SLAs exclude scheduled maintenance windows from downtime calculations. A platform might achieve 99.99% availability according to its SLA while still having regular maintenance periods that affect some users.
SLAs typically measure availability based on the provider’s own monitoring. If their systems report the service as available, downtime does not accrue, even if some users experience problems due to network issues between them and the provider.
Remedies for SLA breaches usually take the form of service credits, not cash refunds. A breach might entitle you to 10% of the monthly fee as credit toward future services. This rarely compensates for actual business impact from an outage.
The calculation method matters as well. Some providers calculate availability monthly, while others use annual periods. A service that goes down for an entire day might still meet an annual SLA while dramatically failing monthly expectations.
Cloud Infrastructure Fundamentals
Modern RON platforms run on cloud infrastructure provided by major vendors like Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform (GCP). Understanding how this infrastructure works illuminates how platforms achieve high availability.
Regions and Availability Zones
Cloud providers organize their infrastructure into regions and availability zones. A region is a geographic area containing multiple data centers. An availability zone is a distinct location within a region, typically a separate data center with independent power, cooling, and network connectivity.
AWS operates 26 geographic regions spanning over 80 availability zones worldwide. Azure has a similar global footprint. This distribution enables applications to run close to users while providing options for geographic redundancy.
When a platform deploys across multiple availability zones within a region, it gains protection against single-point failures. If one data center loses power or network connectivity, services continue running in other zones. The zones are close enough to maintain low-latency communication but far enough apart to avoid shared risks from local events like power grid failures.
Multi-Region Deployment
Availability zones protect against local failures but not regional disasters. A hurricane, earthquake, or widespread power outage could affect all zones within a region simultaneously. Multi-region deployment provides protection against these scenarios.
With multi-region architecture, the platform maintains infrastructure in geographically separated regions. If the primary region becomes unavailable, traffic shifts to the secondary region. This failover can happen automatically or require manual intervention depending on the architecture.
Multi-region deployment introduces complexity. Data must be replicated between regions, and applications must handle the latency involved in cross-region communication. Not all platforms invest in this level of redundancy, making it an important evaluation criterion.
The Shared Responsibility Model
Cloud providers guarantee the availability of their infrastructure, not the applications running on it. This shared responsibility model means that even when AWS or Azure achieves their stated uptime, a poorly architected application might still fail.
For example, if a RON platform runs on a single virtual machine without redundancy, and that machine fails, the application goes down even though the cloud provider’s infrastructure remains available. The provider fulfilled their commitment; the platform operator did not design for resilience.
Evaluating platform architecture matters because you cannot simply rely on the cloud provider’s SLA. The platform operator must design, implement, and maintain systems that take advantage of cloud redundancy features.
Redundancy Strategies
Achieving high availability requires eliminating single points of failure throughout the system. Redundancy strategies address this at multiple levels.
Active-Active vs. Active-Passive
Active-active configurations run identical systems simultaneously, distributing load across all of them. If any system fails, the others continue handling requests without interruption. This approach provides both redundancy and increased capacity.
Active-passive configurations maintain standby systems that remain idle until needed. When the active system fails, the passive system takes over. This approach costs less than active-active but involves some delay during failover.
For notarization platforms, active-active architectures within a region provide the best user experience. Multiple servers handle requests simultaneously, and the failure of any single server causes minimal disruption. Active-passive arrangements between regions provide disaster recovery capability.
Database Redundancy
Databases present particular challenges for redundancy. They must maintain consistency, meaning all copies must reflect the same data. Achieving consistency while maintaining availability requires careful engineering.
Synchronous replication writes data to multiple database copies before confirming the transaction complete. This ensures consistency but adds latency and creates a dependency where the primary cannot function without the replicas.
Asynchronous replication confirms transactions on the primary before copying to replicas. This provides better performance but creates a window where replicas lag behind the primary. If the primary fails during this window, some recent data might be lost.
Modern cloud databases offer various replication options with different tradeoffs. Azure SQL Database, for example, offers 99.99% availability for standard configurations and 99.995% with zone redundancy enabled. Recovery time objectives of 30 seconds and recovery point objectives of 5 seconds are achievable with proper configuration.
Load Balancing
Load balancers distribute incoming requests across multiple servers. Beyond improving performance by spreading load, they provide redundancy by automatically routing around failed servers.
Global load balancers can distribute traffic across geographic regions, directing users to the nearest available endpoint. If one region becomes unavailable, the load balancer redirects traffic to other regions automatically.
Health checks enable load balancers to detect failed servers. The load balancer periodically tests each server’s responsiveness. Servers that fail health checks are removed from rotation until they recover.
Video and Real-Time Communication Resilience
Notarization sessions depend on real-time video communication between signers and notaries. This component faces unique availability challenges because video cannot simply retry like a web request.
WebRTC and Network Variability
Most RON platforms use WebRTC (Web Real-Time Communication) for video sessions. WebRTC establishes peer-to-peer connections when possible and routes through relay servers when direct connection fails.
Network conditions during a session may vary. A brief network interruption might cause video to freeze momentarily before recovering. WebRTC handles these transient issues through internal mechanisms like packet loss concealment for audio and keyframe requests for video.
More significant disconnections trigger reconnection attempts. The WebRTC connection state machine moves through states including “connected,” “disconnected,” and “failed.” A well-designed platform handles disconnected states gracefully, attempting reconnection before declaring failure.
Media Server Redundancy
When direct peer-to-peer connection is not possible, sessions route through media servers (often called TURN servers). These servers must be highly available because their failure would terminate active sessions.
Robust platforms deploy media servers across multiple availability zones and regions. Session state can be transferred between servers if needed, though this typically causes a brief interruption. The goal is ensuring that media server failure does not terminate sessions that would otherwise continue.
Session Recovery
What happens to an active notarization session if the platform experiences an outage? The answer depends on how the platform handles session state.
Sessions in progress at the time of an outage typically cannot continue seamlessly. The video connection is interrupted, and participants lose access to the shared document view. When the platform recovers, participants must reconnect and potentially restart certain steps.
Well-designed platforms preserve session metadata through outages. Documents, identity verification results, and partial signatures survive if stored in redundant databases. When participants reconnect, they can resume from where they left off rather than starting over.
Session recordings present particular recovery challenges. If the recording was streaming to a server that failed, some recording data might be lost. Platforms mitigate this by writing recording data to durable storage continuously rather than waiting until session end.
Backup and Recovery Requirements
Beyond real-time availability, platforms must protect data against loss and corruption. This protection involves backup strategies, retention policies, and tested recovery procedures.
Recovery Objectives
Two key metrics define backup and recovery requirements:
Recovery Point Objective (RPO) specifies the maximum acceptable data loss measured in time. An RPO of one hour means you accept potentially losing up to one hour of data in a disaster. Backups must occur at least this frequently.
Recovery Time Objective (RTO) specifies how quickly systems must be restored after an outage. An RTO of four hours means the platform must be operational within four hours of declaring a disaster.
For notarization platforms, low RPO matters because completed notarizations must not be lost. Losing the record of a completed notarization could have legal consequences. RTO matters because extended outages delay pending transactions.
The 3-2-1 Backup Rule
A fundamental backup strategy maintains three copies of data, using two different storage media types, with one copy stored off-site. This rule ensures that no single failure can destroy all copies.
Modern implementations might translate this to primary database, replicated database in another availability zone, and regular backups to geographically separate storage. The principle remains: diversify storage locations and technologies to prevent correlated failures.
Backup Testing
Backups are worthless if they cannot be restored. Regular testing verifies that backup data is complete, uncorrupted, and actually restorable within the target RTO.
SOC 2 compliance requires documented evidence of backup testing. This means platforms undergo regular verification that their recovery procedures work as designed. When evaluating providers, ask about backup testing frequency and results.
SOC 2 and Compliance Requirements
SOC 2 compliance provides assurance that platforms maintain appropriate controls for security, availability, and other trust criteria. The availability criterion specifically addresses disaster recovery and business continuity.
Availability Trust Services Criteria
SOC 2’s availability criterion (Section A1) requires organizations to authorize, design, implement, and monitor systems that meet availability objectives. This includes environmental protections, software, data backup processes, and recovery infrastructure.
Section A1.2 requires documented data backup and recovery processes along with supporting infrastructure. Auditors verify that backup procedures exist, are followed, and align with stated objectives.
Section A1.3 requires testing recovery plans and procedures on a regular basis. Platforms must demonstrate not just that recovery plans exist, but that they have been tested and proven effective.
Type I vs. Type II Reports
SOC 2 Type I reports assess whether controls are suitably designed at a specific point in time. Type II reports assess whether controls operated effectively over a period, typically 6-12 months.
For disaster recovery assurance, Type II reports provide more confidence. They demonstrate that the platform not only has recovery plans but has maintained and tested them throughout the audit period.
What SOC 2 Does Not Guarantee
SOC 2 compliance indicates that a platform has implemented appropriate controls, but it does not guarantee any specific level of availability. A SOC 2 compliant platform might still experience outages.
Additionally, SOC 2 audits occur periodically. Controls that existed during the audit period might have changed since. Annual re-certification provides ongoing assurance, but the gap between audits represents a period of reduced visibility.
Evaluating Platform Resilience
When selecting a RON platform, several questions help assess disaster recovery and business continuity capabilities.
Architecture Questions
Ask where the platform infrastructure is hosted and across how many regions or availability zones. Multi-region deployment provides stronger disaster protection than single-region.
Inquire about database redundancy. How is data replicated? What is the recovery point objective? Understanding these details reveals how much data might be lost in various failure scenarios.
Ask about video infrastructure specifically. Are media servers redundant? What happens to active sessions if a server fails?
Process Questions
Request information about backup frequency and testing. How often are backups verified through actual restoration? When was the last successful test?
Ask about the disaster recovery plan. Does a documented plan exist? How recently was it updated? Has it been tested through actual drills?
Inquire about incident response procedures. How are outages detected? Who is notified? What is the escalation path? How are customers informed?
Evidence Questions
Request the platform’s SOC 2 report if available. Review the availability-related controls and any noted exceptions.
Ask about historical uptime. What was actual availability over the past year? Were there significant outages? What caused them and how were they resolved?
Request the SLA terms and understand what they actually commit to. Compare the contractual commitment against the historical performance.
What Users Should Know About Outages
Even well-designed platforms occasionally experience outages. Understanding what to expect helps you respond appropriately.
During an Outage
If you experience problems connecting to a RON platform, first verify that the issue is with the platform rather than your own network. Try accessing other websites to confirm general internet connectivity.
Check the platform’s status page if one exists. Major platforms publish real-time status information showing which services are affected and estimated resolution time.
If you have a transaction in progress, communicate with other parties about the delay. For time-sensitive closings, discuss contingency plans such as rescheduling or using alternative notarization methods.
Pending Sessions
Sessions that were scheduled but not yet started typically reschedule easily once the platform recovers. The documents and signer information remain in the system.
Sessions that were in progress when the outage occurred present more complexity. Depending on how far the session progressed and what the platform preserved, you might resume mid-session or need to restart.
Completed sessions should be unaffected by subsequent outages. Once a notarization is complete and the documents are stored, that data should survive platform disruptions.
Recording and Audit Trail Concerns
If an outage occurs during a session, portions of the recording might be incomplete. Platforms typically cannot recover recording data that was never transmitted or stored.
For sessions affected by outages, request confirmation from the platform about recording completeness. If the recording is incomplete, the notarization may still be valid depending on state requirements, but the evidence is diminished.
Audit trails maintained in redundant databases should survive outages intact. Verify that all expected events appear in the audit trail after any disrupted session.
Building Your Own Contingency Plan
Organizations that depend on notarization for critical transactions should develop their own contingency plans rather than relying entirely on platform resilience.
Alternative Platforms
Maintaining accounts with multiple RON platforms provides a fallback if your primary platform becomes unavailable. This redundancy requires some additional setup and cost but provides insurance against platform-specific outages.
Different platforms may have different state authorizations, so verify that alternatives support notarizations in your relevant jurisdictions.
Scheduling Buffer
For critical transactions, avoid scheduling notarization at the last possible moment. Building in time buffer allows for rescheduling if technical issues arise without missing hard deadlines.
In-Person Backup
In-person notarization remains available as a backup for situations where remote options fail. Maintaining relationships with local notaries provides a fallback, though it sacrifices the convenience that drove RON adoption.
Communication Templates
Prepare communication templates for informing transaction parties about delays. Having language ready reduces stress during time-pressured situations.
Frequently Asked Questions
What happens to my session if the platform goes down mid-notarization?
Your session will be interrupted and you will need to reconnect once the platform recovers. Depending on the platform’s architecture, you may be able to resume from where you left off or may need to restart certain steps. Documents and identity verification completed before the outage should be preserved.
What does 99.9% availability actually mean?
99.9% availability allows approximately 8.76 hours of downtime per year, or about 43 minutes per month. This downtime can occur at any time and may coincide with your critical transactions.
How can I verify a platform’s disaster recovery capabilities?
Request the platform’s SOC 2 Type II report and review availability-related controls. Ask about their infrastructure architecture, backup testing procedures, and historical uptime. Compare contractual SLA commitments against actual performance.
Are RON platforms required to have disaster recovery plans?
SOC 2 compliance, which many platforms pursue, requires documented and tested disaster recovery plans. However, SOC 2 is voluntary. State RON regulations vary in whether they mandate specific availability or recovery requirements.
What is the difference between high availability and disaster recovery?
High availability addresses day-to-day resilience against common failures like server crashes or network blips. Disaster recovery addresses recovery from major events like regional outages or natural disasters that affect entire facilities.
How do cloud providers affect platform availability?
RON platforms run on cloud infrastructure (AWS, Azure, GCP) that provides foundational services. Cloud provider outages can affect RON platforms, but well-architected platforms use redundancy across availability zones and regions to minimize this dependency.
What should I do if a platform outage affects my closing?
Communicate immediately with all transaction parties about the delay. Check the platform’s status page for estimated resolution time. Consider whether alternative notarization methods are viable given time constraints. Document the situation for any parties who may need explanation.
How long are notarization recordings retained if there is a disaster?
Recordings stored in properly backed-up systems should be retained according to state requirements (typically 5-10 years) regardless of individual server failures. The backup and recovery procedures are designed specifically to protect this data.
Conclusion:
Business continuity and disaster recovery capabilities distinguish professional-grade RON platforms from basic solutions. The infrastructure decisions a platform makes, including multi-region deployment, database redundancy, and backup procedures, directly affect whether you can complete critical transactions when unexpected problems occur.
Evaluating these capabilities requires looking beyond marketing claims to understand actual architecture, review SOC 2 reports, and examine historical performance. The investment in understanding platform resilience pays off when you need to rely on the service for time-sensitive transactions.
For organizations that depend on notarization, developing your own contingency plans provides additional protection. Maintaining alternative options, building schedule buffers, and preparing communication templates reduces the impact when any single platform experiences problems.
For a RON platform built on resilient infrastructure with demonstrated business continuity capabilities, BlueNotary provides the reliability that critical transactions demand.
