OCI SLA and Service-Credit Language

The OCI SLA and service-credit language in an Oracle Cloud Infrastructure contract is the financial backstop for cloud availability — the contractual mechanism by which Oracle pays the customer for OCI outages, performance failures, and service degradations. The default OCI Service Level Agreement is published at oracle.com/cloud/sla and incorporated by reference into the OCI Cloud Services Agreement. Default service-credit cap: 25 percent of monthly fees for the affected service. Default exclusions: "scheduled maintenance," "force majeure," "customer-caused" outages — categories Oracle interprets broadly. Default credit claim process: customer must request in writing within 30 days, with detailed evidence. Default automatic credits: none.

For a customer running mission-critical workloads on OCI, the default SLA is a financial-and-operational fiction. A real outage causes real business loss; the 25 percent credit cap rarely compensates and the claim process favours Oracle. This article documents what Oracle's default OCI SLA actually delivers, the four SLA structures buyers should negotiate, the eight categories of credit-claim exclusion to challenge, and the financial worked example for a workload that loses 8 hours of OCI Database access.

What Oracle's default OCI SLA actually delivers

Oracle publishes per-service availability targets at oracle.com/cloud/sla. Compute (bare metal and VM): 99.95 percent monthly uptime target. Block Volume: 99.95 percent. Object Storage: 99.9 percent. Autonomous Database: 99.95 percent. OCI Database Cloud Service: 99.95 percent. OKE (Kubernetes): 99.95 percent. Fast Connect: 99.95 percent.

Translated into outage minutes per month: 99.95 percent = 21.9 minutes of permissible downtime; 99.9 percent = 43.8 minutes. Service-credit schedule: 99.0–99.95 percent monthly uptime triggers 10 percent credit on monthly fees for that service; below 99.0 percent triggers 25 percent credit; that is the cap. There is no contractual right to terminate the service for repeated SLA breach, no automatic credit issuance, and no commitment to root-cause analysis disclosure.

The four OCI SLA clause structures buyers should negotiate

1. Enhanced service-credit cap

Negotiate the credit cap from 25 percent to 100 percent of monthly fees for the affected service, with a stepped schedule. Example structure: 99.5–99.95 percent monthly = 15 percent credit; 99.0–99.5 percent = 30 percent credit; 95.0–99.0 percent = 50 percent credit; below 95.0 percent = 100 percent credit plus right to terminate the affected service without penalty. Achievable on Tier 1 OCI commits ($1M+ annual); Tier 2 typically negotiates 50 percent cap.

2. Automatic credit issuance

Default OCI requires the customer to claim credits within 30 days, with evidence. Negotiate automatic credit issuance: Oracle proactively credits the customer's next invoice for any month in which the SLA target is missed, without customer claim. The credit basis is Oracle's own monitoring data (which Oracle has anyway). Removes the administrative-friction asymmetry where credits the customer is entitled to never get claimed.

3. Enhanced uptime targets for mission-critical workloads

Default 99.95 percent translates to 21.9 minutes / month permissible downtime. For mission-critical workloads, negotiate 99.99 percent (4.4 minutes / month) for the affected services, with multi-AD deployment as the engineering basis. Oracle's standard counter is that 99.99 percent requires multi-region deployment at additional cost; negotiate the multi-region commit as part of the SLA package rather than separate billing.

4. SLA-breach termination right

Add a contractual right to terminate the affected OCI service without penalty if the SLA is missed in any 3 of any 12 consecutive months. Example: "In the event Oracle fails to meet the applicable monthly uptime SLA in any three (3) months during any rolling twelve (12) month period, Customer may terminate the affected OCI service on 30 days notice without penalty and Oracle shall refund any pre-paid fees for the unused portion of the term." Creates the credible exit threat that converts SLA performance from soft promise to hard contractual obligation.

The eight credit-claim exclusion categories to challenge

Exclusion 1 — Scheduled maintenance

Default OCI SLA excludes all scheduled maintenance from uptime calculations. Oracle defines scheduled maintenance broadly. Counter: scheduled maintenance must be (a) notified 14 days in advance, (b) capped at 4 hours per month, (c) executed during a customer-selected maintenance window. Maintenance outside these parameters counts as unscheduled downtime.

Exclusion 2 — Force majeure

Default OCI SLA excludes force majeure events with no definition. Counter: force majeure events are limited to natural disasters, governmental action, and infrastructure failure outside Oracle's reasonable control; events caused by Oracle's failure to maintain redundancy, by Oracle's software defects, or by Oracle subprocessor failures do not qualify.

Exclusion 3 — Customer-caused outages

Oracle's default position: any outage Oracle attributes to customer configuration, customer code, or customer-issued commands is excluded. Counter: customer-caused exclusions require documented Oracle root-cause analysis identifying the specific customer action and showing why the outage would not have occurred with Oracle's recommended configuration.

