Business Continuity & Disaster Recovery

Last updated: April 16, 2026

Available on: Mac, Windows, iOS, Android

Wispr Flow uses automated backups, infrastructure redundancy, and real-time monitoring to keep your data protected and the service running — even during unexpected disruptions.

What it is

Business continuity and disaster recovery (BC/DR) encompasses the technical systems, redundancies, and organizational practices that protect your data and maintain service availability. This includes automated backups, infrastructure redundancy, real-time monitoring, and incident response procedures.

How it works in Flow

Client-side backups

Note: Client-side backups apply to Mac and Windows only.

  • Daily local backup: The desktop app backs up its SQLite database daily at noon, if the app is running.

  • Single copy retention: Only the most recent backup copy is retained.

  • Local storage: Backups are stored locally on your device without additional encryption beyond system-level protections.

  • Audio data cleanup: Audio recordings older than 14 days are automatically removed from local storage, while transcript text is preserved. This runs as part of the daily maintenance cron. Audio records pending upload are excluded from cleanup to avoid losing unsynced data.

  • Automatic recovery: If the local database becomes corrupted — for example, after an unexpected app crash or failed migration — the app detects the issue, removes the corrupted database, and restarts to restore a working state. After recovery, notes are automatically re-synced from the cloud on the next app launch.

  • Data retention enforcement: For users with a 24-hour data retention policy (whether set by enterprise policy or chosen in personal settings), the app deletes local history and formatting data older than one day. This runs both at app startup and as part of the daily maintenance cron.

Automatic recovery — platform details

Recovery behavior differs between Mac and Windows:

  • Mac: Only the main database file is removed during corruption recovery.

  • Windows: The main file plus journal files (WAL/SHM) are all removed with retry logic for file locking. The Windows helper process waits at least 15 seconds of unresponsiveness before restarting. Successive failed relaunches use increasing backoff delays (up to 16 seconds), and after 7 failed attempts, the app shows a persistent failure notification. The backoff counter resets if the helper runs successfully for more than 1 minute, and also resets on every system wake. A 60-second wake recovery mode extends IPC timeouts after sleep, preventing false-positive restarts.

On both platforms, the app correctly distinguishes between the helper being genuinely unresponsive and the system having been paused (such as waking from sleep or App Nap), avoiding unnecessary restarts.

Note: Server-side and cloud infrastructure backups are managed separately by AWS.

Infrastructure redundancy

  • AWS-managed services: S3 and SQS provide inherent redundancy.

  • Database health checks: Connection pool health checks verify database connections before use.

  • Redis connection pooling: SSL/TLS encryption, health checks, keepalive, and dedicated blocking pool.

  • Message queue reliability: SQS FIFO queue support with message deduplication.

  • Read replica support: Separate read-only database pool with automatic fallback to the primary if the replica is unavailable.

  • Connection leak detection: Connections held longer than expected trigger warnings, and prolonged leaks are forcefully reclaimed to maintain pool health.

Connection resilience

  • WebSocket health monitoring: 1-second pings with a default 2-second pong timeout. On failure, the connection closes with a categorized failure reason for telemetry. The dictation system then handles retry or fallback depending on the active transcription path.

  • Intelligent failure handling: Multiple failure classification types are recorded for telemetry and analytics, enabling post-hoc diagnostics of connection issues. The dictation system uses these categories for downstream retry decisions.

  • Partial failure recovery: On desktop, audio replay resumes from the last successfully processed point. On iOS (when gRPC is active), replay rewinds exactly 2 buffers before the last processed point to avoid boundary gaps. If no text was received before the failure, playback restarts from the beginning.

  • Server-side timeouts: 120-second auth timeout, 10-second between-message timeout, and an approximate 6-minute audio duration limit (361 seconds, with an additional 10-second processing buffer). Maximum audio upload size is 25 MB. iOS enforces a 5-minute client-side dictation limit. Desktop has a 20-minute client-side timeout (with a warning at 19 minutes), but the server-side limit is reached first in practice.

  • Rate limiting: Per-user limits (3 concurrent requests, 5 requests per 10 seconds) prevent overload.

  • Enterprise custom CA support: Custom root CA certificate support for corporate network environments on Mac and Windows. Trusted certificates include Node.js/Mozilla built-in root certificates plus self-signed root CA certificates from the OS keychain (macOS) or certificate store (Windows). Intermediate certificates from the OS store are excluded.

  • Transcription fallback: On desktop, if gRPC fails, the system falls back to WebSocket for subsequent dictations, with a default 3-hour cooldown before retrying gRPC (configurable via feature flag). Within a single session, a parallel HTTP request can race against gRPC when heartbeat timeouts fire. The parallel HTTP fallback is only attempted for recordings under 30 seconds.

