Availability SLA

Oodle commits to 99.9% availability per calendar month for production services, including:

• telemetry ingestion endpoints
• query APIs
• core platform APIs and Oodle UI

Availability is calculated as: Availability % = ((Total minutes in month - Downtime minutes) / Total minutes in month) × 100

Downtime excludes:

• scheduled maintenance announced at least 24 hours in advance
• third-party outages outside Oodle's reasonable control
• force majeure events and other events outside Oodle's reasonable control
• customer-side agent, collector, or network failures outside Oodle's service boundary

Service credits

Security and Compliance

Oodle is SOC 2, ISO 27001, and GDPR compliant. Security and compliance documentation is available on request. Contact your account team or visit our trust center.

Oodle provides operational support for production incidents and service degradation.

Support SLA

Incident handling approach

For critical production incidents, Oodle prioritizes restoring telemetry availability or query access before root-cause analysis is complete. The immediate goal during an incident is to reduce customer impact quickly; deeper root-cause analysis and follow-up actions happen after service has been stabilized.

Contact methods

• in-app urgent support ticket
• email: oncall-<enterprise-customer>@oodle.ai
• phone escalation for enterprise customers

For real-time platform status and incident updates, visit status.oodle.ai

Oodle's architecture separates durable storage from stateless compute, so the platform can recover from failures without risking customer data or requiring expensive rebuilds.

Key design properties

• Durable storage, independent compute — Telemetry is stored in object storage; ingestion and query compute are stateless and horizontally scalable. A compute failure does not cause telemetry loss.
• Immutable, append-only write path — Telemetry is written as immutable, append-only data. This reduces corruption risk during failures and simplifies recovery.
• Multi-AZ by default — Production services run across multiple AWS Availability Zones. Oodle is designed to continue operating through node, host, and single-AZ failures without manual intervention.
• Independent write and read paths — Ingestion, query execution, and platform services are isolated so failures in one area do not cascade across the entire service.

Oodle separates the platform into data plane and control plane services so that failures in management or configuration services do not automatically imply telemetry loss or full platform unavailability.

Data plane

The data plane includes:

• telemetry ingestion endpoints
• durable telemetry storage
• query execution services

The data plane is responsible for receiving, storing, and serving customer telemetry.

Control plane

The control plane includes:

• authentication and user/session management
• configuration and management APIs
• dashboards, alerts, saved views, and other platform metadata
• administrative platform services

Practical effect of this separation

This separation is designed to limit blast radius during failures:

• control plane degradation does not imply telemetry loss
• ingestion and durable telemetry storage remain isolated from control plane failures
• query execution is designed to remain isolated from control plane failures where possible
• some management functions, configuration changes, or UI features may be impaired even if telemetry ingestion and storage remain healthy

This separation helps Oodle preserve the most important customer outcomes during incidents: continued telemetry durability, continued ingestion, and the ability to restore query access quickly.

Oodle's default production deployment is designed for high availability within a single AWS region. This protects against common failures such as:

• node or host failures
• Availability Zone failures
• transient network partitions
• query worker or cache failures

Ingestion

Ingestion endpoints run across multiple Availability Zones behind redundant service infrastructure. Telemetry is acknowledged only after it has been durably persisted.

Query path

Query services and serverless query execution run across multiple Availability Zones. Query execution is independent of the write path, so query-side failures do not interrupt telemetry ingestion.

Platform services

Core platform services such as API, authentication, and configuration are deployed redundantly across multiple Availability Zones. Platform metadata is stored in managed services with backup and recovery controls.

High availability summary

Oodle defines recovery targets for failures larger than a single node or process.

Availability Zone failure

All Oodle production services are deployed across multiple Availability Zones within a region. Single-AZ failures are handled automatically.

Oodle protects different parts of the platform differently depending on whether they belong to the telemetry data plane or the control plane.

Telemetry data

