Carrier API Uptime SLAs: 8 Vendors' Real Numbers

What we measured, and how

We pulled two different things from public sources between late July and August 4, 2026, and put them side by side: what each carrier or multi-carrier platform actually commits to in writing on uptime, versus what independent status-page trackers have logged over the same period. The gap between those two numbers is the whole point of this post.

Sources were Atlassian Statuspage instances run by the vendors themselves, vendor legal and marketing pages, and third-party aggregators IsDown and StatusGator. We did not use our own harness data here. This is a public-record exercise, deliberately, because the point is to show what's checkable by anyone before you sign a contract, not what we saw in our own test rig.

Three things are explicitly out of scope:

• Direct carrier APIs with no public status page we could locate a numeric SLA on, including DHL and USPS.
• Internal monitoring data from our own test harness, which we're saving for a separate benchmark.
• Anything behind an enterprise-only NDA'd SLA document. If a vendor only discloses a number to signed customers, it isn't public, and we mark it "Not published."

That last rule matters. If a figure isn't sitting on a public page we could open in a browser on August 4, 2026, it's "Not published" in the tables below. No estimates, no "probably around 99.9%."

Table 1: published SLA commitments vs. marketing claims

Most platforms in this space don't publish a contractual uptime number at all. What they publish instead is a headline percentage on a marketing page, which is a different animal from a Service Level Agreement with credits attached.

Sendcloud is the only vendor in our set with a public, named number attached to a specific product tier: Published Ship and Track SLA: 99.9% uptime and a 300ms response commitment on business-critical transactions. Its homepage tells a different story, though: 99.99% uptime is a Sendcloud homepage marketing claim, and a public status page is available, but no public contractual SLA document was identified as of July 2026. Two numbers, two very different weights.

EasyPost's docs page markets "See our 99.99% uptime API status" right on the front page. Dig into their own reliability page and the number softens: EasyPost targets a minimum of 99.9% uptime, meaning they target less than 10 hours of downtime over the entire year. That's a target, stated by the vendor itself, not a contract, and it's a full order of magnitude looser than the headline figure on the docs page.

Table 2: 90-day incident counts from independent trackers

Here's where the marketing claims meet the log files. IsDown tracks incidents by pulling from each vendor's own official status page, so this isn't user-report noise, it's the vendor's own incident history, aggregated.

EasyPost's own status page shows the vendor logged 8 incidents in the last 90 days, 2 major outages and 6 minor incidents, with a median duration of 2 hours 59 minutes, and over its full monitoring history, 209 incidents caught since June 2020, across 7 components tracked in real time. Shippo's 90-day window is rougher: 37 incidents, 14 major outages and 23 minor incidents, with a median duration of 2 hours 18 minutes, against a lifetime total of 539 incidents caught since May 2020, across 18 components tracked in real time. That component count matters, more on it below.

We couldn't pull a clean 90-day incident count for Sendcloud from IsDown at time of writing, so we're not putting a number there we can't stand behind. What we do have is the vendor's own live dashboard reading 99.91% uptime for the current window, and StatusGator's lifetime tally: Sendcloud is an eCommerce solution that StatusGator has been monitoring since October 2021, and over the past almost 5 years, they have collected data on more than 2,535 outages that affected Sendcloud users. UPS shows a similar pattern of scale: StatusGator has been monitoring UPS since April 2023, and over the past 3-plus years, has collected data on more than 552 outages that affected UPS users. Both of those are multi-year totals, not comparable to the 90-day rows above them. Don't average them in.

Why the SLA and the incident log rarely agree

The short answer: they're measuring different things, on purpose. A 99.9% SLA leaves room for real, felt downtime while the vendor stays fully "compliant" on paper. A number like that translates to roughly one significant outage window per quarter that hits every customer on the platform simultaneously, and most SLA documents only count full, verified outages, not degraded latency or partial error rates. Sendcloud's own documentation is explicit about the threshold it uses before something even counts as an incident: Sendcloud will declare incidents on the Statuspage only when an issue is detected by their monitoring systems and persists for more than 30 minutes. A 25-minute blip that breaks your checkout flow at 2pm on a Tuesday doesn't make it onto the public log at all. That's not dishonest, it's a stated policy, but it means the incident count you can read publicly is already a floor, not a ceiling.

There's a second layer specific to multi-carrier platforms: they log by upstream component, not platform-wide. Shippo tracks incidents across 18 components in real time, and its own status page during our research window listed scheduled maintenance windows for individual carrier connections rather than the platform as a whole, including a USPS scheduled maintenance window on Aug 3, 2026, lasting up to 8 hours, during which tracking information would be intermittently unavailable, alongside a separate Royal Mail Intersoft maintenance window a few days later. A "Shippo incident" in that log is very often a DHL or Royal Mail problem surfacing through Shippo's dashboard, not a Shippo platform failure. If you're benchmarking the vendor's own reliability, that distinction changes what the number means.

What this means for architecture decisions

Don't size your retry budget or failover logic off a homepage percentage. Size it off the incident log, and off how granular that vendor's status page is. A platform tracking 18 separate carrier components, like Shippo, will show more total incidents than one tracking fewer, simply because it's watching more failure points, not necessarily because it's less reliable.

If you're stacking a multi-carrier layer on top of three or four direct carrier connections, remember that dependent systems compound risk multiplicatively, not by average. Two systems each rated at 99.9% don't give you 99.9% combined; the real ceiling on your dependency chain is the product of every link in it, and a marketing page for any single vendor tells you nothing about that math.

Where a vendor, whether that's nShift, ShipEngine, or Cargoson, doesn't publish a numeric SLA, ask for their underlying Statuspage history directly rather than trusting the homepage copy. It's a five-minute ask and it's the only way to get a real answer instead of a rounded one.

Method notes, gaps, and what we'd need to close them

We couldn't locate a public numeric SLA for DHL, FedEx, UPS, or USPS direct APIs, despite each running public infrastructure status pages. ShipEngine's and nShift's status pages display live uptime charts, but neither exposes a static aggregate we could extract as a 90-day number without scraping a rendered chart, which we didn't do for this post.

If you're logging your own uptime against any of these platforms from a production integration, we'd like to see it. A follow-up comparing self-reported vendor numbers against engineer-side monitoring is the obvious next step, and it's the kind of data this post can't produce on its own.

All figures above are accurate as of August 4, 2026. Status pages change; check the linked sources before you cite this in a vendor negotiation.