Capacity management

  • API rate limiting: 3 concurrent requests and 5 requests per 10 seconds per user.

  • Rate limiter tracking: LRU cache tracking up to 65,536 recently active users for rate limiting state. Older users' rate limit state is evicted.

  • Backend connection pooling: Up to 100 concurrent connections and 20 keepalive connections per backend service, with HTTP/2 enabled.

Rate limiting applies to individual authenticated users only. Requests from organization/API clients bypass rate limiting.

Monitoring and observability

Wispr Flow uses comprehensive monitoring to detect and respond to issues quickly:

  • Sentry integration: Error tracking and performance monitoring across backend, desktop, iOS, and Android.

  • Critical error capture: On iOS, crashes, app hangs, MetricKit exceptions, and fatal errors always bypass sampling and are captured at 100%. On desktop, events tagged as severe bypass the default 0.05% sample rate. Backend events are sampled at 1%. Android uses a 5% general event sample rate and has always-on Sentry Logs enabled.

  • Performance tracing: Dictation lifecycle and authentication flows are traced for performance monitoring. Android traces dictation and service lifecycles at a 25% sample rate.

  • iOS-specific monitoring: App hang detection (10 seconds or more), MetricKit integration for CPU and disk exceptions, and session replay. Session replay captures 10% of sessions normally and 100% when errors occur. Screenshots and view hierarchy snapshots are attached to error events (main app only, not keyboard extension). Non-critical events are sampled at 1% before debouncing. Transient network errors are automatically filtered from Sentry reporting.

  • Error debouncing: On desktop, repeated identical errors within 5 minutes are suppressed (only the first and periodic summaries are sent). Novel errors are always sent at least once regardless of sampling. On iOS, non-critical events use a 60-second debounce window.

  • Backend logging: HTTP access logging via remote log service.

  • Distributed tracing: Cross-platform tracing via trace headers.

Data center security

Physical data center security is provided and managed by AWS. AWS data centers include:

  • Physical access controls and surveillance systems

  • Environmental controls (fire suppression, temperature, humidity)

  • Redundant power and network connectivity

  • 24/7 physical security personnel

Wispr reviews cloud provider SOC 2 reports annually to verify data center controls.

Organizational policies

  • Business continuity planning: Identification of critical business functions, recovery time objectives (RTO), recovery point objectives (RPO), alternative work arrangements, and regular plan reviews.

  • Disaster recovery: The incident response team activates disaster recovery procedures, restores critical systems according to priority, notifies customers of service impacts, and conducts post-incident reviews.

  • Emergency response: On-call personnel respond to critical alerts with escalation procedures, communication protocols, and incident command structure.

  • Supplier resilience: Critical suppliers are evaluated for business continuity capabilities, required to maintain disaster recovery plans, and monitored for service availability.

  • Communication during incidents: Customers are notified via email or status page with regular updates during extended outages and post-incident reports.

FAQs

How often is my data backed up?

The desktop app performs a daily local backup at noon if the app is running. Only the most recent backup is retained. Server-side backups are managed by AWS.

How will I know if there's a service disruption?

Wispr notifies you via email or the status page during incidents, with regular updates during extended outages and a post-incident report detailing root cause and remediation.

What happens if my internet connection drops while dictating?

Flow falls back to an alternative transcription method and replays audio that was not yet processed. In most cases, no audio is lost, but partial loss is possible during extended failures or when large amounts of unprocessed audio have accumulated.

Limitations and notes

  • Client-side backups are available on Mac and Windows only.

  • Custom root CA certificate support is available on Mac and Windows only.

  • Local backups are stored on your device without additional encryption beyond system-level protections.

  • Only the most recent local backup is retained.

  • Maximum audio upload size is 25 MB, with an approximate 6-minute server-side audio duration limit (361 seconds). iOS enforces a 5-minute client-side limit. Desktop has a 20-minute client-side timeout, but the server-side limit applies first.