Service level agreement

The Quake AI Service Level Agreement (SLA) is the contractual document that defines the availability target for each service and the credits available when a target is missed. The SLA is published as part of Quake AI's commercial terms; this page links you to the canonical document and explains how to read it.

Where the SLA lives#

The current SLA terms are published at rumble.cloud/legal. The terms include the per-service availability targets, the measurement window, exclusions (scheduled maintenance, customer error, force majeure), and the credit schedule.

What the SLA does and does not promise#

The SLA defines what gets credited if a service falls below its target. It does not define your application's availability. Your application availability is a function of how you architect across instances, zones, and regions.

To make the SLA meaningful for your application:

• Run replicas across at least two instances in different server groups so a single host failure does not take you offline.
• For state, use replicated object storage (or your own database replication), block volumes are zonal.
• For geographic redundancy, design across regions: Quake AI does not currently offer managed multi-region failover.

How credit claims work#

Service credit eligibility is determined by the published SLA. Credits are not automatic; they require a claim filed within the window the SLA specifies. To file a claim, open a support ticket with:

• The service and region affected.
• The time window of the incident (UTC).
• The resource identifiers (project ID, instance/volume/bucket IDs).
• Any error messages or evidence collected, see support ticket evidence collection for the standard checklist.

Related references#

• Platform overview: Operational expectations: what the SLA covers and how it relates to your design.
• Regions and availability: the regions covered by the SLA.
• How billing works: how SLA credits appear on invoices.
• Get help: support paths and what to expect.