Service Level Agreement

Service: OpenObserve Cloud (Multi-Tenant SaaS), OpenObserve Enterprise (Single-Tenant Hosted), OpenObserve Enterprise (BYOC), and OpenObserve Enterprise (Self-Hosted)

Version: 1.0

Last Updated: June 30, 2026

1. Introduction

This Service Level Agreement ("SLA") is a policy governing the use of the OpenObserve services and is made part of the applicable OpenObserve Subscription or License Agreement (the "Agreement"). It applies to the following OpenObserve Deployment Models:

• OpenObserve Cloud — the fully managed, multi-tenant Software-as-a-Service platform hosted and operated entirely by OpenObserve.
• OpenObserve Enterprise (Single-Tenant Hosted) — a dedicated, single-tenant deployment hosted in an OpenObserve-operated cloud account and fully managed and operated by OpenObserve, including all underlying infrastructure.
• OpenObserve Enterprise (BYOC) — a dedicated, single-tenant deployment hosted within the Customer's own cloud account ("Bring Your Own Cloud") and managed and operated by OpenObserve on the Customer's behalf, under a shared-responsibility model in which the Customer maintains the underlying cloud account and infrastructure.
• OpenObserve Enterprise (Self-Hosted) — a paid Enterprise License under which the Customer deploys and operates the OpenObserve Software entirely within its own infrastructure. OpenObserve provides the licensed software, updates, and technical support, but does not host, operate, or manage the deployment.

Scope of commitments by Deployment Model:

• The Service Availability Commitment and Service Credits (Section 3) apply to OpenObserve Cloud, OpenObserve Enterprise (Single-Tenant Hosted), and OpenObserve Enterprise (BYOC). They do not apply to OpenObserve Enterprise (Self-Hosted), because OpenObserve does not operate or control the infrastructure on which a Self-Hosted Deployment runs.
• The Support Service Levels (Section 6) apply to all paid Deployment Models (Cloud, Single-Tenant Hosted, BYOC, and Self-Hosted) for Customers entitled to Enterprise support, as described in that section.
• This SLA does not apply to free, trial, community, or open-source deployments of OpenObserve, which are provided without any service-level or support commitment.

The following table summarizes which commitments apply to each Deployment Model. The full terms of each commitment, including conditions and exclusions, are set out in the sections referenced.

Commitment	OpenObserve Cloud	OpenObserve Single-Tenant Hosted	OpenObserve BYOC	OpenObserve Self-Hosted
Service Availability Commitment (99.8%) + Service Credits (§3)	✔	✔	✔	—
Support Service Levels / SLOs (§6)	✔	✔	✔	✔
Root Cause Analysis for P0 (§6)	✔	✔	✔	—

Sections 3, 6, 7, and 8 apply to the Deployment Models indicated in each section. Section 4 (Responsibilities) and Section 5 (Exclusions) contain provisions specific to each Deployment Model. In the event of a conflict between the terms of this SLA and the terms of the Agreement, the terms and conditions of this SLA apply, but only to the extent of such conflict.

2. Definitions

• "Deployment Model" refers to the manner in which the Customer consumes the Service — OpenObserve Cloud, OpenObserve Enterprise (Single-Tenant Hosted), OpenObserve Enterprise (BYOC), or OpenObserve Enterprise (Self-Hosted).
• "Service" refers to the OpenObserve software and platform made available to the Customer under the applicable Deployment Model, including the user interface, ingestion endpoints, query engine, alerting, metadata management, and authentication services.
• "OpenObserve Software" refers to the OpenObserve application software, binaries, and container images licensed or otherwise made available to the Customer, exclusive of any underlying infrastructure on which it runs.
• "Cloud Provider" (BYOC only) refers to the third-party infrastructure provider (Amazon Web Services, Google Cloud Platform, or Microsoft Azure) in whose account the OpenObserve Enterprise (BYOC) deployment is hosted.
• "Self-Hosted Deployment" (Self-Hosted only) refers to the Customer-operated installation of the licensed OpenObserve Software running entirely within infrastructure owned or controlled by the Customer.
• "Ingestion" refers to the Service's ability to accept and durably store observability data (logs, metrics, and traces) submitted by the Customer through supported endpoints.
• "Query" refers to the Service's ability to search, aggregate, and return previously ingested observability data to the Customer.
• "Downtime" means a period of time during which the Service is unable to perform Ingestion or Query for the Customer, solely due to a defect in, or failure of, the OpenObserve Software or the infrastructure managed by OpenObserve. For OpenObserve Cloud and OpenObserve Enterprise (Single-Tenant Hosted), this means the OpenObserve-managed platform or dedicated deployment as a whole. For OpenObserve Enterprise (BYOC), this means the OpenObserve-managed deployment running in the Customer's cloud account is unable to perform Ingestion or Query, solely due to a defect in, or failure of, the OpenObserve Software or OpenObserve's operation of the deployment, and not due to the Customer's cloud account or infrastructure. Downtime is not measured for Self-Hosted Deployments.
• "Monthly Uptime Percentage" is calculated, for each calendar month, by subtracting the number of minutes of Downtime during that calendar month from the total number of minutes in that calendar month, then dividing by the total number of minutes in that calendar month.
• "Monthly Fee" means the total charges paid by the Customer for the Service for the applicable calendar month (or the monthly pro-rated equivalent of an annual fee).

