OCI Managed Services SLAs Explained

A service level agreement is where a managed service stops being a brochure and becomes a contract. It is the set of measurable commitments the provider makes, and the consequences if they miss them. Yet SLAs are also where providers hide, because an impressive headline number can be hollowed out by exclusions and definitions buried in the fine print. Reading an SLA properly is one of the most valuable things a buyer can do, because the wording decides whether the commitment actually protects you or simply looks reassuring on a slide.

The three numbers that matter

Most of an SLA comes down to three commitments, and it is worth being precise about what each one means.

The most common confusion is between response and resolution. A provider can meet an aggressive response target by acknowledging your ticket within minutes while taking days to actually fix the problem. Response time tells you how quickly someone picks up the phone. Resolution time, or a restoration target, is what tells you how quickly the problem goes away, and it is the number that matters more to the business.

Availability and the exclusions trap

Availability is usually quoted as a percentage, and small differences in the percentage mean large differences in allowed downtime. The table shows what each level permits over a year.

But the percentage is only meaningful once you know what counts against it. The critical question is what the measurement excludes. Planned maintenance is almost always excluded, which is reasonable, but the definition of planned maintenance can be stretched. Changes you requested are often excluded. Problems traced to your own application rather than the infrastructure are excluded. Force majeure is excluded. By the time the exclusions are accounted for, a 99.99 percent commitment can permit far more real downtime than the number suggests. Read the exclusions before you read the percentage, because that is where the truth lives.

What credits really mean

When a provider misses an availability commitment, the SLA usually owes you a service credit, typically a percentage of the monthly fee. It is important to be realistic about what this is. A credit is a small refund, not compensation for the business impact of the outage. If an hour of downtime costs you far more than a fraction of a monthly fee, and for a critical estate it usually does, then the credit is symbolic rather than restorative. The credit's real value is as a signal of how seriously the provider takes its own commitment and as a mechanism that gives them a financial reason to avoid misses. Choose a provider because you believe they will keep the estate up, not because the credit will make you whole if they do not.

How to read an SLA properly

Severity levels and why they matter

A single response or resolution target applied to every issue is a blunt instrument, because not all problems are equal. A serious SLA defines severity levels, so that a critical outage taking down a revenue service carries a tight response and restoration target, while a minor cosmetic issue carries a relaxed one. This matters in both directions. It protects you, by guaranteeing that genuine emergencies get immediate attention rather than sitting in a queue behind trivial requests. And it protects the provider from being held to an emergency target for a problem that is not one, which keeps the commitment realistic and therefore credible. When you read an SLA, check that severity is defined clearly, that you and the provider would agree on how a given incident is classified, and that you, not only the provider, have a say in the severity of an issue affecting your business. A provider who alone decides severity can quietly downgrade problems to make its targets easier to meet, which is a subtle way of weakening a commitment that looks strong on paper.

Service levels you set versus those the platform sets

It is worth distinguishing the service levels a managed provider commits to from those the underlying cloud platform offers, because they are different things and conflating them causes confusion. The platform makes its own availability commitments for its services, which are a floor the provider builds on but does not control. The provider's SLA is about how it operates your estate on top of that platform: how fast it responds, how quickly it restores, how it keeps the estate healthy. A provider cannot credibly promise more availability than the platform underneath supports, so a commitment that exceeds what the architecture can deliver is a warning sign. The honest framing is that the provider commits to operating the estate well within the bounds the platform sets, and to designing the architecture so that the platform's own resilience features are used to reach the availability you need. An SLA that ignores this distinction, or promises numbers the architecture cannot support, is selling comfort rather than a commitment.

The honest SLA test

A good way to test an SLA is to ask the provider to walk you through exactly what happens, and what they owe, in a specific scenario: a critical service goes down at two in the morning. A confident provider will describe the detection, the response, the escalation and the restoration target clearly, and will be straightforward about the exclusions and the credit. A provider who becomes vague, or who points to a percentage without explaining how it is measured, is telling you something useful. The SLA is only as good as the provider's willingness to explain it plainly, and that willingness is itself a strong signal of how the relationship will run.

Service levels work hand in hand with coverage hours, which are covered in 24/7 OCI support models. For the wider context see the complete guide to OCI managed services and what managed services include. When you want a managed service with service levels written to protect rather than flatter, our OCI managed services practice commits to terms in the plain language described here.