Disaster Recovery

How Wytness protects your audit data, what happens when things go wrong, and our recovery commitments.

Defence in Depth

Every audit event passes through multiple independent storage layers. No single failure causes permanent data loss. The append-only archive is the ultimate source of truth — every verified event is stored with 7-year retention and a soft-delete recovery window, and every event is Ed25519-signed and hash-chained so any tampering is cryptographically detectable.

Storage LayerPurposeMax Data Loss (RPO)Recovery Time (RTO)
Operational databaseUsers, orgs, API keys, signing keys< 5 minutes< 1 hour
Analytics store (hot retention)Queryable audit events and anomaly alerts0 (rebuildable from archive)Minutes (restart) or hours (full rebuild)
Archive store (cold retention)Append-only encrypted Azure Blob archive of every verified event (7-year retention with a soft-delete recovery window)0< 15 minutes
SDK offline bufferLocal fallback file when API is unreachable0Automatic on next successful call
Tip
RPO = Recovery Point Objective (maximum data loss window). RTO = Recovery Time Objective (maximum downtime to restore). An RPO of 0 means no event data is lost — even in a disaster scenario.

SDK Offline Resilience

If our API becomes unreachable, your agents don't stop working. The SDK has built-in offline buffering with automatic replay.

1Agent emits event

Your agent performs an action. The SDK signs the event locally with Ed25519.

2API unreachable

SDK attempts to send the event. Connection fails.

3Local buffer

Event is written to a local fallback file. No data is lost.

4API recovers

On the next successful call, the SDK automatically replays all buffered events in order.

5Buffer cleared

Successfully replayed events are removed. Failures remain for the next attempt.

Both Python and TypeScript SDKs implement this pattern. Your agent code requires no changes — offline resilience is automatic.

What Happens When Things Go Wrong

ScenarioYour ExperienceYour Data
API outageSDK buffers events locally; dashboard temporarily unavailableNo event loss — buffered events replay automatically
Analytics store downDashboard queries unavailable; ingest queues to SDK bufferNo event loss — archive is independent and rebuilds the analytics store on recovery
Archive store downIngest still writes the analytics store; events queue for archive retryNo event loss — events held in a dead-letter queue on persistent failure
Database outageLogin and dashboard unavailablePoint-in-time recovery within minutes
Full region outagePlatform temporarily unavailableNo permanent data loss — database backups are geo-replicated to a secondary region; the audit archive is preserved with a soft-delete recovery window

Infrastructure SLAs

Built on cloud infrastructure with high-availability SLAs (99.95% / 99.99% depending on service). See Pricing for per-tier availability and support response commitments.

Note
Database backups use geo-redundant storage; the audit archive uses geo-redundant storage (GRS) in the primary region and locally-redundant storage (LRS) in data-residency regions to keep data in-region, both with a soft-delete recovery window. Enterprise customers can extend backup policies, deploy read replicas, and configure private endpoints — all within their own cloud subscription.

We set no cookies. Sign-in and preferences use essential first-party browser storage only — no tracking, advertising, or third-party analytics. Privacy Policy

Disaster Recovery
TABLE OF CONTENTS