What is a Service Level Agreement (SLA) and what should an AI startup actually commit to

Somewhere in your first enterprise contract, alongside the Master Services Agreement, you will likely be asked to agree to a Service Level Agreement, or SLA. It is one of those documents that sounds procedural but can quietly become one of the most consequential things you sign, because it sets numeric promises about your product that you are then contractually held to. This article explains what an SLA actually is and, more usefully, what an AI startup should realistically commit to, because the wrong SLA can create obligations that are genuinely difficult for a small team to meet.

What an SLA actually is

A Service Level Agreement is a contract, or a section within a wider contract, that defines the level of service you commit to providing, usually expressed as specific, measurable numbers. The most common is uptime, the percentage of time your service is available and working. But a proper SLA typically covers several other things too, including response times when something goes wrong, resolution times for different severities of issue, and the remedies the customer gets if you fail to meet those numbers, often service credits or, in serious cases, the right to terminate the contract.

The reason this matters more than it might seem is that an SLA turns a general expectation, we will try to keep things running well, into a specific, enforceable number. If you promise 99.9% uptime and fail to deliver it, that is a contractual breach with defined consequences, not just a disappointed customer.

The uptime numbers, and what they actually mean

Uptime percentages sound abstract until you translate them into actual time, and the difference between the common tiers is bigger than it first appears.

• 99% uptime allows for around three and a half days of downtime across a year. This sounds low, but it is a realistic and defensible starting point for an early stage product.
• 99.9% uptime, often called three nines, allows for around eight and a half hours of downtime a year. This is a common enterprise expectation and is achievable for a mature, well architected product, but it requires real operational discipline to hold consistently.
• 99.99% uptime, four nines, allows for roughly 52 minutes of downtime across an entire year. This is a serious commitment that typically requires redundant infrastructure, mature incident response, and dedicated operational investment. Very few early stage startups can honestly commit to this and should not sign up to it just because a buyer's template defaults to it.

The number in the SLA is not a marketing figure, it is a promise you have to actually be able to keep, measured and enforced.

What an AI startup should actually commit to

Here is the honest, practical guidance. Your SLA should reflect your genuine operational maturity, not what sounds impressive or what a buyer's template happens to default to.

For most early stage AI startups, a target of 99% to 99.5% uptime is a realistic and defensible starting point. It is high enough to signal seriousness, and low enough that you can actually hold it without heroics. As your infrastructure matures, you can commit to tighter numbers in future renewals, which is a much better path than overpromising now and breaching your own contract later.

Be especially careful about two things specific to AI products. First, define uptime clearly enough that it distinguishes your own infrastructure from your model provider's. If OpenAI, Anthropic, or another provider you depend on has an outage, your product may be affected through no fault of your own, and a well drafted SLA should account for this, either through a carve out for third party provider outages or by being realistic about the ceiling your own commitment can reach given that dependency. Signing an aggressive uptime SLA without accounting for your dependency on a third party model provider is one of the more common mistakes AI startups make.

Second, think carefully about latency and response time commitments if your product involves real time AI interactions, because these can be harder to guarantee precisely than for traditional software, given the variability in model response times, especially under load or during a provider's own performance fluctuations.

Response and resolution times, the part people forget

Uptime gets the attention, but the response and resolution time commitments matter just as much and are often where startups sign up to something unrealistic. A response time is how quickly you acknowledge an issue has been raised. A resolution time is how quickly you actually fix it. These should scale with severity, so a critical outage affecting the whole product warrants a much faster commitment than a minor cosmetic bug.

The trap is committing to fast resolution times without the team or the process to genuinely deliver them. A commitment to resolve critical issues within four hours only means something if you have a real on call process behind it. Do not put a number in an SLA that describes an aspiration rather than your actual operational capability.

What happens if you miss the numbers

Look carefully at the remedies clause, because this is what actually happens to you if you fail to meet the SLA. Most commonly, missing your uptime commitment results in service credits, a partial refund of fees for the period affected, calculated on a sliding scale depending on how badly you missed the target. Understand this calculation before you sign, not after you have missed a target and are trying to work out what you owe.

In more serious or repeated cases, some SLAs give the customer a right to terminate the contract entirely if service levels are missed persistently. Know whether that clause exists in what you are signing, because it changes an SLA breach from a financial inconvenience into an existential risk to the relationship.

Negotiating rather than accepting the template

Enterprise buyers frequently start with their own standard SLA template, calibrated for large, mature vendors, not an early stage startup. It is entirely normal and expected to negotiate this down to numbers that reflect your actual size and maturity, rather than silently accepting a template built for a much bigger company. Buyers who are serious about working with an early stage vendor understand this, and a startup that pushes back with realistic, well reasoned numbers looks more credible, not less, than one that signs whatever is put in front of it.

The honest takeaway

An SLA is not paperwork to sign quickly so a deal can close. It is a specific, enforceable promise about your uptime, your response times, and your resolution times, with real financial and contractual consequences if you fail to meet it. Commit to numbers that reflect your actual operational maturity today, account explicitly for your dependency on third party AI providers, and negotiate a buyer's template rather than accepting it as given.

Get this right, and your SLA becomes a credible signal of how seriously you take reliability. Get it wrong, and it becomes the clause that quietly turns your first big outage into a contractual crisis.