A good API uptime SLA promises a specific availability percentage over a defined period, states plainly what counts as downtime, explains how it is measured, and pays a meaningful credit when it is missed. For most production APIs, 99.9% is a reasonable floor and 99.95% to 99.99% is strong. The number matters far less than the definition around it: an SLA that excludes half of real failures and measures from the vendor's own servers is marketing, not a promise.
APIs get held to a higher standard than websites, and rightly so. A website with a five-minute blip annoys some visitors. An API with a five-minute blip can break every customer who built on top of it, all at once, with no way for them to route around you. That is why the SLA on an API deserves a closer read than the headline percentage most vendors lead with.
What is an API uptime SLA?
An API uptime SLA, or service level agreement, is a contractual commitment to a level of availability. It has three parts that all matter: the target (say 99.9% monthly), the definition of what "available" means and which failures count against it, and the remedy, usually a service credit, when the target is missed. An SLA without all three is just a number on a marketing page.
The percentage is where people stop reading, and it is the least interesting part. A 99.99% SLA that excludes scheduled maintenance, rate-limiting, degraded performance and anything the vendor labels "not an outage" can be weaker in practice than a plain 99.9% that counts everything. Read the definition before you read the number.
What is a good API uptime percentage?
Good depends on what the API does, but there are sane reference points. The gap between each tier is not linear: every extra nine cuts the allowed downtime by roughly ten times, and the cost of delivering it rises far faster.
| Uptime SLA | Downtime per month | Downtime per year | Typical for |
|---|---|---|---|
| 99.9% (three nines) | 43m 50s | 8h 46m | Standard production APIs |
| 99.95% | 21m 54s | 4h 23m | Paid APIs with real dependencies |
| 99.99% (four nines) | 4m 23s | 52m 36s | Payments, auth, core infrastructure |
| 99.999% (five nines) | 26s | 5m 15s | Rarely offered, very expensive |
For a paid API that other businesses build on, 99.9% is a defensible floor and 99.95% signals you take it seriously. Reserve 99.99% for the parts that genuinely cannot blink, like authentication or payments, because promising it everywhere means paying for redundancy you may not need. We broke the math down further in what is a good uptime percentage.
alertping
Measure your API SLA from outside
AlertPing checks your API every 30 seconds from two regions, asserts on the response body and status, and records the exact downtime windows, so your SLA number comes from independent measurement rather than a guess.
How is an API uptime SLA measured?
This is where good and bad SLAs separate, because the same outage can count or not depending on who is holding the stopwatch and what they decided to time. Three questions decide whether an SLA means anything.
- Measured from where? An SLA measured on the vendor's own network misses the network path, DNS and regional problems your customers actually hit. Independent, external measurement from multiple regions is the only figure a buyer should trust.
- What counts as down? A strong SLA counts errors, timeouts and degraded responses, not just a fully unreachable endpoint. A weak one only counts total outage, so an API returning 500s to every caller can technically stay "up".
- Over what window? A monthly window resets the clock every 30 days, which favors the vendor after a bad day. A rolling window is harder to game. Check whether maintenance windows are carved out before the percentage is even calculated.
The practical consequence for anyone consuming an API: do not take the vendor's dashboard as the source of truth for whether they hit their SLA. Measure it yourself. A monitor that checks the endpoint from outside, asserts on the actual response and timestamps every failure gives you your own record, which is the one that matters when you file for a credit.
What should an API uptime SLA count as downtime?
A meaningful API SLA counts more than "the server did not answer". The failures that hurt API consumers are often the ones a naive check waves through.
- Error responses. An endpoint returning 500 or 503 to every request is down, even though it answered. The SLA should say so.
- Wrong or malformed responses. A 200 with a broken JSON body or a missing field breaks the caller just as hard as an outage. This is why measuring an API means asserting on the response, not the status code alone.
- Latency past a threshold. An API that takes 30 seconds to answer is unusable for most callers. Strong SLAs define a response-time ceiling and count breaches.
- Auth and rate-limit failures. If valid requests get rejected, the API is down for that customer regardless of how the vendor categorizes it.
Turning that list into working checks, with body assertions and latency thresholds, is the subject of how to monitor an API for errors.
This is also the honest limit of any uptime tool, ours included: a check can confirm the endpoint answers correctly and quickly, but it cannot prove every downstream integration behaves. If you depend on the third-party APIs you connect your systems to, monitor each one against its own SLA rather than assuming the vendor's status page tells the whole story.
What does an API uptime SLA actually pay out?
This is the part buyers skip and then regret. An SLA is not a guarantee that your API stays up. It is a pre-agreed refund schedule for when it does not, and the refund is almost always a percentage of what you paid that month, not a percentage of what the outage cost you.
The shape is near-identical across AWS, Google Cloud and Azure, and most SaaS vendors copy it. Credits are banded: miss the target slightly and you get a small percentage back, miss it badly and you get more. Nobody pays out above the monthly fee.
| Actual monthly uptime | Downtime in a 30.44-day month | Typical service credit | Credit on a $2,000/mo contract |
|---|---|---|---|
| At or above the 99.9% target | Up to 43m 50s | 0% | $0 |
| 99.0% to under 99.9% | 43m 50s to 7h 18m | 10% | $200 |
| 95.0% to under 99.0% | 7h 18m to 36h 32m | 25% | $500 |
| Below 95.0% | Over 36h 32m | 50% to 100% | $1,000 to $2,000 |
Work one row of that honestly. Your vendor promises 99.9% and delivers 99.5%. That is 3 hours and 39 minutes with a broken API in a single month. The credit is $200. If your checkout depends on that API, $200 does not come close to covering three and a half hours of failed orders, and the vendor has met its contractual obligation in full by paying it.
So the credit schedule is best read as a signal rather than as insurance. A vendor willing to write 25% at 99.0% is telling you it expects to stay well clear of that band. A vendor whose maximum exposure is 10% of one month's fee is telling you the opposite. Either way, price the outage yourself and decide how much redundancy to buy, because the SLA will not do it for you.
Three practical conditions apply to almost every credit clause and each one reduces what you collect. You usually have to request the credit in writing within 30 days, which means somebody has to be tracking availability independently or the window quietly closes. Credits are applied to future invoices rather than refunded in cash. And downtime is counted from the vendor's own measurements unless you can produce your own, which is the practical argument for running independent API monitoring against anything you have an SLA with. We broke the full credit mechanics down in SLA service credits.
Which of SLA, SLO and SLI is the promise?
These get tangled, and the distinction matters when you read a contract. The SLA is the external promise with a remedy attached. The SLO is your own internal target, usually stricter than the SLA so you have headroom before you breach. The SLI is the actual measured number, the indicator you compute from monitoring data. You promise an SLA, you aim for a tighter SLO, and you track an SLI to know where you stand. We separated the three in SLA vs SLO vs SLI.
Put together, a good API uptime SLA is legible: a percentage you can hit, a definition of downtime that counts the failures customers feel, external measurement they can verify, and a credit that actually stings when you miss. If you are consuming an API, judge the SLA by those four, not the number. If you are offering one, back it with independent API monitoring and publish real SLA reporting, because a promise you cannot measure is one you cannot keep.