3. Service Availability Commitment

This Section 3 applies to OpenObserve Cloud, OpenObserve Enterprise (Single-Tenant Hosted), and OpenObserve Enterprise (BYOC). It does not apply to OpenObserve Enterprise (Self-Hosted).

OpenObserve commits to use commercially reasonable efforts to make the Service available with a Monthly Uptime Percentage of at least 99.8% during any calendar month (the "Service Commitment").

3.1 Service Credits

In the event OpenObserve does not meet the Service Commitment, the Customer will be eligible to receive a Service Credit as described below:

Monthly Uptime Percentage	Service Credit Percentage
< 99.8% but ≥ 99.0%	10% of Monthly Fee
< 99.0% but ≥ 95.0%	20% of Monthly Fee
< 95.0%	30% of Monthly Fee

Service Credits are calculated as a percentage of the total charges paid by Customer for the applicable Service for the calendar month in which the Downtime occurred. If the Customer is on an annual subscription plan, the Service Credit will be calculated based on the monthly pro-rated equivalent of the annual fee (i.e., the annual fee divided by 12). The maximum total Service Credit for any single calendar month shall not exceed 100% of the Monthly Fee (or pro-rated monthly equivalent) for that calendar month. Service Credits shall be applied to future payments only and no cash refunds will be provided. Service Credits are the Customer's sole and exclusive remedy for any failure by OpenObserve to meet the Service Commitment.

4. Responsibilities

The allocation of responsibility depends on the Customer's Deployment Model. Where applicable, the Service Commitment in Section 3 is contingent upon the Customer meeting the responsibilities applicable to their Deployment Model.

4.1 OpenObserve Cloud

OpenObserve Cloud is a fully managed service. OpenObserve operates and is responsible for the entire service stack — including infrastructure, software, and data durability. The Customer remains responsible for the security of their account and for using the Service in accordance with the Agreement and applicable plan limits.

OpenObserve Responsibilities:

• Infrastructure Management: Provisioning, operating, scaling, and maintaining all compute, object storage, networking, and load-balancing resources required to deliver the Service.
• Software Availability: Ensuring the OpenObserve Software, ingestion endpoints, and query engine are functioning correctly.
• Operations & Patching: Managing deployment, upgrades, patching, capacity planning, and backups of the Service.
• Data Durability: Maintaining the durability of ingested data within the Service in accordance with the Customer's subscribed data retention plan.
• Security: Maintaining the security of the platform and applying critical patches to protect the integrity of the Service.
• Support: Providing technical support for software defects and Service issues in accordance with Section 6.

Customer Responsibilities:

• Account Security: Safeguarding user credentials, API keys, and access tokens, and managing user access within the Customer's organization.
• Plan Limits: Operating within the subscribed plan limits, including ingestion volume, query concurrency, retention period, and applicable rate limits.
• Client Configuration: Correctly configuring data collectors, agents, and integrations (e.g., OpenTelemetry, Fluent Bit, Vector) that submit data to or query the Service.
• Network Connectivity: Maintaining the Customer's own internet connectivity and egress required to reach the Service endpoints.
• Acceptable Use: Using the Service in compliance with the Agreement and the OpenObserve Acceptable Use Policy.

4.2 OpenObserve Enterprise (Single-Tenant Hosted)

OpenObserve Enterprise (Single-Tenant Hosted) is a dedicated, single-tenant deployment that OpenObserve hosts and fully manages within an OpenObserve-operated cloud account. As with OpenObserve Cloud, OpenObserve operates and is responsible for the entire service stack — including infrastructure, software, and data durability. The Customer remains responsible for the security of their account and for using the Service in accordance with the Agreement and applicable plan limits.

OpenObserve Responsibilities:

• Infrastructure Management: Provisioning, operating, scaling, and maintaining all compute, object storage, networking, and load-balancing resources required to deliver the dedicated deployment.
• Software Availability: Ensuring the OpenObserve Software, ingestion endpoints, and query engine are functioning correctly.
• Operations & Patching: Managing deployment, upgrades, patching, capacity planning, and backups of the deployment.
• Data Durability: Maintaining the durability of ingested data within the deployment in accordance with the Customer's subscribed data retention plan.
• Security: Maintaining the security of the deployment and applying critical patches to protect the integrity of the Service.
• Support: Providing technical support for software defects and Service issues in accordance with Section 6.

