A large partner's integration contract asks for 99.99% availability and a 200 ms p99 on your API, with penalties. Your service currently runs at 99.9% and 400 ms p99. What do you agree to, and what do you trade for it?

What the numbers actually mean

Put the arithmetic on the table first, because most SLA requests are made without it. 99.99% is about 4.3 minutes of downtime a month. 99.9% is about 43 minutes. The difference is not one decimal place of effort: it removes the possibility of a single deploy going wrong and being rolled back by a human, because a human cannot notice, decide and act inside four minutes. 99.99% is an architecture and an automation commitment, not a target.

The latency request deserves the same treatment. p99 at 200 ms when you serve 400 ms means either substantial work on the tail or a scope change, and p99 measured where? Measured at your edge and measured at their client are different numbers separated by the internet.

What is gained

The contract, obviously, and often a genuine forcing function: partner requirements are one of the few things that reliably fund reliability work. If you intended to do the work anyway, a committed SLA converts it from a backlog item into a funded project.

What is paid

• Engineering cost, concentrated in redundancy, automated failover and the removal of single-zone dependencies. Expect a multi-quarter programme, not a sprint.
• Delivery speed, permanently. Four minutes of monthly budget means progressive delivery, automated rollback and change freezes around peak periods.
• Operational cost: multi-zone or multi-region runs roughly 1.7× to 2.2× single-zone infrastructure once replication and cross-zone traffic are counted, plus a second on-call rotation's worth of attention.
• Penalty exposure, which is usually the smallest number in the negotiation and the one that gets all the attention.

What to trade, and how to shape the agreement

• Scope the SLA to the endpoints that matter. Partners ask for a blanket number because it is easier to write. Offer 99.99% on the two endpoints their business depends on and 99.9% on the rest; this is usually accepted and it is a fraction of the work.
• Agree the measurement point and the exclusions before the number. Planned maintenance windows, client-side network faults, and their own rate-limit breaches. An undefined measurement point is where SLA disputes actually happen, not the percentage.
• Trade the number for a commitment you need: a longer contract term, a higher rate, an earlier integration deadline, or the right to a maintenance window.
• Phase it. 99.9% at signature, 99.95% at six months, 99.99% at twelve, with the investment visible in the schedule. This is honest and it usually survives contact with procurement.

When this is the wrong deal to take

When the request is a percentage the partner's own system cannot consume. If their client times out at 2 seconds and retries once, your 200 ms p99 changes nothing for their users. Ask what user-visible outcome the number protects; if there is no answer, you are being asked to fund a procurement habit, and the right move is a smaller commitment you will actually meet.