Unavailability never blocks your page or your login. The SDK runs asynchronously outside the authentication path. A disruption only affects event ingestion, which the SDK retries later, and the management console.
1. Deployment options
2. Availability configurations
A dedicated instance comes in three configurations. Each builds on the previous one. The application layer runs across three Availability Zones (AZ) in every configuration. Event ingestion does not need the primary data store to run: events are buffered durably outside it. The configurations differ in how the primary data store is protected.2.1 Standard
- Availability: 99.9% per month for event ingestion and the management console.
- Infrastructure: the application runs across three AZs in one AWS region. The primary data store runs in one AZ with continuous backup.
- Resiliency: if an AZ fails, the application and event ingestion continue in the remaining AZs. If the AZ of the primary data store fails, the data store is restored into a healthy AZ with point-in-time recovery.
2.2 Multi-AZ data store
- Availability: 99.99% per month for event ingestion, 99.9% for the management console.
- Infrastructure: the application runs across three AZs. The primary data store runs in two AZs with a synchronous standby.
- Resiliency: the failure of one AZ is handled automatically with near-zero data loss. A full regional failure requires a restore from the cross-region backup.
2.3 Multi-AZ data store with geo-redundancy
- Availability: as Multi-AZ data store.
- Infrastructure: adds near real-time data replication to a second AWS region and a standby application environment there.
- Resiliency: in a full regional outage, the service fails over to the second region via push-button failover.
3. Recovery objectives
The recovery time objective (RTO) is the time until the service is available again. The recovery point objective (RPO) is the maximum window of data that can be lost.4. Behaviour during a disruption
Observe is telemetry only and sits outside the authentication path. A disruption delays or pauses measurement. It never blocks, delays or changes a login.- Sign-in: unaffected. The SDK loads and runs asynchronously.
- Event delivery: failed sends are retried with exponential backoff. Events can be kept in a bounded browser outbox and resent on the next page load. Each event carries an idempotency ID, so resends are deduplicated.
- Ingestion: a durable queue decouples ingestion from processing. It absorbs traffic peaks and keeps accepting events while processing or the primary data store is unavailable.
- Processing: queued events are processed once the primary data store is available again, and flows and KPIs are recomputed from raw events. Dashboards, alerts and exports catch up automatically.
- Management console and API: unavailable for the duration of the outage. Data loss is limited to the RPO of your configuration.
5. Backup and recovery
- Continuous backup: point-in-time recovery for the primary data store with a five minute RPO, plus daily, weekly and monthly recovery points.
- Cross-region copy: there is always at least one backup in a second AWS region available that is at most 24 hours old.
- Cross-account copy: backups are also copied to a separate, isolated AWS account for disaster recovery.
- Immutable backups: backup vaults are locked, so recovery points cannot be altered or deleted before their retention ends.
- Restore tests: backups are restored automatically on a schedule, the restored data is validated and a failed or missing restore raises an alert.
6. Support and incident response
- 24/7 monitoring and on-call: every instance is monitored 24/7 by the Corbado team, with an engineer on call around the clock. Automated monitoring of ingestion, processing and the management console pages the on-call engineer immediately.
- Critical incidents (P1): any disruption that materially impairs availability or event ingestion receives a first response within one hour, 24/7. In practice the response is usually much faster, and in most cases Corbado detects a problem before you notice it.
- Incident communication: your named contacts are informed when a P1 incident starts, receive updates until it is resolved and get a written root cause analysis afterwards.
- Other requests: first response within one business day.
7. Service level terms
- Monthly availability: the percentage of minutes in a calendar month during which a component can perform its documented core functionality.
- Not counted as unavailability: maintenance announced at least 24 hours in advance, causes on your side, internet infrastructure outside Corbado’s control, changes to the SDK or service not made or authorized by Corbado and force majeure.
- Service credits: apply if a component misses its availability target in a calendar month.
- Your policies: login is critical. If your corporate policies require specific terms, for example on response times, notification or reporting, Corbado can adjust them.
Security & compliance
Certifications, hosting, encryption and access control.
Privacy & data policies
Built-in protections, retention per purpose and user requests.
Trust Center
ISO 27001 certificate, SOC 2 Type II report and subprocessors.