Customer Responsibilities:

• Account Security: Safeguarding user credentials, API keys, and access tokens, and managing user access within the Customer's organization.
• Plan Limits: Operating within the subscribed plan limits, including ingestion volume, query concurrency, retention period, and applicable rate limits.
• Client Configuration: Correctly configuring data collectors, agents, and integrations (e.g., OpenTelemetry, Fluent Bit, Vector) that submit data to or query the deployment.
• Network Connectivity: Maintaining the Customer's own internet connectivity and egress required to reach the Service endpoints.
• Acceptable Use: Using the Service in compliance with the Agreement and the OpenObserve Acceptable Use Policy.

4.3 OpenObserve Enterprise (BYOC)

The "Bring Your Own Cloud" (BYOC) model relies on a shared responsibility between OpenObserve and the Customer. While OpenObserve manages and operates the deployment, the SLA is contingent upon the Customer maintaining the health of their own cloud account and infrastructure.

OpenObserve Responsibilities:

• Software Availability: Ensuring the OpenObserve Software deployed in the Customer's cloud account is functioning correctly.
• Operations & Patching: Managing the deployment, upgrades, and patching of the OpenObserve Software within the Customer's cloud account.
• Data Durability: Operating the deployment to durably store ingested data in accordance with the Customer's subscribed data retention plan, within the storage maintained by the Customer in its cloud account.
• Security: Maintaining the security of the OpenObserve Software and applying critical patches to protect the integrity of the deployment.
• Support: Providing technical support for software defects and configuration issues in accordance with Section 6.

Customer Responsibilities:

• Infrastructure Quotas: Ensuring the Cloud Provider account has sufficient quotas (vCPU, IP addresses, IOPS) to support the deployed cluster.
• Network Connectivity: Managing VPC peering, Transit Gateways, or PrivateLink connections required for OpenObserve to access and manage the deployment in the Customer's cloud account.
• IAM & Permissions: Maintaining valid IAM roles/service accounts that grant OpenObserve the necessary permissions to deploy and manage the OpenObserve resources in the Customer's cloud account.
• Storage Availability: Ensuring the S3/GCS/Azure Blob storage buckets exist, are not deleted, and have correct lifecycle policies preventing premature data deletion.
• Account Security & Acceptable Use: Safeguarding credentials and using the Service in compliance with the Agreement and the OpenObserve Acceptable Use Policy.

4.4 OpenObserve Enterprise (Self-Hosted)

Under the Self-Hosted Enterprise License, the Customer operates the OpenObserve Software entirely within its own infrastructure. OpenObserve provides the licensed software and support but does not operate the deployment; accordingly, no Service Availability Commitment or Service Credits apply to Self-Hosted Deployments (see Section 3). The Customer is solely responsible for the availability, performance, and operation of its Self-Hosted Deployment.

OpenObserve Responsibilities:

• Licensed Software: Providing the licensed OpenObserve Enterprise software and entitlement keys.
• Updates & Patches: Making available version updates, bug fixes, and security patches for supported releases.
• Security Advisories: Issuing security advisories for identified vulnerabilities in the OpenObserve Software.
• Support: Providing technical support for software defects and configuration questions in accordance with Section 6.

Customer Responsibilities:

• Infrastructure & Operation: Provisioning, operating, scaling, and maintaining all infrastructure (compute, storage, networking) on which the software runs.
• Availability & Resilience: Designing, deploying, and operating the deployment for the Customer's own required availability, including high availability, backups, and disaster recovery.
• Deployment & Upgrades: Installing, configuring, upgrading, and patching the OpenObserve Software in a timely manner, including applying security patches.
• Monitoring & Capacity: Monitoring the health and capacity of the deployment and provisioning sufficient resources.
• Security & Acceptable Use: Securing the deployment and its data, and using the software in compliance with the Agreement and the OpenObserve Acceptable Use Policy.

5. SLA Exclusions

The Service Commitment in Section 3 does not apply to any unavailability, suspension, or termination of the Service, or any other OpenObserve performance issues arising from the circumstances described below. (This Section is relevant to the Deployment Models covered by Section 3 — Cloud, Single-Tenant Hosted, and BYOC.)

5.1 General Exclusions (Cloud, Single-Tenant Hosted, and BYOC)