Exclusion 4 — Beta and preview services

OCI services in beta or preview have no SLA. Counter: customer is not required to use beta or preview services; if Oracle deprecates a GA service into beta, the prior SLA continues.

Exclusion 5 — Subprocessor failures

Oracle subprocessors (third-party CDN, third-party DNS, third-party security partners) failures are excluded by default. Counter: Oracle subprocessor failures are Oracle's responsibility for SLA purposes.

Exclusion 6 — Single-AD deployments

Default SLA applies only to multi-AD deployments. Single-AD workloads have effectively no SLA. Counter: if Oracle has only single-AD coverage in a region the customer requires, single-AD SLA must apply at the same uptime target.

Exclusion 7 — Network failures upstream of OCI

Internet routing failures, ISP failures, customer-side network failures are excluded. Counter: only customer-side network failures should be excluded; Oracle's connectivity-to-internet and Fast Connect failures remain Oracle's responsibility.

Exclusion 8 — Performance degradations short of total outage

Default OCI SLA addresses availability (up vs down), not performance (slow). A workload running at 10 percent of normal throughput is technically available — no credit. Counter: add performance SLAs for latency-sensitive services (Block Volume IOPS, Autonomous Database query response time, Fast Connect latency).

OCI SLA negotiation by workload class

Mission-critical production database (OLTP, ERP backend)

Target: 99.99 percent uptime, 100 percent credit cap, automatic issuance, termination right after 3-of-12 breach, performance SLAs on IOPS and latency. Justified by the business cost of database unavailability ($X per minute documented to Oracle as the leverage anchor).

Analytics and reporting workloads

Target: standard 99.95 percent uptime, 50 percent credit cap, automatic issuance. Analytics workloads typically tolerate longer recovery windows but the credit-claim friction is the same — the automatic-issuance language is the high-value clause.

Development, test, and non-production environments

Target: standard 99.9 percent uptime, default 25 percent credit. Concession to Oracle in exchange for stronger SLA on production. Use as the trade-off variable.

Fast Connect / DR replication

Target: 99.99 percent on Fast Connect, with explicit credit if the secondary site is unavailable for DR. Critical for any regulated workload where DR availability is the regulatory bar (e.g., financial services operational-resilience requirements).

Three buyer-side moves for OCI SLAs

1. Document business loss per minute of OCI outage

For each mission-critical OCI workload, document the business loss per minute of unavailability — direct revenue loss, recovery cost, regulatory penalty. The quantification is the leverage anchor for SLA negotiation: it converts an abstract SLA discussion into a concrete commercial conversation about Oracle's contribution to that business loss.

2. Build the OCI SLA redline library

Adopt the four SLA clause structures plus the eight exclusion-narrowing clauses as procurement standard redlines on every new OCI Ordering Document. Couple with data-residency clauses from the OCI data residency clauses article.

3. Audit OCI SLA performance quarterly

Pull Oracle's uptime reports for each OCI service quarterly. Compare actual uptime against contracted SLA. Any month with SLA miss is a credit-claim opportunity (or, with automatic-issuance language, a verification opportunity). Cumulative SLA misses become renewal-leverage anchors. See the Oracle negotiation master guide for the broader leverage framework.

Frequently asked questions

What is the default OCI SLA uptime target?

99.95 percent monthly uptime for most OCI services (Compute, Block Volume, Autonomous Database, Database Cloud Service, OKE, Fast Connect). 99.9 percent for Object Storage. Translated: 21.9 minutes of permissible downtime per month at 99.95 percent, 43.8 minutes at 99.9 percent. Default service credit caps at 25 percent of monthly fees for the affected service.

Are OCI SLA credits issued automatically?

No. Default OCI SLA requires the customer to submit a written claim within 30 days of the outage, with detailed evidence. Most customers never file. The negotiated structure is automatic credit issuance based on Oracle's own monitoring data, with the customer's next invoice credited automatically for any month in which the SLA is missed.

Can I negotiate a higher OCI SLA than 99.95 percent?

Yes, on Tier 1 commits ($1M+ annual). Oracle's Deal Desk has signed 99.99 percent uptime targets on mission-critical workloads, typically conditional on multi-AD deployment (which Oracle bills separately) or, for the strictest cases, multi-region deployment. Negotiate the multi-AD or multi-region commit as part of the SLA package rather than separately billed.

Does the OCI SLA cover performance degradation?

No, only total availability. A service running at 10 percent of normal throughput is technically available and triggers no credit. Performance SLAs must be negotiated separately for each latency-sensitive service — IOPS targets for Block Volume, query response targets for Autonomous Database, latency targets for Fast Connect. These performance SLAs are achievable but require separate negotiation and quantified business-loss justification.

Related reading