Writing B2B SLAs When Core Services Rely on OpenAI Uptime
By wGrow Project Team ·
99.9% uptime allows around 43 minutes and 49 seconds of downtime per month, averaged across the calendar year. If you build on OpenAI and OpenAI drops, you cannot absorb the SLA penalty for their server issues.
That should be the opening conversation with any Singapore SME procurement team before anything is signed. Not a negotiating tactic. Arithmetic.
The Commercial Math Nobody Wants to Run
OpenAI’s status history records a multi-hour API and ChatGPT outage on November 8, 2023 (status.openai.com/history), disrupting production workloads across its customer base. A separate entry in that same status history, dated June 4, 2024, logs elevated errors and latency across the API (status.openai.com/history). Without an upstream carve-out in your MSA, either type of incident can land on your side of the liability ledger — even when the root cause sits entirely outside your stack.
Take a 4,000 engagement, that credit is $400. You have paid to be the middleman for someone else’s infrastructure failure.
This is the baseline risk of building agentic applications on third-party model endpoints. A software studio that signs a standard SLA for an LLM-powered product without carving out foundational model availability is accepting liability it cannot operationally control.
The Third-Party AI Dependency Clause
For agentic workflows, a standard software SLA is the wrong instrument. A better fit is a modified Master Services Agreement containing what can be called a Third-Party AI Dependency clause.
The hardest test is a public-sector buyer. When a public-facing chatbot is integrated into a service portal, legal may reject a standard MSA outright. They want full vendor accountability: one throat to choke, one SLA number, full stop. Understandable. That is how government procurement is trained to think about software.
Meeting that objection means restructuring how uptime is defined entirely.
The clause separates Application Uptime from Model Uptime. Application Uptime covers the vendor’s infrastructure: the web layer, the API gateway, the orchestration layer, the database. The vendor owns those and can SLA those. Standard credits are defensible because the vendor controls the stack.
Model Uptime sits in a different box. It covers the availability of the primary LLM endpoint — OpenAI, Anthropic, or whichever foundational model the architecture depends on. Failures here are classified as Third-Party AI Dependency Events, sitting under a modified force majeure definition. The vendor’s obligations: detect and log the failure quickly; activate fallback routing; notify the client with a link to the upstream provider’s status page. What the vendor is not obligated to do is issue credits for downtime causally attributable to the upstream endpoint — provided it can demonstrate the failure boundary with telemetry.
That restructuring works because procurement has to accept a structural reality: LLM APIs are not hosted databases or CDNs. Those services carry decades of reliability engineering. LLM endpoints do not. The SLA framework has to reflect that gap.
Graceful Degradation Is Not Optional
A watertight contract does not stop users from getting frustrated. Even once legal accepts the clause, an engineering problem remains: what does the UI do when the OpenAI API drops?
Returning a 500 server error is a failure of architecture, not a failure of the API.
An SME customer service portal can be built with a three-tier routing strategy. The primary layer calls GPT-4o. If that endpoint returns errors or exceeds a fixed timeout, the orchestration layer reroutes to a self-hosted Llama 3.1 8B instance. Llama 3.1 8B handles classification, FAQ retrieval, and short-form response generation adequately — it cannot match GPT-4o on nuanced reasoning, and running a local instance adds hosting overhead — but it keeps the interface alive.
If the local model also goes down, the system falls back to a cached response layer: pre-generated answers to the highest-frequency queries, served with a degraded-mode banner that reads, “We are currently operating in limited capacity. Responses may be shorter than usual.” Users see something. Ticket volume to human agents may rise. The 500 error page never appears.
The routing logic is a priority queue with health checks polling on a short interval. No exotic orchestration framework. The harder decision is which model handles which query class in degraded mode — that is a product call, not an infrastructure one.
Educating Procurement on Where Your Control Ends
If a Singapore SME founder or IT director treats AI as standard SaaS (monthly subscription, defined feature set, uptime guarantee), that model breaks down for agentic applications. Correcting it should be part of the delivery process.
Run an onboarding session with every new client’s procurement and IT leads. Walk them through the telemetry dashboard — application response times, model endpoint health checks, the upstream provider status page — and run a simulated incident so they can see exactly which alert fires at which layer. That simulation can do more to calibrate expectations than any contract clause.
When an actual incident occurs, send the client a structured incident report promptly: which layer failed, when, for how long, what the fallback did, and a link to the upstream provider’s incident report. Procurement teams can accept AI volatility when you show them the boundary of your control with evidence. What they cannot accept — and should not be asked to — is a vendor who shrugs.
Stop Promising What You Cannot Deliver
Stop promising absolute uptime for agentic workflows. The dependency chain is long, the liability math is punishing, and the tooling is not yet mature enough to absorb it without explicit carve-outs.
The two responsibilities don’t overlap and neither replaces the other: engineers build graceful degradation into the application layer; commercial counsel builds third-party carve-outs into the MSA. Both have to ship before you go to contract.
Building enterprise AI in Singapore today is less about prompting and more about mitigating downstream liability. The contracts and the architecture have to reflect that in equal measure — and the conversation starts with 43 minutes and 49 seconds.