1. Factors Beyond Reasonable Control: Caused by factors outside of OpenObserve's reasonable control, including any force majeure event, or internet access, ISP, or related connectivity problems beyond the demarcation point of OpenObserve's Service endpoints.
2. Customer Misconfiguration or Misuse: Resulting from any actions or inactions of the Customer or any third party, including misconfigured collectors, agents, or integrations, invalid credentials, or use of the Service in a manner inconsistent with the documentation.
3. Plan Limits & Rate Limiting: Resulting from the Customer exceeding subscribed plan limits or applicable rate limits (e.g., ingestion volume, query concurrency, or API request rate limits).
4. Suspension: Resulting from suspension or termination of the Customer's right to use the Service in accordance with the Agreement, including for non-payment or violation of the Acceptable Use Policy.
5. Maintenance:
   • Scheduled Maintenance: Maintenance carried out during a pre-announced window (usually communicated at least 48 hours in advance).
   • Emergency Maintenance: Critical security patching required to protect the integrity of the Service.
6. Beta Features: Resulting from the use of services, hardware, or software designated as "Alpha," "Beta," or "Preview."

5.2 Additional Exclusions (BYOC Only)

For the BYOC Deployment Model, the Service Commitment additionally does not apply to issues arising from:

1. Cloud Provider Outages: Outages or capacity issues in the Customer's chosen Cloud Provider region (e.g., an AWS us-east-1 outage), or other failures of infrastructure within the Customer's cloud account.
2. Customer Infrastructure Configuration: Failure to configure VPC security groups, firewalls, or IAM permissions as prescribed in the documentation.
3. Resource Exhaustion: The Customer's underlying infrastructure reaching physical or logical limits (e.g., full disk on nodes not managed by auto-scaling, hitting Cloud Provider API rate limits).

6. Support Service Levels (SLOs)

The Support Service Levels (SLOs) set out in this Section 6 apply to Customers entitled to Enterprise support — that is, Customers on a paid Enterprise plan (Cloud, Single-Tenant Hosted, or BYOC) or holding a paid Enterprise License (Self-Hosted) — in each case with the applicable plan, subscription, or license active and the account in good standing. "Enterprise support" is a support entitlement and is distinct from the OpenObserve Deployment-Model names; for the Cloud Deployment Model it is included with the paid Enterprise plan. Customers without an active Enterprise support entitlement receive support on a commercially reasonable, best-effort basis by emailing support@openobserve.ai and through community channels, without the guaranteed initial response times below.

OpenObserve provides support based on the severity of the incident. The Customer must designate a primary technical contact for P0 and P1 issues.

Business Hours: "Business Day" or "Business Hours" refers to Monday through Friday, 9:00 AM to 5:00 PM Pacific Time (US), excluding US public holidays.

Severity Level	Definition	Initial Response Time (Enterprise)
P0 (Critical)	Service Down. The Service is completely inaccessible or a critical function (Ingestion/Query) is completely broken for all of the Customer's users. No workaround available.	< 1 Hour (24/7)
P1 (High)	Service Degraded. Significant feature unavailability (e.g., Alerts not firing, heavy query latency). Operations are severely hampered.	< 8 Hours (24/7)
P2 (Normal)	General Issue. Non-critical errors, questions about configuration, or minor bugs that do not halt business operations.	< 2 Business Days
P3 (Low)	Minor. Feature requests, cosmetic issues, or documentation clarifications.	< 4 Business Days

For Self-Hosted Deployments, support response times relate to OpenObserve's initial response to a support request; resolution may require the Customer to apply updates, configuration changes, or patches within its own environment.

Root Cause Analysis (RCA): For P0 (Critical) incidents affecting OpenObserve Cloud, Single-Tenant Hosted, or BYOC, OpenObserve will provide a formal Root Cause Analysis (RCA) document within a reasonable time not exceeding 21 days following the full resolution of the incident.

7. Claims Process

This Section 7 applies to Service Credit claims under Section 3 (OpenObserve Cloud, Single-Tenant Hosted, and BYOC).

To receive a Service Credit, the Customer must submit a claim by emailing support@openobserve.ai. The Customer's account must be current (not past due) and in compliance with the Agreement at the time the claim is submitted; no Service Credit will be issued for any period during which the account is past due or otherwise in breach of the Agreement. To be eligible, the credit request must be received by OpenObserve by the end of the second calendar month following the calendar month in which the Downtime occurred and must include:

1. The words "SLA Credit Request" in the subject line.
2. The dates and times of each Downtime incident that you are claiming.
3. Logs or screenshots documenting and corroborating the claimed Downtime (subject to the exclusions in Section 5).

If the Monthly Uptime Percentage of such request is confirmed by OpenObserve and is less than the Service Commitment, then OpenObserve will issue the Service Credit to the Customer within one calendar month following the calendar month in which the request was confirmed.

8. Changes to this SLA

OpenObserve may update or modify this SLA from time to time by publishing a revised version at the same location. Material changes will be reflected by an updated "Version" and "Last Updated" date above, and OpenObserve will use commercially reasonable efforts to notify Customers of material changes. The version of this SLA in effect at the start of a given calendar month governs the Service Commitment for that calendar month. Continued use of the Service after a revision takes effect constitutes acceptance of the revised SLA.