> ## Documentation Index
> Fetch the complete documentation index at: https://docs.corbado.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Corbado Observe Deployment and Availability

> Hosting models, availability configurations, recovery objectives, support and service level terms for Corbado Observe.

Corbado Observe runs on Corbado's public cloud or as a dedicated instance. For a dedicated instance, availability and recovery follow the configuration you choose. This page summarizes the options for your architecture and procurement review.

<Info>
  **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.
</Info>

## 1. Deployment options

| | Public cloud | Dedicated instance |
| - | - | - |
| **Infrastructure** | Shared AWS infrastructure, operated by Corbado | Own AWS account per customer, operated by Corbado |
| **Region** | Frankfurt, Germany | A region of your choice |
| **Operations** | Upgrades, monitoring and on-call by Corbado | Upgrades, monitoring and on-call by Corbado |
| **Availability configuration** | Standard | Standard, Multi-AZ data store or Multi-AZ data store with geo-redundancy |
| **Fits** | Fast start, no data residency constraints | Data residency, isolation and higher availability requirements |

## 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.

| **Failure event** | **Standard** | **Multi-AZ data store** | **Multi-AZ data store with geo-redundancy** |
| - | - | - | - |
| **Single AZ failure** | RTO: 1-4 h  RPO: up to 5 min | RTO: 1-5 min  RPO: \~0 min | RTO: 1-5 min  RPO: \~0 min |
| **Two AZ failure** | RTO: 1-4 h  RPO: up to 5 min | RTO: 15-30 min  RPO: \~0 min  *Until AWS stabilizes* | RTO: 15-30 min  RPO: \< 1 min  *Push-button failover* |
| **Primary region failure** | RTO: 4-8 h  RPO: up to 24 h  *Manual failover* | RTO: 4-8 h  RPO: up to 24 h  *Manual failover* | RTO: 15-30 min  RPO: \< 1 min  *Push-button failover* |

## 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](/corbado-observe/data-access/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.

Service levels, service credits and the support scope are set in your Enterprise Agreement. [Contact us](mailto:support@corbado.com) to choose a configuration.

<CardGroup cols={3}>
  <Card title="Security & compliance" icon="shield-check" href="/corbado-observe/security/overview">
    Certifications, hosting, encryption and access control.
  </Card>

  <Card title="Privacy & data policies" icon="shield-halved" href="/corbado-observe/security/privacy">
    Built-in protections, retention per purpose and user requests.
  </Card>

  <Card title="Trust Center" icon="certificate" href="https://trust.corbado.com">
    ISO 27001 certificate, SOC 2 Type II report and subprocessors.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.