When Your Vendor's SLA Isn't Your Client's SLA

When a resold tool goes down, your client's contract is with you, not the vendor that built it. The vendor's SLA controls what you get back when it fails, usually a billing credit. Your SLA controls what you owe the client. Benchmarking the gap between those two documents, not copying the vendor's number, is what keeps a missed SLA from costing you the account.

The more white-labeled tools you add to your catalog, the more of these gaps you're carrying at once. Every AI-powered tool you brand and resell sits on top of someone else's infrastructure, someone else's uptime commitment, and someone else's definition of a qualifying outage. A client buying several services from you under one contract is really depending on several separate vendor SLAs you have never read side by side, stacked underneath one promise with your name on it.

What does a vendor's SLA actually promise you?

A vendor SLA promises a credit, not an outcome. AWS's Bedrock Service Level Agreement ties the remedy to monthly uptime for the region: a 10 percent credit on that region's monthly charges when uptime falls between 99.0 and 99.9 percent, a 25 percent credit between 95.0 and 99.0 percent, and a 100 percent credit below 95.0 percent. That tiered structure is typical across cloud and SaaS vendors generally, not something unique to one provider.

Here is that tier structure the way the vendor publishes it:

The credit is calculated against what you paid the vendor that month, not against what your client pays you, and not against what the outage cost your client in lost work. Atlassian's cloud SLA states plainly that service credits are the customer's sole and exclusive remedy for a missed service level commitment. Read literally, the vendor's entire financial exposure for an outage is capped at a slice of your subscription fee, regardless of what the outage does to your client relationship.

This is not a complaint about vendor behavior. It is the standard structure of nearly every SaaS and cloud contract, including the ones running underneath the white-labeled tools you resell. The trouble starts only when an MSP treats the vendor's uptime number as if it were the client's SLA, instead of treating it as one input into building the client's SLA.

Where does the gap land when a resold tool goes down?

The gap lands on you, not the vendor, because your client's relationship is with your brand. MSSP Alert's coverage of the July 2024 CrowdStrike outage captured this directly. Blackswan Cybersecurity CEO Mike Saylor said that an MSSP monitoring an affected client environment will observe the resulting outages, errors, and alerts, and that its job becomes assessing and reporting what it sees, then keeping tickets updated, whether or not it has any partnership with the vendor behind the failure.

Your client did not sign a contract with the tool vendor. They signed one with you, under your brand, and your name is the one on the renewal. When the underlying product misses its own SLA, the vendor's remedy flows to you as a credit on your bill. Whether any part of that credit, or any explanation, reaches your client depends entirely on the SLA you wrote for them, not the one the vendor wrote for you.

That gap is also why reselling a bare tool is riskier than productizing the delivery around it. Comparing each candidate product's underlying SLA against your own client commitments before you add it to your catalog, using something like a stack-builder comparison, tells you up front how much buffer you need to carry and what you can honestly promise once it is live.

How should you benchmark your own SLA against the vendor's?

Start with the vendor's actual uptime commitment and credit ladder, not its marketing claims, then layer your own response and communication commitments on top of it. Your client-facing SLA has to cover two things the vendor's SLA never touches: how fast you tell the client something is wrong, and what you do operationally while the vendor's issue is still open.

Hypothetical example: say a white-labeled AI tool your MSP resells carries a vendor SLA with a 99.9 percent monthly uptime target and a 10 percent credit below that line, the same structure published in AWS's own tier table above. If that tool goes down for several hours during one incident, the vendor credit you receive is a small slice of what you paid the vendor that month, nowhere close to what a half-day outage can cost a client in lost productivity or missed deadlines. If your own client contract promises a fast acknowledgment and regular status updates during an outage, that commitment has to be staffed and tested on its own, independent of whatever credit eventually arrives from the vendor.

The real benchmarking question is not whether the vendor's uptime number looks good on a sales page. It is whether your technician coverage, escalation path, and communication cadence can deliver on your promise to the client even when the vendor's own number holds up exactly as published.

What should your own SLA document actually define?

A client-facing SLA built to survive a vendor outage has to spell out things the vendor's SLA never addresses, because the vendor is only answering for its own infrastructure, not for your relationship with the client sitting on top of it. At minimum, it should define:

• Severity tiers tied to business impact for that specific client, not generic ticket categories, so a payroll outage and a printer issue are never measured against the same clock.
• An acknowledgment time your dispatch process can hit on a bad day, not just an average day, since averages are exactly what break down during a vendor-wide incident.
• An escalation path that names who talks to the client during an open vendor incident, so "we're waiting on the vendor" is a status update, not a disappearance.
• Your own definition of resolved, which should match when the client's business function is restored, not when the vendor marks its own status page green again.

Those elements are what separate an SLA you can actually operate from one that only reads well in a sales conversation. None of them require the vendor to change anything about their own contract. They require you to decide, in advance, what you are staffing and measuring against, instead of discovering it live during an incident call.

What happens if you don't close the gap?

The cost of getting this wrong keeps climbing. Uptime Institute's 2025 Annual Survey, cited in its 2026 Annual Outage Analysis, found that 57 percent of respondents said their most recent major outage cost more than $100,000. The same survey found that for the second consecutive year, 1 in 5 reported costs exceeding $1 million. None of that cost is offset by the credit sitting in your vendor account, and none of it is the vendor's problem to solve.

An MSP that has not closed the gap between its own SLA and its vendors' SLAs usually finds out the hard way:

• A client invokes a termination or renegotiation clause after an outage the MSP had no operational answer for, because the SLA promised a response the bench could not actually staff.
• A renewal turns into a pricing standoff, because the client now prices in a risk the MSP never disclosed up front.
• The MSP eats the cost of a client-facing service credit out of its own margin, because the vendor's credit never came close to covering it.

None of those outcomes require the vendor to have done anything wrong. They are all downstream of a client SLA that was written against a vendor's marketing number instead of its published credit terms and your own delivery capacity.

Where this fits in your product lineup

Every white-labeled product you add to your stack carries its own uptime commitment, its own credit structure, and its own operational dependencies once something breaks. Before you brand and resell the next one, run the same exercise: read the vendor's actual SLA document, not just its pitch deck, and decide what you can honestly promise your client on top of it. Make sure your team has the skills to execute those commitments under load, not just language in a contract, and Forge University offers AI-mentored IT and security certification training to build them.

Reviewing the full product stack before you commit to a new SLA tier is a far cheaper exercise than discovering the gap during a live incident. See the full stack to compare what is already benchmarked against your delivery model.