Every OCI estate sits on top of three support layers, whether anyone designed it that way or not. At the bottom is Oracle's own support organisation, reached through the service request process and bound to the platform itself. Above it sits partner or specialist support, the layer that understands your architecture, your workloads, and your cost profile rather than just the cloud they run on. And wrapped around both is the run team, internal or outsourced, that watches the estate, applies the patches, and answers the pager. Buyers routinely assume the first layer covers everything, discover during their first serious incident that it does not, and then scramble to bolt the other two layers on mid crisis. This piece is part of our complete guide to hiring an OCI partner, and its job is to help you build the full stack deliberately, before the outage rather than during it.
The core misunderstanding is simple. Oracle support exists to keep the OCI platform working as documented. It does not exist to keep your business working. The gap between those two sentences is where partner support and run teams live, and it is far wider than most teams expect on the day they sign their cloud agreement.
Layer one: Oracle support and the SR process
Every OCI subscription includes Oracle support for the platform. You raise a service request, an SR, through the console or My Oracle Support, assign it a severity, and Oracle works it according to that severity. The model is mature and the engineers behind it are competent, but the scope is narrower than the marketing suggests, and the severity definitions do real work in practice.
Severity levels and what they mean
Severity 1 means a complete loss of service for a production system with no workaround, and it obliges you to be available around the clock to work the issue, because Oracle will engage continuously and will downgrade the SR if you are not there to respond. First response for a Severity 1 typically lands within the hour. Severity 2 covers serious degradation with business impact, usually answered in business hours within a few hours. Severity 3 is a minor loss of function and Severity 4 is a question or documentation request, and both can sit in the queue for days without breaching anything. The single most common SR mistake is filing a genuine emergency at Severity 2 out of politeness, then wondering why the response feels slow. The second most common is filing everything at Severity 1, which burns credibility you will want later.
What an SR covers, and what it does not
Oracle support owns defects and faults in the OCI platform: a compute host that fails, a block volume that misbehaves, an Autonomous Database service that is not doing what the documentation says it should. It will tell you whether the platform is healthy. It will not tell you whether your architecture is sane. An SR will not redesign your network topology, tune your application SQL, explain why your bill doubled, restore the backup nobody verified, or arbitrate between two of your teams about whose change caused the outage. Oracle support also works one SR at a time, which means a complex incident spanning compute, database, and networking can fragment into three parallel tickets with no single owner. None of this is a criticism. It is the deal. Platform support covers the platform, and everything above the platform line is yours.
Layer two: partner and specialist support
The second tier is the one most buyers underestimate until they need it. Partner or specialist support covers everything above the platform line: architecture decisions and their consequences, performance problems that cross service boundaries, cost anomalies, incident response that requires judgement rather than a knowledge base article, and the translation work between what your business is experiencing and what an SR needs to say. A specialist who has seen the same failure pattern across hundreds of estates diagnoses in hours what an internal team meets for the first time. That pattern library is the product. Across 500+ OCI engagements we have rarely seen an incident that was genuinely novel, and that experience changes both the speed and the quality of the response.
This tier also changes your relationship with the first one. A specialist firm raises better SRs: correct severity, reproduction steps, diagnostic bundles attached, the right service identified on the first attempt. Oracle engineers triage faster when the ticket arrives complete, and escalation conversations go differently when the person on your side of the call speaks fluent Oracle. The independent position matters here too. We are not Oracle and we are not a reseller, so when the honest answer is that the platform is fine and the problem is your design, or the reverse, the answer does not bend to anyone's revenue.
Commercially this tier is usually bought one of three ways: a fixed project fee when the support need is attached to a defined piece of work, a managed monthly retainer when you want standing access to senior people, or an optimization fee taken as a percentage of verified savings when the engagement is about cost, where no savings means no fee. The retainer route is the most common for support specifically, and the numbers behind it are covered in our companion piece on OCI managed services pricing.
Layer three: the run team
The third tier is the team that operates the estate every day: monitoring, patching, backup verification, user and access requests, certificate renewals, capacity checks, and the first response when an alert fires. This is the layer that decides whether an incident becomes a story or a footnote, because the run team sees the problem first and frames it for everyone else. It can be your own staff, a provider's staff, or a blend, and the choice between those options is a substantial decision in its own right, one we work through in in house OCI team vs outsourced and, for the contracting structure specifically, in staff augmentation vs managed services.
The run tier has one requirement the other two do not: continuity. Oracle support and specialist firms respond when engaged. The run team has to be awake before anyone engages anything, which is why coverage hours are the first question to settle. An estate that matters to revenue needs 24/7/365 monitoring, full stop, and a run team that only works business hours is a run team that discovers Saturday's outage on Monday. For database heavy estates the same logic extends to DBA coverage, a topic with enough of its own texture that we gave it a separate article on outsourcing Oracle DBA work.
The three tiers side by side
The table below is the one to keep. Most support arguments dissolve once everyone in the room agrees which row a given problem belongs to.
| Support tier | What it covers | What it does not cover | Typical response |
|---|---|---|---|
| Oracle support via SR | Platform faults, service defects, infrastructure failures, documented behaviour questions | Your architecture, application performance, cost, cross service incident ownership | Under one hour for Severity 1, hours to days for lower severities |
| Partner or specialist support | Architecture, performance, cost anomalies, incident command, SR escalation and translation | Platform defects themselves, routine daily operations | Per contract, commonly 15 to 60 minutes for critical issues on a retainer |
| Run team, internal or outsourced | Monitoring, patching, backups, access requests, first response, routine changes | Deep specialist diagnosis, platform fixes, architectural redesign | Minutes for alert acknowledgement when coverage is 24/7/365 |
Read the gaps as carefully as the coverage. No single tier covers everything, and the failure modes are predictable. Oracle alone leaves you with a healthy platform under a broken workload and nobody to say so. A specialist firm alone has nobody watching the estate at night. A run team alone handles the routine beautifully and then hits a wall the first time an incident requires depth it has never needed before. The estates that recover fast are the ones where all three tiers exist and the seams between them are explicit.
Who owns what in an incident
OCI, like every major cloud, runs on a shared responsibility model. Oracle is responsible for the security and availability of the cloud itself: the regions, the physical infrastructure, the managed service layers. You are responsible for everything you build in it: identity configuration, network rules, data protection, patching of anything you control, and the architecture that determines whether a single host failure is invisible or catastrophic. The shared responsibility line is not a legal nicety. It is the operational boundary that decides, in the first ten minutes of an incident, whether the right move is an SR, a specialist, or a runbook.
The practical translation is an ownership map written before anyone needs it. The run team owns detection and first response for everything. The specialist tier owns diagnosis and incident command for anything above the platform line that the run team cannot close. Oracle owns anything below the line, engaged through an SR that the specialist tier drafts or reviews. One named role, usually in the run team, owns the incident record end to end so that three open tickets never substitute for one accountable owner. Write it down, test it in a game day, and the two in the morning call becomes procedure instead of improvisation.
Why 24/7/365 monitoring changes the SR conversation
The quiet advantage of continuous monitoring is not faster alerts, although you get those. It is evidence. When the estate is instrumented properly, the moment something breaks you already hold the timeline: which metric moved first, which service degraded second, what changed in the hours before. Arriving at Oracle with that package transforms the SR. Instead of a day of back and forth while support asks for logs you have to go and find, the ticket opens with the diagnosis half done, the severity is defensible, and the misrouting that plagues vague SRs simply does not happen. We run OCI monitoring on a 24/7/365 basis for exactly this reason: the watching is valuable, but the evidence is what shortens outages. The same telemetry also settles the boundary question quickly. When the platform is at fault the data shows it, and when your workload is at fault the data shows that too, which keeps everyone honest and keeps the incident moving instead of circling through blame.
Six steps to build a working support model
If you are designing or repairing your support stack, work through this sequence in order. Each step closes a gap the previous one exposes.
- Classify your workloads by consequence. Decide which systems justify Severity 1 treatment and around the clock coverage, and which can wait for morning. Everything else in the model keys off this list.
- Draw the responsibility line. For each workload, write down what is Oracle's under shared responsibility and what is yours, so the SR or runbook decision is made in advance rather than mid incident.
- Settle run team coverage. Match coverage hours to the consequence tiers from step one, and be honest about whether the internal team can sustain a real on call rotation or whether 24/7/365 belongs with a provider.
- Contract the specialist tier deliberately. Decide what depth you need on call for architecture, database, and cost questions, and put response times in writing: a fixed project fee for defined work, a managed monthly retainer for standing coverage.
- Write the escalation path as one page. Who detects, who diagnoses, who calls Oracle, who owns the record, who talks to the business, and the time thresholds that trigger each handoff. If it does not fit on a page it will not survive an outage.
- Test it before reality does. Run a game day twice a year, file a practice SR, time the handoffs, and fix what stalls. A support model that has never been rehearsed is a hypothesis, not a model.
What good looks like
A working support model is unglamorous. Alerts are acknowledged in minutes because someone is always watching. Most incidents die at the run tier inside the runbook. The hard ones escalate to a specialist who has seen the pattern before, and the genuine platform faults reach Oracle as complete, well evidenced SRs at the right severity. Nobody argues about ownership because ownership was decided in a meeting, not a war room. Teams that operate this way also spend less, partly because incidents end sooner and partly because the same telemetry that speeds up diagnosis exposes waste; it is no accident that estates with disciplined support models are the ones where optimization work finds its 40 percent. With 20+ years of combined Oracle experience behind our own run and specialist tiers, the strongest advice we can give is also the cheapest: decide who owns what before the pager goes off. Everything else in this article is detail attached to that one decision.
Free white paper
Go deeper on this topic with The OCI Cost Optimization Framework, how to find, verify, and lock in OCI savings. An independent analyst style report with comparison tables and recommendations, free with a work email. Prefer a monthly summary instead? The OCI Brief delivers one practical OCI briefing a month.
Part of a series
This guide is part of OCI Operations & Observability — our complete pillar guide on the topic.
Moving Oracle workloads to OCI, or already running on OCI and not sure the architecture or the spend is right? Most teams bring in a specialist before they commit to a region, a shape, or a Universal Credits number. OCISpecialists.com plans the landing zone, runs the migration, and manages the estate after go live, on a fixed project fee, a managed monthly retainer, or a cost optimization fee paid only on verified savings.