Customer telemetry is durably stored in object storage using Oodle's append-only storage model. Because telemetry is persisted to durable object storage rather than stored primarily in mutable database state, it is not backed up through a separate database-style backup workflow. Instead, durability is provided by the underlying storage system and Oodle's write path, which persists data before acknowledgment. In practice, this means that for any telemetry Oodle has acknowledged as received, the data is durable. The relevant recovery scenario is a control-plane or metadata failure, not telemetry loss and that is addressed by the platform metadata backup process described below.

Platform metadata and control plane state

Platform metadata, including configuration and other control-plane state, is stored in managed services with backup and recovery controls, including automated backups and point-in-time recovery where supported.

Dashboards, alerts, and saved configuration

Dashboards, alerts, and other saved platform objects are stored as platform metadata and are therefore covered by control-plane backup and recovery mechanisms. For customers who want additional reproducibility or easier disaster recovery workflows, Oodle recommends managing alerts and dashboards as code using Terraform.

Restore posture

In the event of a metadata-store failure or control-plane recovery event, Oodle's restore process is focused on restoring platform metadata and management state while leaving customer telemetry in durable storage. This allows Oodle to recover management functions without requiring bulk telemetry restoration from backup.

For customers that require protection against a full regional outage, Oodle supports regional disaster recovery across two regions.

Oodle does not currently provide platform-managed cross-region replication as part of the standard service. To achieve 0 RPO during a regional outage, customer agents or collectors must be configured to dual-write telemetry to two Oodle deployments in different regions.

Oodle supports two regional DR models:

Active / active

Both regions run at full capacity, continuously receive telemetry, and serve queries.

• Highest resilience and fastest recovery
• Requires two full Oodle regional deployments
• Additional charges apply

Active / standby

The standby region continuously receives telemetry via dual-write, but runs at reduced serving capacity until failover.

• Lower cost than active / active
• Standby capacity is reduced until promotion
• Real-time queries and some features may be unavailable in standby until failover
• Requires a second Oodle regional deployment
• Additional charges apply

In addition to the underlying architecture, Oodle's production reliability depends on operational discipline:

• 24×7 monitoring and alerting for production infrastructure and core service health
• on-call engineering escalation for critical incidents
• automated backups and point-in-time recovery for platform metadata stores
• controlled production rollouts to reduce deployment risk
• documented failover procedures for platform recovery and regional DR scenarios

To maximize resilience, Oodle recommends the following:

Enable retry and local buffering

Configure OpenTelemetry Collectors, Prometheus agents, or other telemetry agents to buffer locally and retry on failures. This protects against transient interruptions and brief service disruptions.

Use dual-write for regional DR

If resilience to a full regional outage is required, configure collectors to send telemetry to both a primary and secondary Oodle region.

Manage dashboards and alerts as code

Use Oodle's Terraform provider to manage alerts, dashboards, and platform configuration as version-controlled infrastructure so configuration can be reproduced in a secondary region if needed.

Oodle currently supports deployments in:

• US West
• Asia Pacific
• Europe — coming soon

Customer data remains within the selected deployment region.

Oodle relies on a small set of third-party infrastructure services and subprocessors to deliver the platform. These services are used for areas such as:

• authentication and identity management
• durable telemetry storage
• platform metadata and control-plane state
• cloud infrastructure, networking, and operational service delivery

Examples of categories of third-party services used by Oodle include identity providers such as Auth0/Okta, cloud storage services such as Amazon S3, and managed metadata stores such as Amazon DynamoDB.

These dependencies are incorporated into Oodle's reliability, backup, and disaster recovery design. Oodle's architecture is designed so that failures in individual compute components do not automatically imply telemetry loss, but customers should understand that parts of the platform depend on underlying third-party cloud and identity services.

Oodle maintains a current list of subprocessors and can provide additional subprocessor and security documentation as part of customer security, legal, or vendor review.

To discuss enterprise DR configurations, review subprocessor or security documentation, or ask questions about this document, contact your Oodle account team or reach us at:

• Urgent / production incidents: oncall-<enterprise-customer>@oodle.ai
• High priority production incidents: support@oodle.ai or via in-app support ticket
• Platform status: status.oodle.ai